Win32::GUI, tell an event handler to stop

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

I am playing with a small app that pulls info from a database into a Win32::GUI::Grid . A GUI event triggers the SQL query, which may take several seconds to complete on large table/slow link.

Unfortunately, if I make another GUI event in the mean time, triggering another SQL query, the two get confused; The share a single DBI handle, create their own statement handles which execute in paralell. So far so good. Unfortunately, they both populate the same Win32::GUI::Grid and thus stomp all over each other.

I have tried using a global variable to "signal" the first event handler to abort when a second is called, but the first handler does not see the variable change. Perhaps they run as separate threads, I don't really know...

I imagine this is a fairly common pitfall when it comes to GUI programming, so what's the proper way to solve this?

Comment on Win32::GUI, tell an event handler to stop

Replies are listed 'Best First'.
Re: Win32::GUI, tell an event handler to stop by archfool (Monk) on Jul 03, 2007 at 18:28 UTC
The DBI docs specifically state that DBI is not thread safe, unless you open a separate DB handle in each thread.	[reply]
Re: Win32::GUI, tell an event handler to stop by traveler (Parson) on Jul 03, 2007 at 20:19 UTC
First, you could block events (and show a different cursor, background or something) until the first query completed. Another approach is to queue the requests and fire a new one off when each one completes. HTH, --traveler	[reply]
Re: Win32::GUI, tell an event handler to stop by halley (Prior) on Jul 05, 2007 at 12:58 UTC
Change your architecture from: `guicode --(event)--> dbiquery` [download] to: `guicode --(event)--> supervisor supervisor --> dbiquery` [download] Your supervisory code (in your "model" of an MVC pattern) needs to act as a guardian against illegal uses of its resources, such as the dbiquery capability. If two requests come in, then handle it safely. (1) don't process the second one, (2) enqueue the second one to happen subsequently, or (3) safely terminate the first one, if appropriate and possible. Don't assume dbiquery can do this for you. Don't weigh down your front-end code with this job, either, because today it's a Win32::GUI, tomorrow it's a CGI::Application, next year it's an AJAX::iPhone or whatever. If the backend has technical limitations, your data model's API should do all the supervisory checking. -- `[ e d @ h a l l e y . c c ]`	[reply] [d/l] [select]