Unfortunately the ActiveXWrapper_IE demo still dies. I find resizing it to be
the most reliable way to get it to die. If I eliminate all the callbacks from
the IE COM object it will run fine.
In my email app, I find if I avoid using ANY wxPython calls in the
OnStatusChange callback I can avoid death. I can't even call wxWakeUpIdle...
i tried it out but seems to be very unstable. I can see all kinds of errors
on the console and everything just hangs.
am using python2.1 with wxPython2.3 for python2.1
is someone using it for doing wxpython gui development?
Actually to answer your question, I have been using it for GUI devel on
Linux/Windows simultanously and it looks pretty stable?
So back to your stability question: send a sample script that bombs!
···
On Sun, 2002-01-06 at 00:31, Karthik Gurumurthy wrote:
hi all,
i tried it out but seems to be very unstable. I can see all kinds of errors
on the console and everything just hangs.
am using python2.1 with wxPython2.3 for python2.1
is someone using it for doing wxpython gui development?
I'm becoming fairly certain that the performance degradation that I am
encountering can't be laid at wx(Python|Windows)'s feet. I've had the
hybrid library installed for several dozen iterations now, still see the
degradation, but don't see any issues in the command shell. I have forced
some issues to ensure that it DOES work.
What it LOOKS like is that the PythonWin IDE doesn't like me even working on
wxWindows files -- I haven't tried running them from there (learned that
fast) but as long as the IDE is up, successive runs of wxPython programs
causes it to eat more and more CPU resources. Yesterday it was eating 10% of
my CPU in an idle state. Kill the IDE, system picks back up.
At any rate, I'm pretty sure wxPython is off the hook
This is now of academic interests; I had intended to create a program in
background and have a systray icon to call it up. After reexamining what I
was using it for, I decided that a systray icon would be a waste of
resources, so I'm going a different route.
Meanwhile, here was the original concept:
1) start up the application and set a sys tray icon up.
2) OPEN NO WINDOWS until the icon is double-clicked.
I can get the icon to initialize just fine, but it IMMEDIATELY disappears
unless I have a while 1: right after that. I'm sure that's not how it's
supposed to work Rifling through the demos yielded no useful hints on
this either.
Somebody give me a swift kick in the right direction, please.
What it LOOKS like is that the PythonWin IDE doesn't like me even working
on
wxWindows files -- I haven't tried running them from there (learned that
fast) but as long as the IDE is up, successive runs of wxPython programs
causes it to eat more and more CPU resources. Yesterday it was eating 10%
of
my CPU in an idle state. Kill the IDE, system picks back up.
At any rate, I'm pretty sure wxPython is off the hook
That's good to hear, but I don't see how PythonWin could have any problems
if the wxPython stuff is running from a different process. That is really
weird!
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
This is now of academic interests; I had intended to create a program in
background and have a systray icon to call it up. After reexamining what I
was using it for, I decided that a systray icon would be a waste of
resources, so I'm going a different route.
Meanwhile, here was the original concept:
1) start up the application and set a sys tray icon up.
2) OPEN NO WINDOWS until the icon is double-clicked.
I can get the icon to initialize just fine, but it IMMEDIATELY disappears
unless I have a while 1: right after that. I'm sure that's not how it's
supposed to work Rifling through the demos yielded no useful hints on
this either.
The MainLoop will automatically exit if there are no top level windows left,
or created yet. In your app you could create but not show the main frame
when the task bar icon is created, and then show/hide it in response to the
task bar icon's events. Another possibility is to call
wxApp.SetExitOnFrameDelete(false) but then you'll have to explicitly exit
the app when you want to close it down.
Somebody give me a swift kick in the right direction, please.
Did that hurt? <wink>
···
--
Robin Dunn
Software Craftsman
robin@AllDunn.com Java give you jitters? http://wxPython.org Relax with wxPython!
That's good to hear, but I don't see how PythonWin could have any problems
if the wxPython stuff is running from a different process. That is really
weird!
Indeed it is! It may simply be that I've been doing a LOT of reloads with
wxPython projects in comparison to the past (i.e. not really related) but
I'm not totally convinced. I'm going to be keeping a suspicious eye on
things for a while. Might be just the general suckiness of WinME, wouldn't
be the first time.
