At 10:54 AM 5/3/01, [EMAIL PROTECTED] wrote: >Dear Morbus, >Thank you for your email. >> In essence, LWP uses a blocking call to do whatever it's trying to do. >> Meaning that while LWP is running, Win32::GUI isn't listening to >> events, which is why the window appears to freeze (it's really just >> not listening to your mouseclicks or your window focus). > >I do not think it is a problem of LWP but Win32::GUI. because >when I used to run very similar procedure as a CGI script under >Apache web server, that is without Win32::GUI ,there were not >such problems.
Right - that's my point. When you were running your CGI script through Apache, you weren't using Win32::GUI. Apache spawns your CGI script as a new process, so LWP can take as long as it wants without interfering with everything else.
As soon as you run Win32::GUI, you've got to have one stream of consciousness listening to all the events happening in Windows. It has to listen to mouseclicks, focus events, window grabs, and all that crap. This is a constant "all the time" process.
LWP, on the other hand, takes over totally. It becomes the "all the time" process the moment it runs. You can't (easily) have two "all the time" processes running at the same time, so LWP "wins" since it's the latest/newest one.
With LWP being the "all the time", Win32::GUI can't listen to all the crap that's going on, so it doesn't know that it's supposed to refresh the screen or listen to your mouseclicks or so forth.
It's not a problem with Win32::GUI or LWP really. Both are doing what they're supposed to do. And they conflict because of that. If you want your window to stop freezing, you have to figure out how to have Win32::GUI and LWP listen "all the time" at the same time.
Morbus Iff .sig on other machine. http://www.disobey.com/ http://www.gamegrene.com/
