Click here to Skip to main content
15,900,723 members
Home / Discussions / C / C++ / MFC
   

C / C++ / MFC

 
AnswerRe: My Visual Studio windows are all misplaced. Pin
Richard Andrew x6413-Mar-24 12:34
professionalRichard Andrew x6413-Mar-24 12:34 
GeneralRe: My Visual Studio windows are all misplaced. Pin
Maximilien14-Mar-24 2:44
Maximilien14-Mar-24 2:44 
GeneralRe: My Visual Studio windows are all misplaced. Pin
Richard Andrew x6414-Mar-24 2:52
professionalRichard Andrew x6414-Mar-24 2:52 
GeneralRe: My Visual Studio windows are all misplaced. Pin
RedDk16-Mar-24 11:21
RedDk16-Mar-24 11:21 
QuestionSendNotifyMessage() "queues" messages Pin
MikeBz12-Mar-24 5:53
MikeBz12-Mar-24 5:53 
AnswerRe: SendNotifyMessage() "queues" messages Pin
jschell12-Mar-24 14:55
jschell12-Mar-24 14:55 
GeneralRe: SendNotifyMessage() "queues" messages Pin
MikeBz18-Mar-24 0:26
MikeBz18-Mar-24 0:26 
QuestionDetermining reason for SendMessageTimeout() failure Pin
MikeBz12-Mar-24 0:37
MikeBz12-Mar-24 0:37 
If I call SendMessageTimeout() with the flag SMTO_ABORTIFHUNG and a finite timeout period then it could fail (return 0) due to either of these reasons:

1. Timeout (the thread which owns the window started processing the message but didn't complete it within the timeout period).

2. The thread which owns the window was considered to be hung, so didn't (and won't) process the message.

In the first case GetLastError() returns ERROR_TIMEOUT (1460). I can't find any error codes in winerror.h which look relevant to the second case (hung thread).

What I actually want to know, immediately after SendMessageTimeout() returns, is whether the thread which owns the window has or will actually start processing the message. I don't need nor want to wait until it has finished processing the message.

I've spent a couple of hours searching the web and reading various articles, questions etc. but not found an answer to this.

A little while later... I've set up a test case where the window owning thread is spinning in a loop, and then I call SendMessageTimeout(hWnd, WM_MY_MESSAGE, wParam, lParam, SMTO_NORMAL|SMTO_ABORTIFHUNG, 1000, &dwResult).

SendMessageTimeout() immediately returns 0 as expected, and calling GetLastError() returns [drumroll...] 18 (ERROR_NO_MORE_FILES)!!! Go figure...

So it seems there are 2 yucky ways to trap this:

1) Wrap a timer around the call to SendMessageTimeout(), and if it returns in less than the timeout period (1000ms in the example above) then we know it failed because the thread is hung.

2) Test GetLastError(), if it's ERROR_TIMEOUT then we know it's a timeout, if it's ERROR_NO_MORE_FILES then we assume it's because the thread is hung. Or maybe if it's NOT ERROR_TIMEOUT then assume it's because the thread is hung.

Method 1 is smells of kludge, method 2 relies on undocumented behaviour.

And while we are on undocumented behaviour, it seems that passing a timeout value of 0 means "infinite timeout" although no doc I can find for SendMessageTimeout() mentions that.

And some time later again... Well the behaviour is inconsistent. I've also had it fail (return 0) immediately with ERROR_TIMEOUT, and bizarrely sometimes fail immediately with error code 0 (ERROR_SUCCESS). This is Windows 10. It seems that all bets are off in trying to interpret the return value and/or error code.

modified 12-Mar-24 8:27am.

SuggestionRe: Determining reason for SendMessageTimeout() failure Pin
Richard MacCutchan12-Mar-24 5:50
mveRichard MacCutchan12-Mar-24 5:50 
GeneralRe: Determining reason for SendMessageTimeout() failure Pin
MikeBz12-Mar-24 5:52
MikeBz12-Mar-24 5:52 
AnswerRe: Determining reason for SendMessageTimeout() failure Pin
jschell12-Mar-24 15:01
jschell12-Mar-24 15:01 
GeneralRe: Determining reason for SendMessageTimeout() failure Pin
MikeBz17-Mar-24 23:52
MikeBz17-Mar-24 23:52 
QuestionVS2022, I hate thee... not really but I do wish Microsoft would stop f'ing around with menus and process... - MDI app, ON_NOTIFY Pin
charlieg3-Mar-24 15:42
charlieg3-Mar-24 15:42 
QuestionRe: VS2022, I hate thee... not really but I do wish Microsoft would stop f'ing around with menus and process... - MDI app, ON_NOTIFY Pin
CPallini3-Mar-24 21:01
mveCPallini3-Mar-24 21:01 
AnswerRe: VS2022, I hate thee... not really but I do wish Microsoft would stop f'ing around with menus and process... - MDI app, ON_NOTIFY Pin
charlieg4-Mar-24 1:24
charlieg4-Mar-24 1:24 
QuestionC code "crashes"... Pin
Salvatore Terress3-Mar-24 7:08
Salvatore Terress3-Mar-24 7:08 
AnswerRe: C code "crashes"... Pin
Victor Nijegorodov3-Mar-24 8:05
Victor Nijegorodov3-Mar-24 8:05 
AnswerRe: C code "crashes"... Pin
k50543-Mar-24 10:35
mvek50543-Mar-24 10:35 
GeneralRe: C code "crashes"... Pin
Salvatore Terress3-Mar-24 14:13
Salvatore Terress3-Mar-24 14:13 
GeneralRe: C code "crashes"... Pin
k50544-Mar-24 0:51
mvek50544-Mar-24 0:51 
GeneralRe: C code "crashes"... Pin
Salvatore Terress4-Mar-24 2:12
Salvatore Terress4-Mar-24 2:12 
Questionme vs. VS2022.. detecting NULL pointers Pin
charlieg29-Feb-24 11:38
charlieg29-Feb-24 11:38 
AnswerRe: me vs. VS2022.. detecting NULL pointers Pin
charlieg29-Feb-24 12:11
charlieg29-Feb-24 12:11 
GeneralRe: me vs. VS2022.. detecting NULL pointers Pin
Richard Andrew x6429-Feb-24 12:53
professionalRichard Andrew x6429-Feb-24 12:53 
GeneralRe: me vs. VS2022.. detecting NULL pointers Pin
trønderen1-Mar-24 7:14
trønderen1-Mar-24 7:14 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.