Re: Implement a SendMessage behaviour
- From: Faust <miss.me@xxxxxxxxxxxxxxxx>
- Date: Sun, 19 Jul 2009 02:23:42 +0200
Thanks a lot, and yes, I made a big mistake
first, you're absolutly right, I made a big mistake between SendMessage and PostMessage (my appologies to Ben too).
second, I know the call stack of a thread can't be empty but it was the simpliest way I found to explain the feature I needed. I meant I need as less as possible results of user actions in call stack of the thread that will run the new action. The goal is really to simulate a PostMessage: to wait all current actions (user click, timer event, etc) are finished before starting the next one. As soon as the next action is started, that's not a problem if the windows message queue receive some message as they will wait my current action ends to be proceed (unless I make some specific call in the new action to do it of course)
and third, the Idle event of Application seems to be exactly what i need (more than BeginInvoke as, if I'm not worng, it build a thread to run the delegate in the "same" time of the main thread)
I know it's not absolutly perfect because if my application is spammed with some windows messages, there're some chances that the Idle event never fire
but during the next 6 years, I'd never saw that case :)
thx again :)
/Après mure réflexion, _Peter Duniho_ a écrit/ :
On Sat, 18 Jul 2009 09:19:48 -0700, Faust <miss.me@xxxxxxxxxxxxxxxx> wrote:
/_Ben Voigt [C++ MVP]_ a exposé/ :[...]
SomeControl.BeginInvoke(SomeDelegate) would be equivalent to PostMessage, not SendMessage, but I think it is the behavior you are looking for.
thanks for the tip
but I really need an empty call stack when the actions are started (well, I needed that for a lot of reasons with Delphi; even if some are no more a problem with .net, I guess some are still)
Maybe you could describe your problem at a higher, more abstract level.
There's no such thing as "an empty call stack". By the time any of your code gets to execute there is always at least a little bit of call stack, and a GUI application is going to call as part of its first few actions a .NET method that starts processing the window message queue (e.g. Application.Run() for a Forms application), which will introduce even more frames to the call stack.
The call stack also has very little to do with the message queue, and your original post seemed to state you cared about the latter, not the former.
Also, your comments about SendMessage() are confusing, as SendMessage() does not in any way guarantee that by the time the message sent is actually processed that the window message queue is empty. In fact, a message sent via SendMessage() doesn't go through the message queue at all. If you call it from the thread that owns the window, it simply calls the window class's window proc directly, and if from another thread the OS simply ensures synchronization; it doesn't provide a guarantee that the message queue is empty when the window class's window proc is actually called.
Furthermore, there is no possible way to guarantee that the window message queue is empty at the time that a particular message is handled, whether that message was ever in the message queue or simply handled by a direct call to the window proc. The instant that a particular thread might _think_ that its message queue is empty, any code anywhere else could wind up queuing a message to the queue, just as the particular thread was about to start doing whatever "idle" processing is desired.
That's all a long way of saying that it is not literally possible to accomplish what you seem to be saying you want to accomplish, and that would be true for any Windows application.
Now, back to the basic things that _are_ possible:
-- In the unmanaged API there's SendMessage() and PostMessage(). SendMessage() being synchronous (doesn't return until the message is processed) and PostMessage() being asynchronous (returns immediately, the message to be processed later). In .NET, these are roughly equivalent to Control.Invoke() and Control.BeginInvoke(), respectively. There are obvious differences between the two paradigms, but in a very general sense that would be the mapping.
-- In .NET, you can using the Application.Idle event (http://msdn.microsoft.com/en-us/library/system.windows.forms.application.idle.aspx) to detect when the message pump believes that the message queue is empty and the application is about to enter an "idle" state. That event will _not_ guarantee to you that there are in fact no messages in the queue when your code executes, but then you never had that guarantee before. I suspect that this event is the closest equivalent to what you were using before, and would probably suffice for your purpose.
If the above doesn't help you, then you will probably have to provide a more abstract, less implementation-specific description of what it is you're really trying to accomplish. It's often difficult to provide good advice when the question is presented as a specific implementation that the questioner has already chosen, even if that implementation isn't appropriate.
Pete
--
*/Teträm/*
http://www.tetram.org
"Ecoute toujours ton estomac, c'est quelqu'un de confiance" - Proverbe Troll
.
- Follow-Ups:
- Re: Implement a SendMessage behaviour
- From: Peter Duniho
- Re: Implement a SendMessage behaviour
- References:
- Implement a SendMessage behaviour
- From: Faust
- Re: Implement a SendMessage behaviour
- From: Ben Voigt [C++ MVP]
- Re: Implement a SendMessage behaviour
- From: Faust
- Re: Implement a SendMessage behaviour
- From: Peter Duniho
- Implement a SendMessage behaviour
- Prev by Date: Re: ExecutorService for C#?
- Next by Date: Re: Iterating through IP addresses on a server when screen scraping
- Previous by thread: Re: Implement a SendMessage behaviour
- Next by thread: Re: Implement a SendMessage behaviour
- Index(es):
Relevant Pages
|
