Skip to main content

In The Trenches

Undertaking the task of converting a Visual Basic application to Python/C/C++.


I have undertaken the task of dusting off a VB application I delivered to a client about 2 years ago and converting it to Python and C/C++. You might rightfully conclude from my previous blog entries that I am leaning toward Python/C and C++/LAMP as my development platform of choice. I do have a more favorable view of Python than Java or .NET, and I am just driven by curiosity about Python and C/C++ and what I am missing from my education about programming and systems design by having been stuck on VB 6 for the past 3 1/2 years.


So, yesterday, I started authoring a document about the application I am porting to Python/C/C++/MySQL. The application currently has 29 different GUI modules (I will avoid the use of the word "form", *ahem*), which might be reduced to about 26 or fewer GUI classes through code reuse. According to my document, the design and creation of the database in MySQL will come first, then the design of prototype GUIs. Then, the creation of the database services in C or C++ will be next, followed by the finalization of the GUI modules in the language we decide will be best for production(Python, C/C++, or Tcl).


Last night, I reviewed the table schemas in the database and am close to finishing a script for MySQL that will create the tables. The hard part of migrating the data might be in importing it into MySQL (the actual production DB is a SQL Server DB). Later, I started working with Tkinter in Python to learn how to create a GUI module and how to work with widgets. I couldn't resist the excuse to work with Python, I guess. I read a tutorial on Tkinter produced by John Shipman of New Mexico Tech, which I believe I found via Google, as well as chapters from Mark Lutz's book, Programming Python. I created my first form, with text and button widgets, and created event handlers to clear the text widgets when the Clear button is pressed, and to close the application when the Exit button is pressed. So far, so good.


It is indeed a different experience designing a GUI module with Python/Tkinter than it is with VB. No IDE to speak of, no property pages to access, no IntelliSense dropdown, no form designer. Everything is done in code. It might be a little hard to get used to at first, but the rewarding part about this approach to developing applications might well be the control that one has over the look and feel of the application. What I have discovered with Tkinter is that you really do have a lot of control over the appearance of your GUI app through setting attributes of widgets and the use of geometry managers. Tkinter has three geometry managers available, and the best practice appears to be to choose one of them and stick to it for each GUI class. Shipman urges the reader to choose the grid geometry manager, and all of his code samples use calls to grid to place widgets in the GUI modules. For me, grid is easy to use because it draws upon the concept of a table and table cells to create rows and columns and set the width and height of each cell. Widgets are placed within the cells of the grid and aligned or "stickied" within the cells according to the attributes specified.


When I look at the documentation for Tkinter, one thought crosses my mind: there certainly aren't very many widgets in the the Tkinter toolset. Maybe this is a misreading of the situation, but the doc from Lutz, Shipman, and Frederik Lundh (who also wrote a guide on Tkinter) seem to indicate that Tkinter only has 15 base widgets that are supported. If this is the case, we may want to look into using wxPython, wxWindows or Win32 when it comes to building the production app. However, Lutz also has some more sophisticated examples of GUIs written in Tkinter in his book, which I plan to examine to see what can be done with Tkinter. It seems to me, though, that wxWindows does have a more extensive library of widgets. The project I am working on porting to Python makes use of a few different ActiveX controls in VB, and wxPython and wxWindows might have something that is closer to this functionality than what Tkinter can deliver. One other possibility is whether Tk via Tcl might support more widgets.

Comments

Popular posts from this blog

Accomodating the Client

Working out how far to go to accomodate the client's needs. Despite my talk about how I have "fired" the industrial client, I have been working with them over the past three weeks on certain issues that they are having with the VB 6/SQL Server systems I helped to build. This support has been for free. It is becoming the scenario that I didn't want to get into-- having to support their system because the project champions at the client don't have enough technical competence to support the users, and the IT department is unwilling to support the application because "something better" is coming along soon. Despite my desire to wriggle free from this client, I can't, after all, just throw them overboard; I don't see that as being the responsible thing to do. I have also committed to helping them with the application that interfaces with the tool controllers, but I have made it clear that that application needs to be written in C++, in order to a

Back to the Future

What can Lisp teach us about the future of programming? For a while, Slashdot was a favorite web hangout of mine, and I racked up probably close to 100 posts. My attention to that favored web site of geekdom was interrupted two years ago by my mother's illness and decline, as well as by my concentration on several dev projects that took up a lot of what had been my spare time. Now that I am off my last project and have a little time, I have been visiting with Slashdot again. A visit to the front page of Slashdot the other day is leading to an examination by me of-- of all things-- Lisp. The story that led up to this was a link to an article written by Simeon Simeonov, who, I believe, was the author of the Cold Fusion web scripting language. He discussed how he thought that "Rich Internet Applications" were the way of the future, and how "Composite applications"-- mixing HTML with server-side code and database access-- is not the right programming model, bu

The Never-ending Battle

Hints at market share for Windows and Linux. In the wake of the attack of the Zotob worm, I saw a chart from Netcraft that tracked the uptime of Fortune 100 web servers over the previous 24 hours. Apparently there was no effect from Zotob among the Fortune 100, as the server that had the most downtime was running Sun Solaris, and that might have been taken down for maintenance. Zotob seemed to cause more trouble on the intranets of several media companies, as CNN reported on Zotob as if it were some cyber-Armageddon. As it turned out, CNN's LAN just got hit especially hard. Looking over the Netcraft chart is enlightening. In addition to uptimes and other network-related statistics, the operating system of each site is also listed. The dominant OS in the Fortune 100 is not Windows, but... Solaris. Solaris runs on 42 sites, Windows Server runs on 25 of the sites, Linux on 17, another flavor of Unix runs 5 sites, and 10 sites have an "unknown" operating system. My gu