GetMessagePos vs GetCursorPos

[Gary Beene]

I read this in an '04 post from Lance.

For example, if you want to know <U>where the cursor was positioned when the current message was generated/queued</U> then use the GetMessagePos() API {as opposed to GetCursorPos() which may only tell you where the cursor has wandered off to in the time between the current message being generated and when the Callback Function/WndProc() code would call GetCursorPos()}

Reading this, I'd assume that I could use GetMessagePos in a callback to get mouse position while responding to a message.

But how do I know that the GetMessagePos is sync'd to a message in the callback function? Does my app go on hold, not calling the next message in the queue, and is not using GetMessage() again, such that I'm guaranteed that GetMessagePos corresponds to the message I'm responding to in the callback?

I don't know enough about what goes on in the background to know that nothing else will use GetMessage(), thus making GetMessagePos correspond to a different message.

And in general, even if GetMessagePos is the most accurate approach, is there any practical difference? Has someone used GetCursorPos instead of GetMessagePos and seen a specific "bad" result because of it? At the speed messages come to my app, my first guess would be that the difference is trivial, but I just don't know for sure.

In the samples distributed with PBWin, GetCursorPos is used mostly. I only saw GetMessagePos wasn't used at all.

[Michael Mattias]

Only one notification message at a time can be processed. The next message will not be processed until the current message is completely disposed of in your window procedure.

If you did not already know this, it is a good example of why everyone should do at least one application using "SDK-Style" windows.. because you could take ONE look at the standard message loop and see this instantly...

  WHILE GetMessage(Msg, %NULL, 0, 0)   ' wait for and get [B]one[/B] message.
    TranslateMessage Msg                      ' convert accelerator keys
    DispatchMessage Msg                       ' send message to window procedure
  WEND                                              ' loop to get next message.

This is the kind of stuff both 'DDT' and Microsoft Visual Basic hide from you.

(Ok, so it's kind of hidden using the DialogBox[Indirect][Param] functions, too, but those functions themselves are shortcuts).

MCM

[Fred Harris]

Wm_mousemove

Not sure what you are trying to do Gary, but I've always been able to obtain mouse coordinates through the parameters to the Window Procedure during the WM_MOUSEMOVE message. See the docs on WM_MOUSEMOVE and WM_LBUTTONDOWN. I have to confess I've never used the Api functions you are asking about. Perhaps one of my tutorials would show you what you need that use the WM_MOUSEMOVE message. The two applicable ones are Tutorial Form2 and Tutorial Form2A...

http://www.jose.it-berater.org/smffo...hp?board=285.0

[Gary Beene]

Fred,

I also use the mouse messages normally. In fact, I was writing my own tutorials about using messages and was discussing how API could be used as an alternative. I was just looking at alternate ways of getting the information. No specific problem to solve at this time.

Michael,

I've read info about the SDK style look before, which is actually why I raised my question. Since I wasn't doing the loop myself, I didn't know what DDT was doing in the background - continuing to loop, passing messages on to the windows procedure that I wasn't seeing? I have this picture in my head of the DDT engine doing things, where I can't guarantee that GetMessagePos (which I call) is in sync with the messages that PB lets me see.

Thanks for the response guys!

[Gary Beene]

Having re-read my last comment, I realized there's a conspiracy theory behind my thinking.

Do all messages that Windows sends make it to the callback functions? Not a single one is skipped? Not a single one is removed/handled by the DDT engine without making it to the callback function? Does the DDT default message loop guarantee that I get all messages, none skipped, in the correct sequence?

Also, in other posts, we've discussed how if my callback doesn't handle a message, that the DDT engine does something - but I never saw a clear answer on whether it always (no exceptions) simply passes the unprocessed message to the default window procedure. When Help says the DDT engine "handles" messages, it doesn't say what that means. So I've already got this one mystery - something happening and I don't know exactly what it is.

Then, when Windows documentation sends a message to a window procedure and where I have a child control on a dialog, does Windows send the message directly to a child control callback address, or does the message get to the dialog first for as-yet-unclear pre-processing or redirection? Since the CB function gets information from somewhere, I assume that the dialog somehow receives the message first, extracts info, and then the dialog itself calls the child callback function.

I know that Help says the message goes to the child callback, but is that directly from Windows, or does the dialog class window procedure or compiler provide code that actually calls the child control callback.

With custom windows, where the programmer writes his own windows procedure, the answer seems straight-forward - that if the programmer doesn't do it, it doesn't get done. And that child controls get their messages directly from Windows, not by some pass-through scheme.

But with dialog windows, the handling of messages doesn't seem to be so straight-forward and that child controls are at the mercy of the dialog in terms of receiving messages.

I'd appreciate any clarification that comes to mind.

I can't say that that answers generally change any coding I might do, but the questions do explain why I asked the GetMessagePos question - uncertainty/undocumented background activity that affects the answer.

[Michael Mattias]

Do all messages that Windows sends make it to the callback functions?

With SDK style coding, yes. For DDT style coding, you'd have to ask PB but I'd guess "yes" on that, too.

Not a single one is skipped?

Nope. (see WM_PAINT discusssion which follows)

Not a single one is removed/handled by the DDT engine without making it to the callback function?

Not AFAIK.

Does the DDT default message loop guarantee that I get all messages, none skipped, in the correct sequence?

I'm pretty sure it does, but since it's proprietary technology, you don't really know unless the proprietor tells you.

However, on the sequence question, some notification messages (eg WM_PAINT) are discarded from the queue if WM_PAINT is the current message; plus there is the difference between queued messages and unqueued messages to think about... but you really don't have to think about these much at all.

But with dialog windows, the handling of messages doesn't seem to be so straight-forward and that child controls are at the mercy of the dialog in terms of receiving messages.

Pretty much ALL controls send notifications to the owning window and are not processed at the 'control' level except by the default window procedure.. which, for controls, is generally not accessed by the programmer... which is why programmers use standard controls instead of writing their own labels, edit boxes, listboxes, etc.

MCM