When I embarked on my programming project, I had hoped that my choice of wxPython would make it possible for me to run my program without too much difficulty on Linux, Win XP, Win Mobile, and OSX, but so far I have not been able to get it to run reliably on even one platform, least of all winCE. I had high hopes for the port recently announced by Ingmar Steen, but so far, at least, it suffers from the same problems that the earlier port had (although many other things are working better). Even the version that runs on XP has problems that don't seem to be getting resolved. Unfortunately, I am getting close to crunch time, so I can't wait much longer in the hope that a bug-free port will appear. Accordingly, I am beginning to cast about for a fallback.
I have seen references here to Pythonwin, but I am not familiar with it. I gather that it contains the module win32gui and, if I understand correctly, that module provides an interface to the MFC routines for creating a GUI. I understand that wxPython uses native routines to actually draw the GUI elements, so if I am reasoning correctly it follows that wxPython is calling the same routines that I could call directly using win32gui. Thus, I should be able to do with win32gui anything that I am doing with wxPython -- unless win32gui is not complete. What I lose by using win32gui rather than wxPython is portability, but perhaps I would have better luck getting the program to run reliably on winCE. Is this reasoning correct? It looks as if the best documentation for Pythonwin is the book by Mark Hammond and Andy Robinson, but I note that it was published over 6 years ago. Is it still sufficiently current to be useful? Does anyone know whether a new edition is scheduled to appear soon? Is there more current documentation somewhere? Does Python Programming on WIN32 do an adequate job of explaining how to build GUIs using win32gui, or do I need documentation for the relevant portion of MFC as well? I hate the thought of rewriting my code again for a different GUI library. I was happy using Qt on a Sharp Zaurus running Linux, but when Sharp withdrew the Zaurus from the US market I could not find a suitable substitute. The only alternative I can think of in my current dilemma is to try to fix the bugs in the wxPython port myself, but I doubt that I have the skill. Still, I might give it a try (if the author is willing) before embarking on yet another rewrite. I would even consider hiring a consultant to work on the port, though previous efforts along this line have not borne fruit. -- View this message in context: http://www.nabble.com/Seeking-alternative-to-wxPython-tf2143593.html#a5917335 Sent from the Python - pythonce forum at Nabble.com. _______________________________________________ PythonCE mailing list PythonCE@python.org http://mail.python.org/mailman/listinfo/pythonce