Handle des fokussierten Fensters bekommen
-
nein?
-
GetForegroundWindow ist schon richtig... was funktioniert da nicht? Beachte aber UIPI...
http://msdn.microsoft.com/en-us/windows7trainingcourse_uipi_unit.aspx
-
Pseudocode:
HWND GetCurrentFocusWindow() { HWND focusWnd=GetFocus(); if (focusWnd!=null) { return focusWnd; } else { HWND foregroundWnd = GetForegroundWindow(); if (foregroundWnd == null) { // Uns fehlen scheinbar Rechte ;/ return null; } else { int cur_thread_id = GetCurrentThreadId(); int other_thread_id = GetWindowThreadProcessId(foregroundWnd, IntPtr.Zero); AttachThreadInput(other_thread_id, cur_thread_id, true); focusWnd = GetFocus(); if (focusWnd != null) { return focusWnd; } } } return null; }
-
Warum so kompliziert? Begründung? Was ist anders zu "GetForegroundWindow"?
Das mit dem "AttachThreadInput" braucht man nur, wenn man es *setzen* will... aber nicht zum Auslesen...
-
ach verdammt ich hab die ganze zeit einen fehler übersehen, dass die ausgabe des fensters das im fokus ist nicht in der keyboardhook proc passiert sondern in der windowproc meiner anwendung...
dadurch scheint GetForegroundWindow() jetzt auch immer das richtige auszugeben, aber ich brauche noch den namen der anwendung aus dem HWND.
-
Jochen Kalmbach schrieb:
Warum so kompliziert? Begründung? Was ist anders zu "GetForegroundWindow"?
Das mit dem "AttachThreadInput" braucht man nur, wenn man es *setzen* will... aber nicht zum Auslesen...Hm. Da ist schon ein gewaltiger Unterscheid.
GetForegroundWindow liefert immer nur Top-Level Fenster. Also nie zum Beipsiel das Edit Control in einem Dialog.AttachThreadInput ist nötig wenn man GetFoxu für einen anderen Thread benötigt.
-
Die Methode heisst doch "Window"... und nicht "...Control"...
Nein, man braucht das AttachThreadInput nicht um das _Window_ zu erhalten...
-
Jochen Kalmbach schrieb:
Die Methode heisst doch "Window"... und nicht "...Control"...
Nein, man braucht das AttachThreadInput nicht um das _Window_ zu erhalten...Ich kann es aktuell nicht testen, aber ich meine wie SetForegroundWindow funktioniert es nur auf Top-Level Fenster.
-
In der MFC-Doku steht das, vermutlich bin ich dadurch auf den Trichter gekommen ^^
http://msdn.microsoft.com/en-us/library/b52w40kc(v=vs.110).aspx...ob das für das "echte" GetForegroundWindow() auch gilt k.A., aus der Doku kann man es da auf jedenfall nicht schließen
-
Martin Richter schrieb:
Ich kann es aktuell nicht testen, aber ich meine wie SetForegroundWindow funktioniert es nur auf Top-Level Fenster.
Hallo Martin, wir reden doch hier nur von Get Methoden. Dazu ist es nicht notwendig. Bei den Set Methoden ist es notwendig...
-
Jochen Kalmbach schrieb:
Die Methode heisst doch "Window"... und nicht "...Control"...
Nein, man braucht das AttachThreadInput nicht um das _Window_ zu erhalten...Ein Control ist auch nur ein Window.
Nur halt kein top-level Window.
-
Jochen Kalmbach schrieb:
Martin Richter schrieb:
Ich kann es aktuell nicht testen, aber ich meine wie SetForegroundWindow funktioniert es nur auf Top-Level Fenster.
Hallo Martin, wir reden doch hier nur von Get Methoden. Dazu ist es nicht notwendig. Bei den Set Methoden ist es notwendig...
Vielleicht reden wir aneinander vorbei.
Nach meinem Wissen liefert GetForegroundWindow das Parent des Controls, dass im anderen Thread den Focus hat. Niemals das Control das selbst den Focus hat.Auch SetFocus ist was ganz anderes als SetForegroundWindow...
-
Ja, dann reden wir vom gleichen... meine Aussagen hatten sich nicht auf den Focus bezogen.. sorry...
