To preface we have a strange requirement that all dialogs must be modeless for an MFC application. There is a particular dialog using region drawing and some custom controls to select dates and times for viewing past and future data per view. I need to be able to close this window when it loses focus, the main app gets a system command, etc.
I figured the easiest way to do this would be to register the class like so:
// for CWnd::FindWindow
WNDCLASS wndcls;
SecureZeroMemory(&wndcls, sizeof(WNDCLASS));
wndcls.lpszClassName = L"CTransactionDialog";
wndcls.style = CS_HREDRAW | CS_VREDRAW;
wndcls.lpfnWndProc = AfxWndProc;
wndcls.cbClsExtra = wndcls.cbWndExtra = 0;
wndcls.hInstance = AfxGetInstanceHandle();
wndcls.hIcon = NULL;
#ifndef _WIN32_WCE_NO_CURSOR
wndcls.hCursor = AfxGetApp()->LoadStandardCursor(IDC_ARROW);
#else
wndcls.hCursor = 0;
#endif
wndcls.hbrBackground = (HBRUSH) (COLOR_BACKGROUND + 1);
wndcls.lpszMenuName = NULL;
BOOL retVal = AfxRegisterClass(&wndcls);
if (!retVal)
AfxMessageBox(L"AfxRegisterClass(CTransactionDialog) Failed");
Then later in response to various event handlers and messages where I would want these modeless window or windows to be closed to do something simple like this:
CWnd* pFound = NULL;
while ((pFound = CWnd::FindWindow(L"CTransactionDialog", NULL)) != NULL)
pFound->DestroyWindow();
However despite the registration of the class succeeding and looking at GetRuntimeClass of the dialog in question in debug and seeing that is matches up as expected the FindWindow never seems to find or close these modeless dialogs as expected.
What am I doing wrong or is there a better way to go about this?
Update: This is how the dialog is created via a static method on the dialog class. The dialog resource for the id specified in create has the Popup property set which should resolve to WS_POPUP style under the MFC covers. The dialog shouldn't and doesn't have a parent as far as I knew.
CTransactionDialog* CTransactionDialog::ShowTransactionDialog(const CRect& crCtrlToFloatAbove, UINT dialogID, Itime defaultTime, Itime initialTime)
{
CTransactionDialog* pCTDialog = new CTransactionDialog(crCtrlToFloatAbove, dialogID, defaultTime, initialTime);
pCTDialog->Create(CTransactionDialog::IDD);
pCTDialog->ShowWindow(SW_SHOW);
return pCTDialog;
}
Update: Doh! FindWindowEx isn't finding anything either.
CWnd::FindWindowEx(AfxGetMainWnd()->GetSafeHwnd(), NULL, L"CTransactionDialog", NULL);
However I have a new plan. I'm just going to make my own window message and handle it on the main frame. I think I can get away with passing a pointer to the dialog as the lParam of the message and then casting it to a CWnd* then calling DestroyWindow. It will work for most cases in a very round about way. I may run into trouble with minimizing and maximizing of the main frame window for dialogs that nothing is holding a pointer too but we'll see.
FindWindow doesn't work with child windows. To find a child window, you can use FindWindowEx, passing the HWND of the parent window as the first parameter.
Class name denotes NOT the c++ class name - it denotes the window class name. This name was used to register the window by the OS and has nothing to do with the c++ class.
May MSDN enlight you...
CWnd::FindWindow does not search child windows.
Is it possible that the mode less window that you are creating has a parent set and that is the reason why FindWindow doesn't find it ?
Below is the simplest and cleanest solution I could come up with:
BOOL CTransactionDialog::OnNcActivate(BOOL bActive)
{
if (!bActive)
PostMessage(WM_CLOSE);
return CDialog::OnNcActivate(bActive);
}
Not 100% sure about this but I think you need to set your class name in the resource file. You are defining a windows class and creating a dialog class but you aren't linking them. Setting a class name in the WNDCLASS struct won't help unless you actually have a way of linking it to the dialog. If you use the resource file and define the dialog, and class name in there then it should work.
Related
I'm trying to place a window either above or below the icons on the desktop. I mostly just want it to stay attached to the desktop at all times. Similar to Rainmeter or Wallpaper engine. So far, everything I tried either disables interaction, or gets minimized when you use the "Show Desktop" button. Any ideas on how to achieve this? I'm using electron and a native module in node to do this.
It's an old subject, but I'll find out how to do it recently and answer it.
The method is to find the handle of SHELLDLL_DefView, the parent of the desktop window, and then make the SHELLDLL_DefView handle the parent of my window to fix it to the desktop.
The method is to find the handle of SHELLDLL_DefView, the owner of the desktop window, and then make the SHELLDLL_DefView handle the owner of my window to fix it to the desktop.
SHELLDLL_DefView is located under the Progma or WorkerW handle. This is a code to prevent ShowDesktop from being used in the Electget package created by ffi-napi to attach the Electron browserWindow to the desktop.
const GWLP_HWNDPARENT = -8;
// find SHELLDLL_DefView in Progma
const progman = user32.FindWindowExA(ref.NULL, ref.NULL, 'Progman', ref.NULL);
let defView = user32.FindWindowExA(progman, ref.NULL, 'SHELLDLL_DefView', ref.NULL );
// find SHELLDLL_DefView in WorkerW
if (!defView) {
const desktopHWnd = user32.GetDesktopWindow();
let workerW = 0;
do {
workerW = user32.FindWindowExA(desktopHWnd, workerW, 'WorkerW', ref.NULL);
defView = user32.FindWindowExA(workerW, ref.NULL, 'SHELLDLL_DefView', ref.NULL );
} while (!defView && workerW);
}
if (!defView) return false;
// make the SHELLDLL_DefView handle the parent of my window
user32.SetWindowLongPtrA(hWnd, GWLP_HWNDPARENT, defView);
This allows you to create a window where you can click and interact without being hidden by ShowDesktop.
2022-03-29
There was a wrong word, so I corrected it. According to doc, it is not a parent window, but an owner window. In the doc, it is strange that the GWLP_HWNDPARENT constant is related to the parent window. However, when tested with Spy++, the corresponding constant changes the owner window.
I'm new to c++ and FindWindowA is working for some processes and not others, for example:
FindWindowA(NULL, "Discord"); will work
but FindWindowA(NULL, "Fortnite"); won't.
anyone know why?
Thanks.
FindWindow only finds top level windows. If you are searching for an exact match with the title of the window, then you must take into account hidden characters (space, tab, etc.).
Even if you find the window title, it will only work if that window isn't localized—i.e., if the program that creates that window is localized for a different language, then you must also localize your search string.
A more reliable approach is to search for the class name, since this will typically not be localized: FindWindow("myclass", NULL);
Of course this will still fail if there is a hidden top level window that creates a child window containing the window you are looking for. To get that window, you can call EnumWindows to get the handle of each top level window, and for each top level window found, you then call EnumChildWindows.
Fortnite's window has a space or two
sd.Flags = DXGI_SWAP_CHAIN_FLAG_ALLOW_MODE_SWITCH;
sd.OutputWindow = FindWindow((L"UnrealWindow"), (L"Fortnite "));
sd.SampleDesc.Count = 1;
sd.Windowed = TRUE;
Folks, I apologize if this sounds like a newbie questions, but I am not very familiar with Windows development as a whole. So I was given App A, which does a lot of things and one particular function is to render a duck picture. Internally it created the Window with the title 'DrawingBoard' and later on when the program is ready to render it will try to find this "DrawingBoard" window. I was only told that this is how App A finds the window to render the duck:
static const TCHAR TITLE_NAME[] = "DrawingBoardParent";
static const TCHAR TITLE_CLASS_NAME[] = "DrawingBoard";
HWND parent = FindWindowExA(NULL, NULL, NULL, TITLE_NAME);
while (parent != NULL)
{
//find the child window by window title
window = findWindowRecursive(parent, TITLE_CLASS_NAME);
if (window != NULL)
{
break;
}
//no child by the given title name found, go down one level
parent = FindWindowExA(NULL, parent, NULL, TITLE_NAME);
}
Now I need to create App B and I want to create my own "DrawingBoard" window on App B. Because App A uses the above algorithm to find the rendering window, instead of using it's own App A "DrawingBoard" Window, it will use my App B "DrawingBoard" Window.
Questions:
1) Is this within the realm of possibility at all ?
2) Say if both App A & B have two windows with the same title "DrawingBoard". Which one does FindWindowEx(NULL, NULL, NULL, ""DrawingBoard"); return ?
3) If FindWindowEx always returns the handle for App A "DrawingBoard" window. How do I hack it so it will return App B "DrawingBoard" window.
Thanks for the help folks.
Say if both App A & B have two windows with the same title "DrawingBoard". Which one does FindWindowEx(NULL, NULL, NULL, ""DrawingBoard") return?
That is ill-defined. It will return one of them. You cannot influence which is returned.
If FindWindowEx always returns the handle for App A "DrawingBoard" window. How do I hack it so it will return App B "DrawingBoard" window.
You cannot. The other app is broken. Its search for a window that it created is broken, since it can yield the wrong window, a window from another process.
You can avoid getting caught out by this app by using a different name for your window. However you really ought to either fix or remove the defective program. That's the sane way forward.
I have followed this link to get the window handle of a ActiveX control
Sample Code from microsoft's site
// The following code should return the actual parent window of the ActiveX control.
HWND CMyOleControl::GetActualParent()
{
HWND hwndParent = 0;
// Get the window associated with the in-place site object,
// which is connected to this ActiveX control.
if (m_pInPlaceSite != NULL)
m_pInPlaceSite->GetWindow(&hwndParent);
return hwndParent; // Return the in-place site window handle.
}
But in my case I keep finding that "m_pInPlaceSite" is always NULL. I'm trying to run this code in my controls FinalConstruct. Is there something else I need to implement for the m_pInPlaceSite to be given a value? Or do I need to Query to get the value.
Thanks
FinalConstruct is way too early. In FinalConstruct your class is just being created and is not yet initialized. There is no "in place" site, there is no yet site at all.
Your control will be called by its owner, it will be given its site, then activated - only then you will possibly have m_pInPlaceSite available.
I am creating an MFC application which will be launched on click on Explorer Context (Rightclick) menu.
But I need to launch only single instance of the application. For that I have to use FindWindow and AfxRegisterClass
I tried to register the class in my MFC app as below:
BOOL CNDSClientDlg::InitInstance()
{
//Register Window Updated on 16th Nov 2010, #Subhen
// Register our unique class name that we wish to use
WNDCLASS wndcls;
memset(&wndcls, 0, sizeof(WNDCLASS));
//Class name for using FindWindow later
wndcls.lpszClassName = _T("NDSApp");
// Register new class and exit if it fails
if(!AfxRegisterClass(&wndcls)) // [C]
{
return FALSE;
}
}
and called the method in the constructor of the MFC class. I verified that the class is being registered while I am starting the application.
Now in my shell Extension I am trying to find the Class registered in my MFC as below:
CWnd *pWndPrev = NULL;
pWndPrev = CWnd::FindWindow(_T("NDSApp"),NULL);
if(pWndPrev != NULL)
pWndPrev->BringWindowToTop();
But I am not able to get the CWnd to Window. Not able to figure it out. Please let me know if I am missing something or doing something wrong.
FindWindow finds window instances not window classes. In your app which registers the class you need to actually create a window so that the extension can find that window.
(Finding the window by class name is fine; the problem is you haven't actually created anything to find.)
Also, I suspect if you try to create a window based on the window-class you've registered it will fail because you've left most of the WNDCLASS structure null. See the example you linked to for better default values. (e.g. You must provide a wndproc and hinstance.)