ATTN: Anyone from MS, especially GWES group (was: Re: Pinning dialog on top of other dialogs)

[Dan McCarty]

At the suggestion of Sue Loh (MS) I've posted this here instead of the
...embedded.vc group. I really need some kind of answer. I've
received nothing from several earlier postings to two newsgroups and no
one was able to help at the last MSDN chat session. Any help,
suggestions or plain old WAGs would be appreciated!

original post:
http://groups-beta.google.com/group/microsoft.public.windowsce.embedded.vc/browse_frm/thread/29bd24dafb98f048

ms.public.mfc post:
http://groups-beta.google.com/group/microsoft.public.vc.mfc/browse_frm/thread/2ebdb7a197687c37/94e26f09a2bb6502

Another developer has independently arrived at the same problem, which
leads me to believe that either he and I are both doing something wrong
or there's something wrong with SetWindowPos() under CE. What gives?

As always, TIA.

- - - Original Post - - -
(I posted this to ms.public.vc.mfc but I suspect this is a CE-specific
issue, as I've tried the suggestions I got there and they didn't work.)

I have an MFC that is essentially a dialog app controlled by a process
control layer. The control layer is responsible for hiding and showing
the various dialogs.

All of these dialogs are modeless dialogs created when the app starts
(for speed reasons), then hidden, like so:

pFrame->Log(_T("Symbol Bar loading"));
m_pDlgSymbolBar->Create(IDD_SYMBOL_BAR, NULL);

OnInitDialog:
ShowWindow(SW_HIDE);

When it's time for a dialog to appear, it is sent a message along with
any new data. The dialog updates itself and calls its parent class to
make it visible.

It all works like it should.

But one dialog in particular is giving me a headache. (Which is
probably more from my own ignorance than any problem w/ MFC.) It's
supposed to be a symbol bar, like a tool bar, that sits atop the other
dialogs. When activated, it's supposed to become topmost:

style = GetWindowLong(this->m_hWnd, GWL_EXSTYLE);
style |= WS_EX_TOPMOST;
SetWindowLong(this->m_hWnd, GWL_EXSTYLE, style);

BringWindowToTop();

