Hi all,

I'm out of normal net communication, so am making use of what forums I can.

I'm working on some modules and am finding that I can strange behavior from Windows while using SendMessage and SendMessageTimeout when interacting between threads. Here is the basic scenario:

Thread1:
Is doing normal things and calls SendMessageTimeout() from within a WndProc.

Meanwhile Thread2:
Calls a SendMessage to a window in Thread1 that uses the same WndProc that is currently sitting in SendMessageTimeout.

And now for some reason, Down in the guts of User32.dll the system decides to switch contexts in Thread1, and jumps from SendMessageTimeout() and processes the message that Thread2 sent to the same WndProc. This of course wrecks havoc on my data structures. And there is no way to block it, because it is running in the same thread, so critical sections don't help. It is extremely odd. In the debugger looking at the call stack, I verify that this is the order of things. in Thread1 I'm in my WndProc, I call SendMessageTimeout() then there are some User32 interal happens and Kernel stuff, then all of the sudden without ever returning from SendmessageTimeout Im' back in my WndProc processing the other message sent from Thread2. BLEH!

Anyway, help is appriciated. I'm trying to get some coding done, but this is really holding things up...

chris

On the off chance that you missed it, are you using SMTO_BLOCK? (and not SMTO_NORMAL)

Ah, I should use SMTO_BLOCK I think. I'm using SMTO_NORMAL right now. Thanks, I don't know how I missed it. I looked at that, and I guess it just didn't click at the time. Hopefully this takes care of it. My internet access is quite sporadic, so it may be another couple of days before I can post the results. :)

Using SMTO_BLOCK seems to have fixed the problem. Although it was hard to duplicate the problem a lot, since it is all timing dependant, so I'm not 100% sure. In any case, it makes sense that this fixed it, as SMTO_BLOCK does not allow other sent messages to be processing durin the duration of the SendMessageTimeout call, which should fix the problem being experienced.

Thanks for pointing in the right direction.

Good to hear :) Bugs with threading really suck :P