GetQueueStatus
-
How can I get status of the queue from another thread? I have one worker thread A and UI thread B. Now I need in A find status of message queue of B. Thanks. :)
Ideally, thread A should post a message to thread B asking about it's queue status. Thread B should then respond by posting a message back to thread A with the status. Make sense?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-
Ideally, thread A should post a message to thread B asking about it's queue status. Thread B should then respond by posting a message back to thread A with the status. Make sense?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
If B freeze or busy I will overwhelm its queue which could at that moment already full. I am trying to minimize any message exchange. David BTW do you know how exception mechanizm colapsing/destroing stack up to the first catch? I think it could help me to solve problem. Thanks. :)
-
If B freeze or busy I will overwhelm its queue which could at that moment already full. I am trying to minimize any message exchange. David BTW do you know how exception mechanizm colapsing/destroing stack up to the first catch? I think it could help me to solve problem. Thanks. :)
Alex_Y wrote: If B freeze or busy I will overwhelm its queue which could at that moment already full. While message queues do have an upper limit (10,000 per MSDN), I've never heard of one being filled up, unless it had underlying problems. In any case,
PostMessage()
will returnFALSE
if the queue is indeed full.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-
Alex_Y wrote: If B freeze or busy I will overwhelm its queue which could at that moment already full. While message queues do have an upper limit (10,000 per MSDN), I've never heard of one being filled up, unless it had underlying problems. In any case,
PostMessage()
will returnFALSE
if the queue is indeed full.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
:) I know for sure that there is underlying problem. I want do the work around because one of the ocx controls in UI thread freezing. I already subclass windproc, but I never know on what message third party control will freez. Messages which is comming from message loop is "peace of cake". I can skip them if I already know from subclassing that control is busy, but most hassel is Send messages which is comming from parent/Windows which goes directly to the WindProc. I never know how log that particular message will spend in ocx control. I find that send/post message don't improves situation if control already stuck. Even if you send WM_NULL just to make sure that message loop in still alive. Thanks. P.S. Sometimes sharing with somebody is giving feeleng that you solve half of problem. :) :)
-
:) I know for sure that there is underlying problem. I want do the work around because one of the ocx controls in UI thread freezing. I already subclass windproc, but I never know on what message third party control will freez. Messages which is comming from message loop is "peace of cake". I can skip them if I already know from subclassing that control is busy, but most hassel is Send messages which is comming from parent/Windows which goes directly to the WindProc. I never know how log that particular message will spend in ocx control. I find that send/post message don't improves situation if control already stuck. Even if you send WM_NULL just to make sure that message loop in still alive. Thanks. P.S. Sometimes sharing with somebody is giving feeleng that you solve half of problem. :) :)
Is
SendMessageTimeout()
of any help?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
-
Is
SendMessageTimeout()
of any help?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
I was trying to resend to myself message by SendMessageTimeOut and it never expired. I found on msdn that timeout is disabled if you doing within the same thread. :) Remarks The function calls the window procedure for the specified window and, if the specified window belongs to a different thread, does not return until the window procedure has processed the message or the specified time-out period has elapsed. !!! If the window receiving the message belongs to the same queue as the current thread, the window procedure is called directly—the time-out value is ignored. !!! Thanks. :)