ProcessMessages for a Separate AllocateHWnd() Window

[a***@aol.com]

I use AllocateHWnd to provide a separate window for message processing
from some hardware (& it works fine).

But in a procedure during execution of the main application I want to
ensure that all messages sent to that separate window have been
processed before moving on to another line of code.

In the main application I would use Application.ProcessMessages to
handle messages to the application, but does this ensure that the
messages to the separate window have all been handled.

AFAICS the answer is "No". AllocateHwnd calls CreateWindowEx without
specifying a parent window, so I would think it is on its own,
separate from the PeekMessage called by APP.ProcMess.

Any comments or direct help welcomed.

Alan Lloyd

[Maarten Wiltink]

Post by a***@aol.com
I use AllocateHWnd to provide a separate window for message processing
from some hardware (& it works fine).
But in a procedure during execution of the main application I want to
ensure that all messages sent to that separate window have been
processed before moving on to another line of code.
In the main application I would use Application.ProcessMessages to
handle messages to the application, but does this ensure that the
messages to the separate window have all been handled.
AFAICS the answer is "No". AllocateHwnd calls CreateWindowEx without
specifying a parent window, so I would think it is on its own,
separate from the PeekMessage called by APP.ProcMess.
Any comments or direct help welcomed.

From the sound of it, you have the problem figured out (unlike many
other posters), and the solution, too. So just copy the source of A.PM
and make it do what you want.

Groetjes,
Maarten Wiltink

[a***@aol.com]

Post by Maarten Wiltink
From the sound of it, you have the problem figured out (unlike many
other posters), and the solution, too. So just copy the source of A.PM
and make it do what you want.

OK (you are too kind <g>) thanks Maarten - but I'm not sure I'm in my
"knowledge comfort zone" on that.

1 I assume I use PeekMessage with the AllocHWnd handle specified to
get only those.

2 I assume that the AllocHwnd is in the same thread as my app (for
PeekMsg).

3 I assume that the message will have the AllocHwnd handle in it
already (that's why PeekMessage finds it)

4 I assume that I don't (as the singular App.ProcessMessage does) have
to do the "if Assigned(FOnMessage. . ." or the "if not
IsHintMsg(Msg) . . . " nor handle the quit message separately (DeAlloc
does that). (I have only a few hardware specific messages from the
hardware)

5 & finally that my ProcessHwndMessages can be a method or a
procedure.

Thanks

Alan Lloyd

[a***@aol.com]

Post by a***@aol.com
OK (you are too kind <g>) thanks Maarten - but I'm not sure I'm in my
"knowledge comfort zone" on that.
1 I assume I use PeekMessage with the AllocHWnd handle specified to
get only those.
2 I assume that the AllocHwnd is in the same thread as my app (for
PeekMsg).
3 I assume that the message will have the AllocHwnd handle in it
already (that's why PeekMessage finds it)
4 I assume that I don't (as the singular App.ProcessMessage does) have
to do the "if Assigned(FOnMessage. . ." or the "if not
IsHintMsg(Msg) . . . " nor handle the quit message separately (DeAlloc
does that). (I have only a few hardware specific messages from the
hardware)
5 & finally that my ProcessHwndMessages can be a method or a
procedure.

Maarten

Looking at the PeekMessage in App.ProcMsg, I think that App.ProcMsg
clears the queue for the AllocateHWnd as well, please say if you
agree.

In MSDN Library the hWnd parameter of PeekMessage has the following
comment :

"hWnd
[in] Handle to the window whose messages are to be examined. The
window must belong to the current thread.
If hWnd is NULL, PeekMessage retrieves messages for any window that
belongs to the current thread. If hWnd is INVALID_HANDLE_VALUE,
PeekMessage retrieves messages whose hWnd value is NULL, as posted by
the PostThreadMessage function."

Surely the AllocateHWnd window belongs to the current (application)
thread. And PeekMessage() in A.PM specifies that parameter as 0 (ie
NULL). Therefore A.PM also clears the queue for the AllocateHWnd
window & I can use A.PM to do what I want.

If the above is correct, I'm sorry I wasted your time <g>.

Alan Lloyd

[Maarten Wiltink]

<***@aol.com> wrote in message news:4167d933-9863-42d3-aa16-***@z20g2000pra.googlegroups.com...
[...]

Post by a***@aol.com
In MSDN Library the hWnd parameter of PeekMessage has the following
"hWnd
[in] Handle to the window whose messages are to be examined. The
window must belong to the current thread.
If hWnd is NULL, PeekMessage retrieves messages for any window that
belongs to the current thread. If hWnd is INVALID_HANDLE_VALUE,
PeekMessage retrieves messages whose hWnd value is NULL, as posted by
the PostThreadMessage function."
Surely the AllocateHWnd window belongs to the current (application)
thread. And PeekMessage() in A.PM specifies that parameter as 0 (ie
NULL). Therefore A.PM also clears the queue for the AllocateHWnd
window & I can use A.PM to do what I want.
If the above is correct, I'm sorry I wasted your time <g>.

Well, I mostly listened to you proving it to yourself. (-:
Nothing left to do but try it out now, eh?

Groetjes,
Maarten Wiltink

[a***@aol.com]

Post by Maarten Wiltink
Nothing left to do but try it out now, eh?

Yes, it does work, and now I understand what "dispatching" a windows
message does. It looks up the WndProc associated with the window
handle in the message & calls WndProc with the message as parameter. I
ought to have known this but most technical desriptions on messaging
(and on most things) say _what_ something achieves with saying _how_
it does it.

Your comment "I mostly listened to you proving it to yourself"
underlines the issue with the "lone programmer" (and of course my
issue), and one of the most potent bug-killers - explaining your code
to another programmer.

Thanks, anyway, Maarten.

Alan Lloyd

[Maarten Wiltink]

<***@aol.com> wrote in message news:a84858b6-01e6-495e-8010-***@h16g2000vbz.googlegroups.com...
[...]

Post by a***@aol.com
Your comment "I mostly listened to you proving it to yourself"
underlines the issue with the "lone programmer" (and of course my

Been there, done that. Now I work in a place where they want me to
follow the rules, _their_ rules, and dumb myself down to other people.

Post by a***@aol.com
issue), and one of the most potent bug-killers - explaining your
code to another programmer.

Or even to the stuffed panda. (As one helpdesk reputedly had you do.
This seemed to solve most problems before the helpdesk itself had to
be bothered with them.)

Groetjes,
Maarten Wiltink

[Jamie]

Post by a***@aol.com
I use AllocateHWnd to provide a separate window for message processing
from some hardware (& it works fine).
But in a procedure during execution of the main application I want to
ensure that all messages sent to that separate window have been
processed before moving on to another line of code.
In the main application I would use Application.ProcessMessages to
handle messages to the application, but does this ensure that the
messages to the separate window have all been handled.
AFAICS the answer is "No". AllocateHwnd calls CreateWindowEx without
specifying a parent window, so I would think it is on its own,
separate from the PeekMessage called by APP.ProcMess.
Any comments or direct help welcomed.
Alan Lloyd

Yes, that will perform a message scan and the system will dispatch the
message to the appropriate window. Even if the message isn't for your
hardware window.. I guess if want your hardware window to have priority,
you could use the PeekMessage before allowing this...

Systems these days should be fast enough to just simply call the
ProcessMessages, with out worrying about other messages getting
processed to slow you down...

Of course, if you're doing some multilayer app like .NET I can
understand the concern..


Jamie..