Is there a way to create a modeless dialog box in C++ MFC which always stays on top of the other windows in the application? I'm thinking sort of like the Find dialog in Visual Studio 2005 - where it stays on top, but you can still edit the underlying text.
(If it makes any difference, it's not MDI; it's a dialog-based app)
Note: This does not work under Windows 10, and may not work under Windows 7 and 8 (Reports vary).
From Nish:
###Making your dialog stay on top
Haven't you seen programs which have
an "always-stay-on-top" option? Well
the unbelievable thing is that you can
make your dialog stay on top with just
one line of code. Simply put the
following line in your dialog class's
OnInitDialog() function.
SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
Basically what we are doing is to use
the SetWindowPos function to change
the Z-order of our dialog window. We
make our dialog stay on top of all
other windows by moving it to the top
of the Z-order. Now even when you
activate some other window, our window
will stay on top. But I'd advise you
to make sure you know exactly what you
are doing when you do this, for it
might annoy people if they can't get
your window out of the way when they
want to do that.
As you mentioned in the comments, the above line makes the window sit on top of every application. You'll need to do
SetWindowPos(&this->wndTop,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE);
To make a window sit on top of only your application.
The accepted answer fails for Windows 7 or above. (Or perhaps its me)
But making the modeless dialog as popup instead of child solves it.
It now gets positioned wrt main dialog window but you can write code to constrain anywhere.
Using the no border or top bar makes it a simple window.
It worked for me in Microsoft Windows Version 10.0.18362.476. Had to put SetWindowPos(&this->wndTopMost,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE); in OnInitDialog and make the dialog as a PopUp.
Related
I want to create a file open dialog with wxwidgets that uses the "new" style of the Common Item Dialog under Win-Vista and newer. Is there any way to achive this? With the wxFileDlg() I get a dialog as shown on the right side but I'd like to get th left dialog...
both dialogs
The dialogs sample included in wxWidgets shows the example of "new style" file dialog if you use e.g. "Dialogs|File operations|Save dialog" menu item (or just press Ctrl+S) and there is nothing special to do. If this doesn't work for you, check that you're
Not using some ancient version of wxWidgets.
Have correct manifest in your application.
Not using any custom controls in your dialog, as those are only supported in old style version.
I struggled with this today so thought I would post here for the next person who has the same issue. If I were to guess, your code was calling either dialog.Center() or dialog.CenterOnParent(). I've posted a lengthy explanation of why this happens here.
From all my time spent on this today, you have to choose whether you want have the old common control dialog and be able to center it, or use the new common item dialog and have it appear in your windows top-left corner.
The good news is that Visual Studio, Word, Excel, Firefox, Chrome, and many others all use the new dialog and they all open at the top-left of the application window.
I'm seeing non-standard behavior (as compared to tools like Word and Visual Studio 2013) in my C++ Windows Forms application. We use Application::Run and then ShowDialog to show various modal dialogs. When one of the modal dialogs is up and I place another application window partially in front of the modal dialog, I can click on part of the modal dialog and it brings it back into the foreground as I expect.
However, if I instead click on part of the main window (shown with Application::Run) the modal dialog isn't brought to the foreground. This makes it hard to bring my application back so I can work on it. Ideas?
A simple MFC app created in VS2013 works as it should too. You can witness this with the About box which is shown with DoModal. I would have expected ShowDialog and DoModal to be equivalents. A simple C++/CLI or C# winforms application acts fine.
And this only happens in out application when our main window is maximized.
It turns out that is caused by our use of the Syncfusion UI libraries. They will be fixing the bug.
I have this XP app (win32 C++) that I am just now testing under Windows7 (vista actually, but it does the same thing in windows 7).
I'm surprised that virtually the only issue I'm encountering is the following:
None of the scroll bars in a complex modelless dialog are functioning correctly. The main problem is the scroll thumb is not responding - just stays locked in position if you try and move it. Have had no issues going all the way back to win98, win2000, and winxp. Only in windows 7/Vista just now
But there is no commonality in the scrollbars in this dialog to explain it: One is in a plain richtext control created through a resource file. Another is in a richtext created through CreateWindow. And yet a third scrollbar is in a custom window class. None of them are working correctly (although you can make them scroll by right clicking and selected "Scroll Here".)
So I'm presuming maybe most encountered this a few years ago when porting to Window7/Vista for the first time, but I'm not finding anything in google now.
For modeless dialogs, you have to run IsDialogMessage in the main application GetMessage Loop, so messages for modeless dialogs are not subject to TranslateMessage and DispatchMessage. So I was doing that previously. However, Vista/Win7 doesn't like WM_MOUSEMOVE, and WM_LBUTTONDOWN and WM_LBUTTONUP to be bypassed like that for the dialog (i.e. they need to stay in the main App message loop). At least this was the problem in my case. I check for those message types now in the main message loop and that solved my problem. Can't explain it necessarily. Also couldn't explain why no one's encountered this previously (could be some idiosyncracy of my set up I guess). THanks for those who looked into this.
I have a Motif-based notepad-like legacy application.
I would like the modeless "Find/Replace" dialog (which is a Motif TopLevelShell) to always stay on top of the other windows of my application, but not on top of other applications.
I don't see any Motif-specific setting to do this.
KDE allows me to set window-specific behavior, but I can only make the "Find/Replace" window stay on top of all windows, which isn't right.
What is the correct way to force one of my application windows to stay on top of the other windows of the same application? Is it possible at all? Is there a way to do it in Motif? KDE? Do I have to drop down to an X call?
If you use a DialogShell then this behavior happens automatically. DialogShells are not modal by default, and do work well for file open and find/replace. Here is a quote from the Motif book:
A DialogShell is always placed on top of the shell widget that owns the parent of the DialogShell.
Dialogs are described well in chapter 5.
Sorry for being 12 years late!
You can subclass KDialog http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/classKDialog.html#10744dda705aa265a43becab32a43ea4
with Qt::WA_ShowModal attribute http://doc.qt.nokia.com/4.0/qt.html#WindowType-enum
KDialog dialog(parent, Qt::WA_ShowModal)
dialog.exec()
Maybe it's not what you want, but ...
I'm trying to set something up so my main dialog has one or more child dialogs, and these are glued/docked to the outside of the main dialog - when the main dialog is minimised, the children are too, when main dialog moves, children move with it.
I'd tried setting child dialogs as having main dialog CWnd as parent, with CHILD style. But then they get clipped by the parent's boundary. If I set them as POPUP, they can be outside but then don't move with the parent.
I'm looking at putting an OnMove handler on the parent dialog, but is there something built-in? And, should child dialogs still be children of the main dialog... I assume they should?
This is VS2005 (I think VS2008 has some related functionality so I mention this).
You need to implement the movement manually when they are popups, and yes they should be popups otherwise they will be clipped out.
I'm new to SO. Not sure if I can refer to an external article.
I guess this is what you are looking for.
I started to write this class because
I'm often in need to popup additional
dialogs around the main one. Often
these dialogs can give some trouble to
the user; for example, he must
move/close them one by one... A
solution that could give the
application a more solid aspect and
that could make the management of the
various windows easier could be, to
dock all dialogs side by side (like
Winamp does, for example).
As Roel says, your extra dialogs will need to be popups. I'm interested: what kind of UI is this? Is it WinAmp-style, where the windows snap to eachother?
Or are you doing some kind of expanding dialog? If it's an expanding dialog (with a More>> button on it, e.g.), then you can put all of the controls on the same dialog and play with the window rect when showing/hiding the extras.