Win32::GUI

Hi,

If you are doing the processing in a loop, you can call DoEvents which will unfreeze the window and process all events currently in the queue. This approach would only work if the call to DoEvents happens frequently enough while you are processing. The alternative approach is to use threads. As long as you are using a modern perl (ie, 5.8.7+) and the latest version of Win32::GUI you should have no problems with  threads.

Cheers,

jez.

________________________________
From: perlrob@...
To: perl-win32-gui-users@...
Date: Tue, 17 Jun 2008 21:38:50 -0600
Subject: [perl-win32-gui-users] Avoid the appearance of a "frozen" window


Hi
all,

I’m
curious: how do you prevent your window from looking like it’s frozen
during lengthy operations? For example, suppose a user clicks a button that
will trigger a very long event, such as copying a 10 GB file. While the really
long event is underway, how do you free up your window so that it doesn’t
appear unresponsive? I usually resort to writing two separate programs--the GUI
and a “worker”--and I just launch the worker when needed.







I
realize threads are an option, but in my experience they are not always
reliable (many Win32::GUI modules don’t seem to be thread-safe).







Thanks,



Rob








_________________________________________________________________

http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/

I've had some luck doing this using fork() and a pipe to communicate  
between the (pseudo) processes.  On Win32, fork is emulated using perl  
threads.  So it's basically the same thing.  I haven't tested this on  
Perl 5.10 yet, but I've had a gui application built this way running  
and in use for more than 18 months now.

Create and layout the window before spawning a new process/thread, as  
both pseudo processes can use the same gui handles.  After the  
thread/fork instantiate the non threadsafe modules. (Like opening a  
DBI connection).

Thanks,
Charles Alderman


----- Original Message -----
From: Jeremy White <jez_white@...>
Sent: Wed, 18 Jun 2008 14:58:46 +0000
Re: Re: [perl-win32-gui-users] Avoid the appearance of a "frozen" window



>
> Hi,
>
> If you are doing the processing in a loop, you can call DoEvents   
> which will unfreeze the window and process all events currently in   
> the queue. This approach would only work if the call to DoEvents   
> happens frequently enough while you are processing. The alternative   
> approach is to use threads. As long as you are using a modern perl   
> (ie, 5.8.7+) and the latest version of Win32::GUI you should have no  
>  problems with  threads.
>
> Cheers,
>
> jez.
>
> ________________________________
> From: perlrob@...
> To: perl-win32-gui-users@...
> Date: Tue, 17 Jun 2008 21:38:50 -0600
> Subject: [perl-win32-gui-users] Avoid the appearance of a "frozen" window
>
>
> Hi
> all,
>
> I’m
> curious: how do you prevent your window from looking like it’s frozen
> during lengthy operations? For example, suppose a user clicks a button that
> will trigger a very long event, such as copying a 10 GB file. While   
> the really
> long event is underway, how do you free up your window so that it doesn’t
> appear unresponsive? I usually resort to writing two separate   
> programs--the GUI
> and a “worker”--and I just launch the worker when needed.
>
>
>
>
>
>
>
> I
> realize threads are an option, but in my experience they are not always
> reliable (many Win32::GUI modules don’t seem to be thread-safe).
>
>
>
>
>
>
>
> Thanks,
>
>
>
> Rob
>
>
>
>
>
>
>
>
> _________________________________________________________________
>
> http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> Perl-Win32-GUI-Users mailing list
> Perl-Win32-GUI-Users@...
> https://lists.sourceforge.net/lists/listinfo/perl-win32-gui-users
> http://perl-win32-gui.sourceforge.net/
>

On Wed, 18 Jun 2008, Charles Alderman wrote:
> I've had some luck doing this using fork() and a pipe to communicate
> between the (pseudo) processes. On Win32, fork is emulated using perl
> threads. So it's basically the same thing. I haven't tested this on
> Perl 5.10 yet, but I've had a gui application built this way running
> and in use for more than 18 months now.
>
> Create and layout the window before spawning a new process/thread, as
> both pseudo processes can use the same gui handles.

You are not really supposed to use GUI handles from a thread that doesn't
own them (the one that has created them).  While "read" access is generally
safe, modifying GUI objects from non-owning threads isn't.  For example:

    http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx

Cheers,
-Jan

----- Original Message -----
From: Jan Dubois <jand@...>
Sent: Wed, 18 Jun 2008 10:58:28 -0700
Re: RE: [perl-win32-gui-users] Avoid the appearance of a "frozen" window

> You are not really supposed to use GUI handles from a thread that doesn't
> own them (the one that has created them).  While "read" access is generally
> safe, modifying GUI objects from non-owning threads isn't.  For example:
>
>     http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx
>
> Cheers,
> -Jan
>
>

Sure, race conditions and IPC are always issues to consider in  
multi-threaded applications.  But, I don't think there is anything  
inherently flawed with pre-spawning off threads as event handlers for  
the various gui elements on a window.  Just build the app to not make  
changes to the window in those threads.

In fact, I feel like that's a preferred approach to spawning off a new  
thread after the main thread handles window events.  Pre  
spawning/forking/whatever shifts a lot of overhead to the application  
initial load time, which leads to a better user experience.  Users  
hate waiting after clicking.

All of this kind of feels like a hack to me (I know all of these  
problems have been solved a bajillion times before), but I don't  
consider myself a great GUI programmer.  I picked Win32::GUI because  
it gave me an easy on-ramp to building a "professional" looking  
windows gui application.  And this was the quickest, best way for me  
to get my code out the door... :)

Thanks,
Charles Alderman

> On Wed, 18 Jun 2008, Charles Alderman wrote:
> > I've had some luck doing this using fork() and a pipe to communicate
> > between the (pseudo) processes. On Win32, fork is emulated using perl
> > threads. So it's basically the same thing. I haven't tested this on
> > Perl 5.10 yet, but I've had a gui application built this way running
> > and in use for more than 18 months now.
> >
> > Create and layout the window before spawning a new process/thread, as
> > both pseudo processes can use the same gui handles.
> 
> You are not really supposed to use GUI handles from a thread that doesn't
> own them (the one that has created them).  While "read" access is generally
> safe, modifying GUI objects from non-owning threads isn't.  For example:
> 
>     http://blogs.msdn.com/oldnewthing/archive/2005/10/10/479124.aspx

Just to add that you can also spawn multiple threads, each creating their own Win32::GUI windows (with their own message queues) allowing each thread to have each an "instance" of the application. It might sound clunky, but it does scale well on dual/quad cores.

Cheers,

jez.

_________________________________________________________________

http://clk.atdmt.com/UKM/go/msnnkmgl0010000007ukm/direct/01/