Retrieve HWND of a control that has focus

[_Flaviu]

No. In fact, it a CDialog which belong to another app.

[_Flaviu]

I have found a little workaround, I don't know if is ok:

	HWND hWndChild = ::GetNextWindow(hwnd, GW\_HWNDNEXT);
	hWndChild = ::GetNextWindow(hWndChild, GW\_HWNDPREV);
	::SetWindowText(hWndChild, sText);

[_Flaviu]

"What is your aversion to using GetFocus()?" Because this dialog is not belong to my app, and if there is another window in foreground, this GetFocus() will not work.

[David Crow]

Understood. Does this thread even remotely talk about what it is that you are attempting to do?

"One man's wage rise is another man's price increase." - Harold Wilson

"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons

"You can easily judge the character of a man by how he treats those who can do nothing for him." - James D. Miles

[leon de boer]

GetForegroundWindow and GetActiveWindow are the goto functions. GetActiveWindow give you the active window of your app if it was activated and topmost. GetForegroundWindow function is the special function specifically designed for obtaining windows from other processes. It is the windows system topmost window, so if a window has focus it will be that window. All windows recieving focus get WM_SETFOCUS messages and those losing it receive WM_KILLFOCUS messages which is the other way to track focus changes.

In vino veritas

[_Flaviu]

GetForegroundWindow and GetActiveWindow are doing the job when this dialog has the focus ... but in my case this dialog is very possible to haven't focus, and

::SetWindowText(GetFocus()->GetSafeHwnd(), sText); // this edit control is gaining the mouse cursor

is not working ... and I guess GetForegroundWindow and GetActiveWindow are useless ...

[Lost User]

You would be better using EnumWindows function | Microsoft Docs[^] and using the text of the Window to identify it.

[leon de boer]

GetForegroundWindow doesn't give a rats if your dialog has focus or not. At a guess you have the dialog in modal mode and the message queue is shutdown and your code isn't executing when it isn't focused :-) https://msdn.microsoft.com/en-us/library/windows/desktop/ms633505(v=vs.85).aspx[^] It is quite specific it's the window that's currently getting input regardless of its relationship to the calling thread (aka your little APP). It has two choices the focus window (or the windows that contains the focus window depends on class) or null if the desktop itself has focus. If you doubt it download and use spy++ and click on the focus window with the mouse to get its details Introducing Spy++ - Visual Studio | Microsoft Docs[^] You should also be able to confirm it with GetLastActivePopup. GetLastActivePopup function (Windows)[^] The call they have closed down is its sister call SetForegroundWindow() to steal focus from another process (unless that process has explicitly given permission via AllowSetForegroundWindow) because lots of web browser popups were abusing it.

In vino veritas

[_Flaviu]

I have tried:

HWND hWnd = ::FindWindow(NULL, \_T("Dialog Test"));
if(NULL != hWnd) // the dialog is founded
{
	CString sTemp;
	hWnd = ::GetTopWindow(hWnd);
	while(NULL != hWnd)
	{
		hWnd = ::GetNextWindow(hWnd, GW\_HWNDNEXT);
		int nID = ::GetDlgCtrlID(hWnd);
		if(1001 == nID) // the edit box has been founded
		{
			::SetWindowText(hWnd, \_T("ABC ABC"));
			sTemp.Format(\_T("%d"), nID);
			MessageBox(sTemp);
		}
	}
}

but ::SetWindowText simply not set the text (is not changing the text) ... strange ...

[Lost User]

Some comments: 1.) If you are not the author of the target process then from a purely conceptual point of view you are attacking the process. The [modern UWP applications](https://docs.microsoft.com/en-us/windows/uwp/get-started/universal-application-platform-guide) will limit these types of cross process interactions. You should check if the target process supports [Active Accessibility, UI Automation, or IAccessibleEx](https://docs.microsoft.com/en-us/windows/desktop/WinAuto/microsoft-active-accessibility-and-ui-automation-compared). 2.) If you need to send input such as WM_CHAR to a window owned by another process you may need to use the [AttachThreadInput function](https://docs.microsoft.com/en-us/windows/desktop/api/winuser/nf-winuser-attachthreadinput) before sending the WM_CHAR or other input messages. 3.) The [SetWindowText function](https://msdn.microsoft.com/en-us/library/windows/desktop/ms633546(v=vs.85).aspx) can only be used in the current process. It cannot be used to set the text in a window owned by another process. 4.) To set the text of a window in another process you will need to send the WM_SETTEXT message directly. 5.) The [SendMessage function](https://msdn.microsoft.com/en-us/library/windows/desktop/ms644950(v=vs.85).aspx) can cause your program to hang. Use [SendMessageTimeout](https://msdn.microsoft.com/en-us/library/windows/desktop/ms644952(v=vs.85).aspx) instead. 6.) You will need to make sure that the process setting the text is of greater or equal [integrity levels](https://msdn.microsoft.com/en-us/library/bb625963.aspx?f=255). For example... a process running at medium level cannot set the text in a window owned by a process running at high integrity level. Best Wishes, -David Delaune P.S. The solution to your problem is in bold.