This works, but doesn't _keep_ the window on top. Clicking on a window
behind this symbol bar will move the other dialog in front of it. I've
tried everything that I can think of, including
SetWindowPos(&CWnd::wndTopMost..., setting the window long,
BringWindowToTop() and various hacks. Is what I'm trying to do not
possible?

What am I missing?

[Chris Edgington]

Sounds like you've done your homework ... but just to make sure, have
you reviewed this URL:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui/html/_wcesdk_Sizing_and_Positioning_a_Window.asp

Also, have you tried making the style WS_EX_TOOLWINDOW?

If you run the same code on desktop Windows - does it behave the same?

-Chris

[Steve Maillet (eMVP)]

Have you contacted MS support? (Note posting here is not contacting
support - just there rest of us users!)

--
Steve Maillet
EmbeddedFusion
www.EmbeddedFusion.com
smaillet at EmbeddedFusion dot com

[Michael J. Salamone]

Make sure the dialog doesn't have a parent window.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"Dan McCarty" <dmcc...@gmail.com> wrote in message
news:1123106431.2...@g14g2000cwa.googlegroups.com...

[wrx03ppp]

Hi

I know that this doesn't actually help, but I have an MFC app that I target
at both CE 5.0 and 'normal' PC windows. To make it workout OK I needed to
code stuff like this:

m_FileName.ShowWindow(nCmdShow);
#ifdef UNDER_CE
m_FileName.BringWindowToTop();
#endif

Never worked out why, but would like to know the reason.

Sean

[Dan McCarty]

Chris Edgington wrote:
> Sounds like you've done your homework ... but just to make sure, have
> you reviewed this URL:
> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/wceui/html/_wcesdk_Sizing_and_Positioning_a_Window.asp
>

Yeah, that's what the eVC docs say, too. And I'm pretty sure I
followed the directions correctly. (But it wouldn't be the first time
I was misled by the docs, or they were flat out wrong.) One thing I'm
not sure about, though, is that the dialog's parent might be the frame.
(?) If that's the case, do I need to make the frame topmost as well?

"When creating an owned window, if the owner of the window is
designated WS_EX_TOPMOST, the owned window must be a topmost window,
too."

"If the dialog is owned by the frame" is the key question, I suppose.
It's created without specifying a parent, so I would have to assume
that the answer is no.
mpDlgSymbolBar->Create(IDD_SYMBOL_BAR, NULL);

I experimented with Creating it like this instead

mpDlgSymbolBar->CreateEx(WS_EX_TOPMOST, _T("CDlgSymbolBar"),
_T("Symbol Bar"), WS_BORDER | WS_DLGFRAME | WS_POPUP,
CRect(0, 0, 1024, 76), NULL, IDD_SYMBOL_BAR);

but that didn't help either. Any thoughts?

[Dan McCarty]

Michael J. Salamone wrote:
> Make sure the dialog doesn't have a parent window.

I don't think it does. It's Created like this

m_pDlgSymbolBar->Create(IDD_SYMBOL_BAR, NULL);

so unless the MFC frame is inherently becoming the dialog's parent (?!)
I would think that the dialog should be parentless...?

[Michael J. Salamone]

I think MFC is inherently doing it for you. Use Remote Spy++ to verify.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"Dan McCarty" <dmcc...@gmail.com> wrote in message

news:1123186781.0...@g44g2000cwa.googlegroups.com...

[Dan McCarty]

Michael J. Salamone wrote:
> I think MFC is inherently doing it for you. Use Remote Spy++ to verify.

Unfortunately, Spy reports that the dialog is parentless. I guess it's
time to call support and fork over the $$$. :(

Thanks for all your help,
Dan.

[Michael J. Salamone]

Is it non-owned? Soy will show as a top-level window because it's a dialog.
But, does it have a hWndParent? You could probably just call GetParent from
the dialog itself.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"Dan McCarty" <dmcc...@gmail.com> wrote in message

news:1123252484.8...@g44g2000cwa.googlegroups.com...

[Dan McCarty]

Finally figured it out...I'll post more when I get a chance to clean up
the code and simplify it.

-Dan

[Dan McCarty]

Finally figured it out...I'll post more when I get a chance to clean up
the code and simplify it.

Thanks very much to all who helped!

-Dan

[Dan McCarty]

Michael J. Salamone wrote:
> But, does it have a hWndParent? You could probably just call GetParent from
> the dialog itself.

Michael,
That was the tip that led to finding the solution. Thanks!

I'll list what I found below. Hopefully someone who has this same
problem will find my post before they find out the hard way. And if
I'm wrong about any of this someone please correctly me. (Gently ;-)

1. The window style needs to be set to Overlapped, _not_ Popup. If
it's set to popup, other popup siblings can cover it.

2. Using SetWindowLong() with WS_EX_TOPMOST plain doesn't work.

3. The parent must be the desktop (or something else other than the
app itself). Right now I'm doing it in the dialog's InitDialog:

CWnd *desktop = GetDesktopWindow();
SetParent(desktop);

this is because

4. MFC f/ CE apparently _ignores_ the parent parameter at creation,
instead surreptitiously setting the parent to the main app, a la

mpDlgSymbolBar->Create(IDD_SYMBOL_BAR, CWnd::GetDesktopWindow());

I believe I had the same problem with CreateEx(), although I didn't
investigate it enough to know for certain.

5. SetWindowPos() should be done at the dialog's Init, like

SetWindowPos(&wndTopMost, 0,0,0,0,
SWP_SHOWWINDOW | SWP_NOMOVE | SWP_NOSIZE);

Later, if the dialog needs to be reshown (because it was hidden or
something) it can be brought back to the top with BringWindowToTop().

So it's finally working, and with four separate parts it's not an
easy solution. I'm sure some of my meanderings down dead ends were due
to my own ignorance of windowing/MFC issues, but a lot my problems can
be placed squarely on bad or missing documentation. Of the 5 points
above, help only correctly talks about #2 and #5. The other points are
either unmentioned or ignored. One key difference between HWND_TOPMOST
and &CWnd::wndTopMost is dead wrong.

I know that this newsgroup isn't official Microsoft support, but
this isn't the kind of issue I or my company like spending
$200/incident on. This was a problem that experts in three different
newsgroups (MVC/eVC/PB) and MS experts in the last embedded chat didn't
know the answer to. If the solution was that complicated I doubt
anyone from first-level telephone support could've helped me.

I didn't post this to whine; I'm glad I found the solution. But I
also hope that other developers don't have to go through the same
problems. Hopefully the above steps will go into the next set of docs,
or maybe the KB. I'll keep my fingers crossed, but I won't hold my
breath.

[Dean Ramsier]

Sounds like an excellent opportunity to hit the Send Feedback link in the PB
documentation (upper left corner of every page). My experience has been
that MS does a very good job at responding to those, and getting the docs
updated. They'll email you back directly with an acknowledgment, their
proposed new content etc.

Nice work!

--
Dean Ramsier - eMVP

"Dan McCarty" <dmcc...@gmail.com> wrote in message

news:1123518258.9...@g49g2000cwa.googlegroups.com...