Those concerned, If anyone would like I can provide a more detailed example of how all this works, and more properly per the use of Queues, as they are technically not needed in this demonstration ( I could have use the wparam and lparam )
Jason P. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Plum, Jason Sent: Monday, February 06, 2006 1:18 PM To: perl-win32-gui-users@lists.sourceforge.net Subject: RE: [perl-win32-gui-users] Multi-Threaded Example This is actually rather simple. Simple create a shared variable containing the a scalar handle to the window, and proceed to "Win32::GUI::SendMessage($ts_winHandle, WM_USER +2)" etc., thus allowing for no need to actually poll the Queue for status, as the message stack for the window will *tell* when there is an item in the Queue... Sorry I didn't include that in the example, as it was dated from before the weekend and I haven't been to this email account since then even though I have been working on the ideas in my spare time at home. Jason P. See Attached. -----Original Message----- From: Jeremy White [mailto:[EMAIL PROTECTED] Sent: Monday, February 06, 2006 12:04 PM To: Plum, Jason; perl-win32-gui-users@lists.sourceforge.net Subject: RE: [perl-win32-gui-users] Multi-Threaded Example >Actually it was a mistake, thanks for sending it! I was starting to >wonder where the blazes it went! > >Yes that restriction might be a bit of an issue, however I *suppose* >information on the control (not the control itself) could be serialized >and sent over a Queue to the process altering the control. I have yet to >test this. Be Careful. A few months back I hinted at some code that Rob had built that would make threading coding much easier for Win32-GUI apps. In light of your recent examples, I've dropped him an offlist mail suggesting that his code be available to more people. Although not complete, it is a great platform to build from. One of the problems that Rob's code solves is that one end of a thread message queue can be attached to a window meaning there are no sleeps or polling to check for new messages. Basically, it means that a working thread can fire events in the thread controlling the window, resulting in a very efficient and simple event driven threading model. Cheers, jez.
