Tag Archives: wxPython

Sep 10 2010

wxPython versus ArcToolbox tool


It started out to be simple stuff that I wanted to accomplish with Python and geoprocessing.  A lot of the tools that I created or wanted to create were quite easy to do in ArcToolbox but I soon found that I wanted to have more flexibility and more input options.  The ArcToolbox tools work great but they are limited in their uses and functions.  So in walked wxPython.  I tried messing around with several different options but after the dust settled it was wxPython that I went with.

Tinkter was ok but lacked a lot of options.  I tried Boa-Constructor but found that it was confusing to get going.  I tried Python-Card and although it seemed easier that Boa-Constructor, I was left with the nagging question of now what when I finished the “window.”  So back to wxPython.  As it is based on wxWidgets there is a lot of information on the web and tutorials as well.  So my mind was made up and then I had to figure out what it was that I wanted to do.

Being new to programming, I quickly learned that there are two stages to programming.  The first stage is “what am I trying to do” followed by the second stage of “OK, now how the heck do I do it!”  I know for all of you programmer gurus or those with formal programming training, this is quite obvious but for me it wasn’t obvious at all.  Now that I have gotten better at both Python and wxPython, I see that it sometimes takes longer to understand what I want to accomplish than it does to code it once my mind is made up.

So back to wxPython…….One of the functions that I soon found lacking in the ArcToolbox tools is taking inputed data and allowing user to perform functions based on the actual data that was imported.  What I am trying to say here is that I wanted to input a point file and then based on the data in the file, decide what processes I wanted to perform.  Another example of this is that I can input a shapefile and get a list of field names but I cannot choose a field and decide what to do with it.  The ArcToolbox allows minimal input and output but that is it.  I wanted more interaction such as input a shapefile, create a list of fields, allow the user to choose a field, and then make calculations based off of that.  This back and forth interaction wasn’t possible so off the wxPython I went.

Now by creating “wizard” like interfaces, I can accept inputed data, create lists and dropdown choices of those lists and further functions.  Don’t get me wrong, I have more ArcToolbox tools than I have wxPython GUI’s but they each serve a different function.

BR

Aug 22 2010

Logging, logging, logging……


So with a lot of help from friends and a programmer that works with us, we have just about completed our first wxPython GUI that we are going to use for a clients interface.  For those that have a clue about basic programming (which I did NOT) I am sure that you are familiar with setting break points to troubleshoot your code.  Even better than this (in my opinion and easier as well) is the use of logging.  Using logging statements all over your code in areas that may be giving you problems, you can see where the issue may be occurring.


import logging

logging.basicConfig(filename='dev.log',level=logging.DEBUG,filemode='w',
 format='%(filename)s::%(module)s::%(funcName)s::%(lineno)d %(levelname)s %(message)s'
 )

# above is the config/setup. Put at top of file.

# here's some examples using it.
 # look in "dev.log" for output!

def blah() :
 logging.debug("starting blah!")

logging.debug("finished blah!")
 blah()

Now when you run your process you can check your dev.log to see if all of your logging statement are there.  If they are not all there, then you can see where the last statement was and it helps to zero in on your problem.