Re^3: Win32::GUI window freezing, even with threading. (Wrong solution)

This is how I set it up initially (because I didn't even know about threading). The data is added to the message queue to be processed by Win32::Gui to be processed when it gets around to it. My problem is whenever there is a WWW::Mechanize get call the gui would freeze. There's nowhere to add a DoEvents() call because the offending section of code is only one line (my $response = $mech->get( $url );) that takes a couple seconds to finish.

A solution was posted below, but I'd love to learn more about Win32::GUI, if you're up to it (documentation and discussion is a bit sparse).

Comment on Re^3: Win32::GUI window freezing, even with threading. (Wrong solution) Download Code

Replies are listed 'Best First'.
Re^4: Win32::GUI window freezing, even with threading. (Wrong solution) by BrowserUk (Patriarch) on May 28, 2013 at 13:50 UTC
There's nowhere to add a DoEvents() call because the offending section of code is only one line (my $response = $mech->get( $url );) that takes a couple seconds to finish. Using a thread to allow your GETs to run asynchronously from your GUI is a good idea. Using a queue to ship the data back to the gui thread for adding to the listbox is both unnecessary (you can add it from the same thread as you get it); and totally flawed if you use the blocking dequeue() call to fetch the data to be added, because that call blocks. You could use dequeue_nb(), but that creates its own set of problems. I'd love to learn more about Win32::GUI, if you're up to it I long ago gave up on Win32::GUI because the lack of documentation made every minor code addition or change a nightmare of searching for examples, and trial and error. As for what to use as an alternative, I mostly do without. But were I to have a need for a gui that could not be avoided, I probably plump for using HTML5 and the browser. With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday' Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error. "Science is about questioning the status quo. Questioning authority". In the absence of evidence, opinion is indistinguishable from prejudice.	[reply]

Replies are listed 'Best First'.

Re^4: Win32::GUI window freezing, even with threading. (Wrong solution)
by BrowserUk (Patriarch) on May 28, 2013 at 13:50 UTC

There's nowhere to add a DoEvents() call because the offending section of code is only one line (my $response = $mech->get( $url );) that takes a couple seconds to finish.

Using a thread to allow your GETs to run asynchronously from your GUI is a good idea.

Using a queue to ship the data back to the gui thread for adding to the listbox is both unnecessary (you can add it from the same thread as you get it); and totally flawed if you use the blocking dequeue() call to fetch the data to be added, because that call blocks.

You could use dequeue_nb(), but that creates its own set of problems.

I'd love to learn more about Win32::GUI, if you're up to it

I long ago gave up on Win32::GUI because the lack of documentation made every minor code addition or change a nightmare of searching for examples, and trial and error.

As for what to use as an alternative, I mostly do without. But were I to have a need for a gui that could not be avoided, I probably plump for using HTML5 and the browser.

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

[reply]