smcone has asked for the wisdom of the Perl Monks concerning the following question:

Fellow Monks,

Im a 'medium' skilled Perl developer who just finished my first port of a cgi-based shopping cart to a windows based product using the powerful Win32::GUI modules and GUI::loft.

Im very pleased with the end result, but I need some feedback/help on what to do about focus on the main window and the appearance to the end user of 'hanging' during background operations.

This program is very "internet" heavy and has quite a few operations that use a background process for Net::FTP as well and LWP.

During usability testing - I noticed there is a problem of the software doing Net::FTP functions and 'freezing' the entire window during the operation. I assume this is because 100% of the process is dedicated to the Net::FTP command being executed.

The problem is - if my customers have slow connections, then the Win32::GUI widow will basically appear to 'hang' for however long the Net::FTP command is taking to execute. If it takes 30 seconds to login to a site, then my window is going to hang for 30 seconds.

I have tried to add a 'progress' bar and a 'popup status' text window that displays what is happening int he background, but this still does not help me for in-between operations - and hence the opportunities to update the progress bar/status window.

Worse - is that if someone changes focus to another window, then either the Win32:GUI window will just not respond at all, or it comes back 'partially' drawn - and the user has to look at a blank/half-drawn window until the next time the progress bar updates - and even then the rest of the window is still messed up.

Everything always returns to normal when Net::FTP is done whatever its doing - but i think people will be frustrated for the 30-60 seconds my script is showing a messed up window while it does its thing in the background.

So - my questions:

- Do I have 'any' control of re-drawing or capturing input from the user (such as a 'stop' button) whilst in the middle of a NEt::FTP command via the Win32::Gui window?

- Is there any way to prevent 'hanging' of other window areas during the Net::FTP processes?

- Is there anything I can do about the window getting messed up visualy when someone changes focus to a nother app while they are waiting - and then they change back to the win32 window?

- Is there a way I can abort a Net::FTP process that has gotten 'stuck' due to a dropped connection or other problem, without waiting for the 'time-out' (Guess what - this completely locks up the win32::gui window as well) forcing the program to have to be terminated via windows task manager.

Thanks in advance for your help - looking forward to building more apps in Win32::GUI if I can get past this issue.. Steve

Replies are listed 'Best First'.
Re: Win32::GUI and Focus Problems
by BrowserUk (Patriarch) on Mar 24, 2005 at 11:10 UTC

    use threads. This is exactly what they are designed for.

    Have your gui message loop run in the main thread and run the ftp code in a separate thread.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco.
    Rule 1 has a caveat! -- Who broke the cabal?
Re: Win32::GUI and Focus Problems
by jplindstrom (Monsignor) on Mar 24, 2005 at 12:18 UTC
    All your problems seems to stem from the fact that Win32::GUI::DoEvents() isn't called during the operation. Like BrowserUK says, threads is exactly the right solution to this problem, but you need to be a bit careful to not mess upp the Win32::GUI XS code.

    On the win32-gui-users list I recently posted two entries about my first attempt and the resulting module to do this in a fairly neat way.

    It uses Thread::Queue to communicate between the main thread (the GUI) and worker threads that perform the long-running operations.

    The demo application does a GET and updates the GUI (which stays responsive) with a progress bar while getting each chunk of data. It can be cancelled with a Cancel button in the GUI.

    This works because LWP provides callbacks to allow this. If the module you wanted to use does the same it should be a fairly simple task to adapt the demo program to your situation.

    /J

      Thanks alot for this feedback

      I will take a look at how you did it,it will definitely solve my problem.

      Thanks again. Steve