Thread: Setting focus

SetFocus() is dodgy, I haven't worked out how to use it properly. I do something very iffy:

Code:

mouse_event(|MOUSEEVENTF_ABSOLUTE|MOUSEEVENTF_LEFTDOWN , dx , dy , NULL , NULL);
mouse_event(MOUSEEVENTF_ABSOLUTE|MOUSEEVENTF_LEFTUP , dx , dy , NULL , NULL);

You can get dx and dy using GetWindowRect() with the control's HWND.

This method may not seem like the most logical, but it works.

However, if anyone knows how to get SetFocus() working, please tell.

Have you tried EnableWindow()?

I tried it in all sorts of combinations with SetFocus(), SetActiveWindow(), and SetForegroundWindow(), but still doesn't work.

According to the Win32 Programmer's Reference,

To allow the user to easily identify the active window, Windows places it at the top of the Z order and changes the color of its title bar and border to the system-defined active window colors.

And:

The user activates a top-level window by clicking it (or one of its child windows), or by using the ALT+ESC or ALT+TAB key combination. An application activates a top-level window by calling the SetActiveWindow function.

This implies that SetActiveWindow() should have the same effect as clicking in a window. On my machine, and clearly on other people's machines, this does not work.

Any ideas?

ok, made a little test app.

simply launches a dialog with ok, cancel and an edit control.

I used SetFocus() and lo and behold, the edit control indeed got focus, without SetFocus the ok button recieves default focus.

Code:

BOOL CALLBACK DlgProc(HWND hDlg, UINT Msg, WPARAM wParam, LPARAM lParam)
{
	HWND hEdit = GetDlgItem(hDlg, IDC_EDIT1);

	switch(Msg)
	{
	case WM_INITDIALOG:

		SetDlgItemText(hDlg, IDC_EDIT1, L"This should be active.");
		SetFocus(hEdit);

		return false;

	case WM_COMMAND:
		switch(LOWORD(wParam))
		{
		case IDOK:
		case IDCANCEL:
			EndDialog(hDlg, 0);
			return true;
		}
		break;
	}
	return false;
}

The SetFocus function seems to work best with dialogs and their child controls. Where as on regular main windows the function call is sporatic at best.

It would seem to be no for now. If I can find a function that works with main windows then I'll have to let you know. Otherwise I have just tested two of the funtions and they will not work for the life of them. Damn Win16 functions! It would be nice if Microsoft would create something that would work all the time. Damn William Gates III!

I don't seem to have any trouble with this.

try setting the MDI child as having focus first (is active) then setfocus on the edit.

Or try SetWindowPos() to change the MDI childs Z order (top) then, as the parent has focus (is active), it may now allow the child control to get focus.




Try playing with the TAB stop and group settings (may help who knows?)

Oh, now I understand. I thought we were talking about top-level windows. I haven't tried this with MDIs or controls, just top-levels.