> 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.
If you are having problems with Windows XP, it would be brave to hope that Windows CE would have *less* problems <wink>. > 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. Pythonwin and the win32ui module are MFC wrappers, and I suspect you will have some problems getting these to work on CE. The win32gui module (poor module names, I know...) wraps the native win32 GUI api and does not rely on MFC at all. As a result, it is fairly low-level, but is also less likely to get in your way too much. > 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 That is true to some extent - although the effort may be significantly more than you expect. I believe the widget set in wx is larger than Windows itself provides - which would mean wx implements these widgets itself using the 'lower-level' widgets (or even just the low-level drawing routines) as a framework. You theoretically could reimplement all such widgets using win32gui - but depending on the widget, that would be very difficult. In some cases, win32gui may not be complete enough to do everything - it doesn't cover *all* win32 GUI functions (but does cover the majority of the useful ones) > 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 depends on exactly what your program needs to do. Without knowing why wx fails on CE for you, I can't speculate if the same thing would be any easier using win32gui. > 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? The book doesn't cover win32gui in any detail at all - it does cover Pythonwin/win32ui in some detail, but that isn't what you want to use. We are starting work on a new edition this year, but that is unlikely to cover win32gui in any detail - the point of win32gui is a thin wrapper around the windows API, and the intent of the book is not to document that API. Similarly, the documentation that does existing for Pythonwin/win32ui doesn't attempt to be a tutorial in MFC programming - Microsoft already has lots of documentation on that. > Is there more current documentation somewhere? As above, given it is a thin wrapper, the only Python relevant documentation covers things like argument and return-value handling. There will be no attempt (by me) to write a tutorial on low-level win32 UI development. > 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? The latter. > 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. If you can't get a Windows XP version working the way you want, I suspect you have a lot of work ahead of you to get a CE version working the way you want. If your only problem was that the CE port failed in some fundamental way (eg, failed to load), then I expect it would be a much simpler thing to fix. I've no real wx experience though. Sorry I can't offer more concrete advice, but I hope this helps anyway... Mark _______________________________________________ PythonCE mailing list PythonCE@python.org http://mail.python.org/mailman/listinfo/pythonce
