Prev: One more foolishness of the C++ Standard
Next: How to provide right click event on cbitmapbutton?
From: Igor R. on 21 Jan 2010 08:30
Hello,

Excuse me, if it's not the right place to ask this question.

What happens exactly as a response to win+e (launch explorer)? Are
there some messages sent to all the windows/threads? Is there any
article, which explains the subj in details?

I've got a strange issue: when my COM-based application is running, win
+e doesn't work - and totally blocks the explorer/taskbar. I found
*what* caused this problem and how to solve it, but I still don't
realise *why* it used to happen.

Thanks.
From: Igor Tandetnik on 21 Jan 2010 13:24
Igor R. <igor.rubinov(a)gmail.com> wrote:
> Excuse me, if it's not the right place to ask this question.
>
> What happens exactly as a response to win+e (launch explorer)? Are
> there some messages sent to all the windows/threads? Is there any
> article, which explains the subj in details?
>
> I've got a strange issue: when my COM-based application is running,
> win +e doesn't work - and totally blocks the explorer/taskbar. I found
> *what* caused this problem and how to solve it, but I still don't
> realise *why* it used to happen.

Let me guess - you have a thread that creates a top-level window but doesn't process window messages in a timely manner. Don't do that - it would interfere with any application that broadcasts messages. In particular, it would block DDE, and Windows shell relies heavily on DDE.
--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead. -- RFC 1925

From: Igor R. on 21 Jan 2010 14:46
> Let me guess - you have a thread that creates a top-level window but doesn't process window messages in a timely manner. Don't do that - it would interfere with any application that broadcasts messages. In particular, it would block DDE, and Windows shell relies heavily on DDE.


Well, if this were the situation, I wouldn't be surprised that the
shell would freeze. But I was doing something other: in one on my
working pthreads I was quickly creating and destroying a window, whose
winproc looked like this:

LRESULT CALLBACK WinProc(HWND hWnd, UINT message, WPARAM wParam,
LPARAM lParam)
{
switch (message)
{
case WM_MYONE:
doSomething();
break;
default:
return DefWindowProc(hWnd, message, wParam, lParam);
}
return 0;
}

Such windows were created/destroyed several times per second, but for
a time-period the window existed - it did process messages.
From: sasha on 21 Jan 2010 15:18
Igor Tandetnik wrote:

> Let me guess - you have a thread that creates a top-level window but doesn't process window messages in a timely manner. Don't do that - it would interfere with any application that broadcasts messages. In particular, it would block DDE, and Windows shell relies heavily on DDE.

I learnt this the hard way when the whole system froze on me when I was
automating MS Word 10 or so years ago :)
From: Igor R. on 21 Jan 2010 16:30
> Let me guess - you have a thread that creates a top-level window but doesn't process window messages in a timely manner.

Ok, it turns out that you're absolutely right. The above winproc is
irrelevant, because these windows were occasionally in a thread that
doesn't have - and isn't expected to have - a message-loop at all.
 |  Next  |  Last
Pages: 1 2
Prev: One more foolishness of the C++ Standard
Next: How to provide right click event on cbitmapbutton?