Beefy Boxes and Bandwidth Generously Provided by pair Networks
Pathologically Eclectic Rubbish Lister
 
PerlMonks  

Re^3: Win32::GUI sending Windows messages between threads

by BrowserUk (Patriarch)
on Jan 17, 2013 at 17:18 UTC ( [id://1013823]=note: print w/replies, xml ) Need Help??


in reply to Re^2: Win32::GUI sending Windows messages between threads
in thread Win32::GUI sending Windows messages between threads [solved]

A quick Google indicates the only difference between PostMessage and SendMessage is that PostMessage returns immediately while SendMessage waits for the recipient to process the message.

You are correct, but you have missed the significance.

  1. SendMessage is a synchronous call.

    If the timer handler -- your custom function -- takes a long time to run, it will cause your GUI to freeze until it is finished.

  2. PostMessage() is an asynchronous call;

    The message is added to the queue and processed when it reaches the top. This allowing the originator of the message to do other things during the interim.


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.

Replies are listed 'Best First'.
Re^4: Win32::GUI sending Windows messages between threads
by Anonymous Monk on Jan 17, 2013 at 17:48 UTC
    My point was that the difference did not seem to be relevant to the fundamental problem that nothing seems to happen when I call SendMessage(). As I said, I tried it and nothing happened with PostMessage() either. If neither solves my problem, the difference is academic.

    ... or am I missing something?

      The problem is that you are tryiong to hook into a system/module defined API without understanding the rules and requirements of that API.

      Each window can have multiple timers associated with it. This, when the timer triggers and it sends the WM_TIMER message, it *must* also send some additional information as a part of that message that identifies which timer routine should be invoked to handle it. This is easily demonstrated by the following modification of your code which sets up two independent timers for the main window::

      Which when run produces the following output:

      C:\test>\perl32\bin\perl 1013733.pl bless({ "-handle" => 3213678, "-id" => 1, "-interval" => 10000, "-name +" => "Timer1" }, "Win32::GUI::Timer") bless({ "-handle" => 3213678, "-id" => 2, "-interval" => 20000, "-name +" => "Timer2" }, "Win32::GUI::Timer") [ bless({ # tied Win32::GUI::Window "-accel" => 0, "-handle" => 3213678, "-name" => "Main", "-timers" => { 1 => "Timer1", 2 => "Timer2" }, "-type" => 0, Timer1 => bless({ "-handle" => 3213678, "-id" => 1, "-interval" + => 10000, "-name" => "Timer1" }, "Win32::GUI::Timer"), Timer2 => bless({ "-handle" => 3213678, "-id" => 2, "-interval" + => 20000, "-name" => "Timer2" }, "Win32::GUI::Timer"), }, "Win32::GUI::Window"), "Timer1", ] Timer fired [ bless({ # tied Win32::GUI::Window "-accel" => 0, "-handle" => 3213678, "-name" => "Main", "-timers" => { 1 => "Timer1", 2 => "Timer2" }, "-type" => 0, Timer1 => bless({ "-handle" => 3213678, "-id" => 1, "-interval" + => 10000, "-name" => "Timer1" }, "Win32::GUI::Timer"), Timer2 => bless({ "-handle" => 3213678, "-id" => 2, "-interval" + => 20000, "-name" => "Timer2" }, "Win32::GUI::Timer"), }, "Win32::GUI::Window"), "Timer2", ] Timer fired [ bless({ # tied Win32::GUI::Window "-accel" => 0, "-handle" => 3213678, "-name" => "Main", "-timers" => { 1 => "Timer1", 2 => "Timer2" }, "-type" => 0, Timer1 => bless({ "-handle" => 3213678, "-id" => 1, "-interval" + => 10000, "-name" => "Timer1" }, "Win32::GUI::Timer"), Timer2 => bless({ "-handle" => 3213678, "-id" => 2, "-interval" + => 20000, "-name" => "Timer2" }, "Win32::GUI::Timer"), }, "Win32::GUI::Window"), "Timer1", ] Timer fired

      That suggests the possibility that the (Win32::GUI defined) window procedure arranges for the system defined timer to include a numerical 'timer id' as a part of the WM_TIMER message. It then looks up that id in the -timers hash associated with the target window to obtain the name of the blessed timer object, and then uses that to obtain the information passed onto the -onTimer callback routine.

      I've tried passing various combinations of id and name on the SendMessage WM_TIMER caller, but have yet to find the correct combination to allow me to trigger tha callback. I suspect that if you dug around in the Win32::GUI sources -- the only reliable documentation I have found for that module -- you might be able to discover the correct magic to allow you to manually trigger the callback, but sending a bare WM_TIMER will not do it. And is not intended to do so.


      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.
Re^4: Win32::GUI sending Windows messages between threads
by shadrack (Acolyte) on Jan 17, 2013 at 20:36 UTC
    I can't seem to reply to your last message for some reason, but I am aware of the timer ID issue and I did try several different values for wParam and lParam even before my initial post. None of them seemed to be any more effective than using 0, 0, and some even blew up perl, so I left them out of the example. Anyway, I solved the problem by using a different message all together (WM_USER) as is (now) detailed in the OP. Thx.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://1013823]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others romping around the Monastery: (4)
As of 2024-03-19 11:16 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found