Using mixed managed/unmanaged C++ (Visual Studio 2008) I'm opening a windows form child window from a DirectX application. Weird stuff indeed, but it works, mostly. If I use showDialog() the child window works perfectly, but obviously the main app stops running (until the child is closed). If I use show() life is good, but the child has subtle issues. A textbox works and accepts input for example, but you can no longer use the Tab key to move to different controls. Mnemonics (Alt+hotkey) have stopped working as well.
I'm a huge keyboard shortcut fan, so this is very annoying. To make it worse, I'm not even sure how to Google this issue. Any help would be greatly appreciated.
To resolve the tabbing problem either use a separate thread to create the dialog and call showDialog(), or call IsDialogMessage in your main message loop.
Related
I have a modeless dialog that is sometimes left up on the screen when I go to close my main app. If I close it manually, all destructors get called properly. But so far, if I try to do it through C++ code, I encounter problems in the Debug build that don't give me confidence in what is happening in the Release build.
What is the correct way to close a modelss dialog? Documentation for PostQuitMessage() indicates it closes entire threads (is a modeless dialog run in a separate thread, or just part of the single MFC App UI thread?). Calling DestroyWindow() gives me issues in practice. Sending a WM_CLOSE doesn't feel like the right thing to do. And CWnd::EndDialog() only applies to Modal dialogs. Does the correct answer lie among these... or somewhere else?
still relatively new to Qt (and to stackoverflow as well) but succeeded over the last weeks to replace our old obsolete-when-new GUI code with Qt and improve several things along the way as well. Now however I am running into a problem I so far have not been able to google my way out of.
Some background:
Application has an opengl main window which is created outside Qt (most of this application is completely outside Qt), Qt windows are only used for (development) subfunctionality, just GUI.
I am calling processEvents() from the main loop each frame.
Using locally built Qt 4.7.4 on both platforms.
Everything works fine on linux. The Qt windows behave properly and I can interact with the application/simulation in the main opengl window through mouse and keyboard just as was always possible.
However, when I applied the same changes to incorporate Qt on windows the mouse no longer works in the main window. Keyboard does, but our mouse code never seems to get any WM_INPUT events. When I disable calling processEvents() the mouse works fine again. (but then obviously the Qt windows won’t work properly)
It seems Qt is catching mouse events intended for the main window and throwing them away/forgetting them instead of delivering them to the main window.
Unfortunately I haven’t found anything that points to this being a common occurrence (with a common simple solution).
I did find http://qt-project.org/forums/viewthread/502 referencing an issue with mouse events but the resolution mentioned there of compiling Qt with _WIN32_WINNT=0×501 defined does not make any difference.
Any insights would be highly appreciated!
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 always been interested on how we can accomplish this (hide/show the main menu using the alt key), and now some applications do this very often. One that really please me is the visual studio 2010 with this plugin:
http://visualstudiogallery.msdn.microsoft.com/bdbcffca-32a6-4034-8e89-c31b86ad4813?SRC=VSIDE
(firefox also do this, but i think that is in a different way)
Can anyone explain me how this can be achieved or if you known of any sample project that demonstrate this please tell me.
(what i can see in some replies here in stack is that we have to destroy the menu when is to hide and create it when is to show?! but this seems a bit bad solution...)
Thanks
The SetMenu function lets you add/remove the menu from the window. It does not destroy the menu.
Note that most applications which have the dynamic menu hide/show behavior are not really showing a menu. They're showing a custom control that looks like a menu.
You might also take a look at MFC support for auto hiding menus. I used this technique and it worked really well.
in CMainFrame::OnCreate I did
m_wndMenuBar.ShowWindow(SW_HIDE);
which actually works fine in our project
I stumbled across a related pit fall that will show a hidden main frame without your consent:
Whenever the focus for a child window in an MDI application changes (e.g. due to right clicking in it), the function CMDIChildWnd::OnMDIActivate will be called, which in turn shows the main menu (even if it was removed or destroyed previously) of the MDI application.
This works basically by adding the saved main manu from the underlying's CMDIChildWnd m_hMenuShared variable.
A quick&dirty hack to prevent this, is setting m_hMenuShared to NULL (it's protected in CMDIChildWnd so this needs a custom derived child class of CMDIChildWnd) for all child frames.
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.