In win32, what happens if a message is posted to a window handle after its been destroyed?
It's been said that DestroyWindow flushes the message queue? Will it flush only the messages posted to that window? It should be so right? If it flushes the entire message queue then if multiple windows are created by that thread, that would be problem right?
consider multiple windows are created with single message loop,
If I destroy a winow and post a message to that window handle what will happen? Will it be dispatched and crash?
Can someone explain me in-depth of Message queue?
Related
Let's say my Erlang application receives an important message from the outside (through an exposed API endpoint, for example). Due to a bug in the application or an incorrectly formatted message the process handling the message crashes.
What happens to the message? How can I influence what happens to the message? And what happens to the other messages waiting in the process mailbox? Do I have to introduce a hierarchy of processes just to make sure that no messages are lost?
Is there something like Akka's dead letter queue in Erlang? Let's say I want to handle the message later - either by fixing the message or fixing the bug in the application itself, and then rerunning the message processing.
I am surprised how little information about this topic is available.
There is no information because there is no dead letter queue, if you application crashed while processing your message the message would be already received, why would it go on a dead letter queue (if one existed).
Such a queue would be a major scalability issue with not much use (you would get arbitrary messages which couldn't be sent and would be totally out of context)
If you need to make sure a message is processed you usually use a way to get a reply back when the message is processed like a gen_server call.
And if your messages are such important that it would be a catastrophe if lost you should probably persist it in a external DB, because otherwise if your computer crashes what would happen to all the messages in transit?
I have an app which creates a thread which communicate with the main UI via windows messages. It simply send the message to the main app thread and received the status.
That way I am displaying modal windows and do other things.
The problem is when I have to display a form which makes a call to a com+ server.
That way I get OLE error 8001010D: An outgoing call cannot be made since the application is dispatching an input synchronous call.
I think it happens because primary SendMessage is in use and com+ calls need windows messaging for its tasks.
Anyway, In delphi I cannot display the form from a thread, but how Could I workaround the problem ... ?
Thanks
EDIT:
MAIN(UI) 2. A THREAD
A. A Thread(2) sends message to a main thread (1)
B. Main thread(1) receives the msg and before letting it come back to a thread
it displays the window.
C. The modal window in main thread wants to make a com+ call, the above error occurs.
What thread the modal window is in? 2. Which thread the COM call goes from? 3. Which thread the COM object was instantiated in? 4. Is the background thread initialized with an STA? 5. Is the modal form being shown from a SendMessage handler? – Roman R. 2 mins ago
MAIN
MAIN
MAIN
CoInitializeEx(nil, COINIT_MULTITHREADED);
yes.
The problem cause comes from inability of COM to marshal an outgoing COM call while processing SendMessage request. The error which comes up is RPC_E_CANTCALLOUT_ININPUTSYNCCALL (0x8001010D), which you are referring to. I was under impression that this only applies to SendMessage calls which are a part of incoming interthread COM requests, however this might have been a false assumption.
Your typical workaround would be to replace your SendMessage with PostMessage followed by waiting for synchronization object, event or semaphore. This way your caller background thread does not hold messaging to synchronize the calls and waits autonomously, on the main thread the message being dispatched through regular message queue and eventually reaches the same handler.
As a bonus, you have an option to safely terminate the background thread. If currently it's being locked by SendMessage API waiting for modal dialog, the suggested change would let you signal the synchronization object from the main thread and let it keep running, e.g. if you want to safely terminate it.
An alternate solution might be to call InSendMessage function and if true - defer modal UI, e.g. by again posting a message to self to pop the form up in another message handler later.
I have a DirectShow filter created with Delphi Pro 6 and the DSPACK direct show library. I'm running under windows XP. I've tried creating the form dynamically when the container class for the DirectFilter has its constructor called, passing NIL into the constructor as the AOwner parameter (TMyForm.Create(nil) and then calling the Form's Show() method. The form does show but then appears to stop receiving windows messages because it never repaints and does not respond to input. As a test I then tried creating my own WndProc() and overriding the Form's WndProc(). My WndProc() did get called once but never again.
I'm guessing it's because I'm a DLL and the context that I am running in is not "friendly" to the window message handler for the form; perhaps something to do with the thread that calls it or whatever. If someone could give me a tip on how to solve this or what the proper way to create a persistent window is from the context of a DirectShow filter I'd appreciate it. Note, as I said the window needs to be persistent so I can't create it as a Filter property page.
Thanks,
Robert
I can't help you with the DirectShow filter specifics, but I feel that some general information about windows and message handling might help.
Windows have thread affinity, which means that all messages for a window will be handled in the context of the thread that created it. That means that this thread needs to have the standard message processing loop, the low level equivalent of Application.ProcessMessages(). Both messages from the same and from other threads will be queued in the message queue of the creating thread, and the message loop will get them, (optionally) translate them, and dispatch them to the window handler of the target window.
What you are describing could be caused by either
not having a message processing queue in the thread that creates the window, or
creating the window in the wrong thread
(Note that these are essentially the same, but stated like this it becomes apparent that there may be different problems that cause this, which need to be fixed in different ways - either the window needs to be created in a different thread, or a processing loop needs to be created in the thread.)
You need to find out which of the two causes your window not to process messages. You don't necessarily need to override WndProc(), message handling methods for distinct messages will work (or not work) the same. That your WndProc() was called once doesn't really tell you much, because under some circumstances messages sent from the same thread will be handled without the message loop, by calling the window proc directly.
Since your filter resides in a DLL I don't think that creating your own message loop would be the right thing. This works for a modal dialog, which will be created, the message loop will run until the dialog is closed, and then the message loop will terminate and the DLL function will return. It will not work for a DLL exported function that will be called and needs to return all while the message loop is still running. I assume the framework that creates and calls those filters will handle the message loop as well. However, that is a gut feeling, not knowing about DirectShow filters this may well be wrong.
What might help you to debug this is a tool like Spy++ from Visual Studio, with which you can show information about windows, log messages sent to them or to all windows in the same process or thread, show window hierarchies and do a lot of other interesting things. If you don't have that, there are a lot of clones (some freeware) on the net, which Google should turn up. Trying to show the messages sent to all windows of the same thread or process should tell you whether a message loop is running. You should also be able to get more information by running SysInternals Process Explorer or similar tools.
I coding a service application that have two threads.
First thread, show a form with label.
Second thread, query ADO.
First thread always freezing with Hourglass cursor and no label caption.
Please help.
If you're trying to show a form from within a thread that is not the main thread, then you will run into strange things like this. The most notable of which is that if the form and label are created in the non-main thread, then you don't have a message loop to process the messages. If the form was created in the main thread, but you're attempting to show it from the non-main thread, then it is likely a dead lock due to how Windows deals with messages and threads.
When a window handle is created it is tied to the thread on which it was created. This means that Windows will ensure that any messages sent to that handle are processed on that thread.
I would strongly suggest you read up on how window messages, message queues, and handles all interact and function in a multi-threaded environment. If not done correctly, you are assured of some very odd and possibly unpredictable behavior.
I would call your condition either a Race, a Deadlock, or some other kind of error like that. As Allen says, if the background thread makes ANY direct access to the VCL controls, without using TThread.Synchronize(myMethod) to invoke the myMethod that touches your VCL foreground, then this alone would cause your trouble.
Post more information, including a sample of your code please.
I created a multichilded application. The application windows (W[n]: TMyWindows) are all the same and all have an private object class instance associated with them (E: TMyObject).
The child windows generate through this objects some messages. I have created in the main application two threads which process these messages depending on the content of the messages. For example lets have the following asynchronous calls:
W[1].E.Service(thread1service)
W[2].E.Service(thread2service)
the TMyObject.Service(servicetype) is
case servicetype of
thread1service: PostThreadMessage(thread1id,...);
thread2service: PostThreadMessage(thread2id,...);
end;
Now, in the Execute Method of each thread i have something like that:
while not terminated do
begin
...
if peekmessage(msg,0,thread1message_1,thread1message_n,pm_remove) then
process message
do other things;
end
All goes fine exept that the second thread doesn't receive any messages.
Do you have any idea why?
I would check to make sure that the range you are supplying to PeekMessage() is valid. Try putting zeros in instead to receive all messages, like this:
PeekMessage(msg, 0, 0, 0, PM_REMOVE)
If that doesn't work, I would check the result of the PostThreadMessage() function... It may be that the thread hasn't called PeekMessage() yet, that's what prompts windows to create the message queue for you.
As stated in this article (under "Remarks"), you can either check the result of the call to PostThreadMessage(), and Sleep() if it fails, or use an event to signal to the main thread that the child thread is ready to receive messages.
HTH,
N#
So, I had to give up as I didn't find any rational explanation.
I've decided to send messages using a critical section with event signaling to tell the working threads that they have a message to process. Unfortunately, this means that the main thread have to check that the working thread processes any message before sending a new one.
I know this is an old question, but I have just had a similar problem in our code. We are running Delphi 2006 on Win 7 64-bit and the code in question involved a DLL communicating to a separate application via peekmessage/postthreadmessage.
I eventually managed to trace the issue down to administrator rights being granted either to the application or to Delphi. Compatibility mode also causes the problem to surface, as it requires admin rights to be granted. If admin rights are granted, the admin thread could communicate to the non-admin thread, but the non-admin thread could not then post a message back to the thread with admin privileges. The PostThreadMessage call on the non-admin app was reporting success, but the message never appeared in the target app's message queue.
I haven't solved the problem, but fortunately was able to run the application in normal mode, so it wasn't an issue other than the lost time in chasing it down.