that, too. But in practice, you need to KNOW exactly what you're doing, and
what are the hazards of deadlocking. If you want to make your life easier,
Joseph,
I completely understand advantages of the single UI thread.
Ok, probably there is no reason to do so.
But why there are no "DON'T DO IT" neither in MSDN nor in OldNewThing?
Seems strange!
I cannot tell to the project architect that multithreaded UI is risky
because there are no facts at all...
The same scenario (popup MDI childs and topmost windows) works good when
everything belongs to the primary UI thread. Therefore I believe that my
issue has something to do with the multithreading.
I know that my design is risky and Windows behavior could be kind-of
unusual. But I cannot understand why the rule from MSDN is violated. I've
read all articles related to the Windows Management in the MSDN and have
found nothing about risks of multithreaded UI. Isn't it strange?
There are millions of software developers in the world and I cannot
believe
that I'm the first one who face up with this issue.
Thank you very much!
"Joseph M. Newcomer" wrote:
See below...
On Wed, 17 Dec 2008 11:15:01 -0800, Denis Adamchuk
<DenisAdamchuk@discussions.microsoft.com> wrote:
Hi everyone,
I see behavior which violates rules from the well-known article "Windows
Features"
http://msdn.microsoft.com/en-us/library/ms632599(VS.85).aspx
I have an MFC MDI application which is a bit different from a generated
by
Visual Studio Wizard:
ChildFrames are not WS_CHILD but WS_POPUP. It allows to move MDI-childs
out
of the MainFrame. Looks good!
Since ChildFrames are popup windows now, they are owned by the
Mainframe.
On some user action I want to create a topmost window in a separate
thread.
I design it to have WS_POPUP and WS_EX_TOPMOST styles and have the
active
Child Frame as owner.
****
As soon as you say you want to create a window in a separate thread, you
are entering
dangerous territory. Why? There is no reason to do so. All windows
should be owned by
the main GUI thread.
****
Then I start the application and open 2 child frames (A and B).
When the topmost window is created (say, with the child frame A as
owner) -
appears the most weird Windows behavior I've ever seen:
****
As soon as you say you are creating windows owned by multiple threads,
the above line is
the inevitable consequence. Which is why it is not a recommended
practice. Because there
is no reason to create windows in secondary threads, it should not be
done, because then
questions that start with that introduction never come up.
****
If the topmost window is active now - a mouse click at the caption of
the
child frame B brings this childframe to the bottom of Z-order, even
behind
the Mainframe!
****
This may have nothing to do with multithreading, but I wouldn't even
bother to answer such
a question until the windows were moved into the main GUI thread.
****
It's weird and it violates the rule from the "Windows Features":
"An owned window is always above its owner in the z-order."
Does anybody know what's wrong with TOPMOST windows in Win32?
****
Until all windows are in one thread, the question is not worth answering.
You are doing something that is so far out in the minefield that you
should expect that
any step you take is going to blow up something.
joe
****
Thanks a lot!
Joseph M. Newcomer [MVP]
email: newcomer@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm