GetWindowPlacement/GetWindowRect gibt als Pos immer 0 zurück

[LokutusvB]

Und auch hier wird wieder in den True-Teil gesprungen und Anweisung für Anweisung durchgeführt, ohne Fehler.

Bei GetWindowsRect kommt ebenso immer eine 0 als Ergebnis.

Hierbei handelt es sich um ein Warenwirtschaftsprogramm, in diesem Fall um das CRM-Modul, von dem ich dir schon berichtet hatte, eine spezielle Entwicklung. Mit diesem Fenster habe ich unter anderem ja auch das Problem, wie an andere Stelle schon beschrieben, daß IsWindowVisible oder auch (GetWindowLong(twHandle, GWL_STYLE) and WS_VISIBLE <> 0) eindeutig Nicht sichtbar festellen, obwohl ich dieses Fenster auf dem Bildschirm sehe. Zum Verzweifeln ist das. Ist es möglich, das ein Programm derart die Windows-API "verarschen" kann? Oder liegt es doch am Handle, obwohl ich mit eben diesem Handle (Die Ermittlung kennst du ja) das Fenster in den Vordergrund setzen kann bzw. via Timer das Ende ermitteln oder aber das Vorhanden sein ermitteln kann.

[Luckie]

Handlet es sich bei dem Fenster um eine DElphi VLC Anwendung? Wenn ja, gibt es zwei Fenster, einmal das unsichtbare Anwendungsfenster und einmal das für den Benutzer sichtbare Fenster für die Oberfläche.

[LokutusvB]

ich kann leider nicht sagen, mit was diese Anwendung entwickelt worden ist. Das ist ein eingekauftes Programm.

kann ich das von dir Beschriebene irgendwie festellen und entsprechend reagieren?

[Luckie]

Wenn die Fensterklassen mit "T" anfangen, wäre das ein Hinweis auf eine VCL-Anwendung.

[r29d43]

Mit den Programmen "Spy++" oder "Winspector Spy" müsste man eigentlich auch feststellen können, ob es noch mehrere Handles bzgl. deines Programms gibt. Also, u.U. mal danach googeln und dann downloaden.

[LokutusvB]

WinSight sagt mir Folgendes nach dem Programmstart:

Overlapped {XXXmain} X.exe (0,0)-(0,0) "XXX Hauptmenü"
Overlapped {XXXcon} X.exe (hidden) "XXX for Win32"
Overlapped {#32770:Dialog} X.exe (177,150)-(1101,846) "XXX Hauptmenü"

So wie ich das sehe, ermittel ich immer das erste Handle, deswegen auch die 0 als Rückgabe. Wieso aber kann ich dann damit so gut arbeiten was das Bringen in den Vordergrund sowie die Kontrolle des noch aktiv sein betrifft? Wie könnte ich das "richtige" Handle, so wie ich das sehe ich das das 3., ermitteln?

[r29d43]

Die Handles findest Du immer wieder mit FindWindow bzw. wenn es sich um Child-Windows handelt mit FindWindowEx (bei letzterem musst Du dich dann eben immer wieder vom TopLevel-Window aus bis zu diesem ChildWindow durchhangeln). Wichtig hierfür ist, dass dabei immer der exakten ClassTyp des Programms als Parameter angeben werden muss (das scheint hier bei WinSight der Ausdruck in der ersten geschweiften Klammer zu sein) und den ebenfalls exakten Window-Namen (also die Überschrift in der Title-Bar des Windows) hier bei WinSight wahrscheinlich der Ausdruck in den Anführungsstrichen.

[LokutusvB]

Und da sehe ich leider das Problem.

Folgende Sachen ergeben immer ein ungültiges Fensterhandle:
FindWindowEx(twHandle, 0, nil, nil)
FindWindowEx(0, twHandle, nil, nil)
FindWindowEx(twHandle, 0, '#32770:Dialog', 'XXX Hauptmenü')
FindWindowEx(twHandle, 0, '#32770:Dialog', nil)
FindWindowEx(twHandle, 0, nil, nil)

Mit FindWindowEx(0, twH1, 'XXXmain', 'XXX Hauptmenü') ermittle bzw. suche ich nach einer zusätzlich vorhandenen Instanz. Das klappt ja auch, wenn ich das Progamm 2 oder 3 mal starte. Aber wieso findet der das Handle dieses Dialoges nicht?

[r29d43]

Ich kenne jetzt WinSight leider nicht und weiß daher auch nicht, wie das die ChildWindows darstellt (eingerückt oder wie?).

Wenn <<Overlapped {#32770:Dialog} X.exe (177,150)-(1101,846) "XXX Hauptmenü">> das direkte ChildWindow von <<Overlapped {XXXmain} X.exe (0,0)-(0,0) "XXX Hauptmenü" >> ist, dann müsste <<FindWindowEx(twH1, 0, '#32770:Dialog', 'XXX Hauptmenü')>> eigentlich ein richtiges Ergebnis bringen.

Wenn allerdings <<Overlapped {#32770:Dialog} X.exe (177,150)-(1101,846) "XXX Hauptmenü"
>> das ChildWindow von <<Overlapped {XXXcon} X.exe (hidden) "XXX for Win32">> ist, dann musst du natürlich zuerst nochmal nach der Handle dieses Windows suchen und danach FindWindowEx nochmal dann eben mit diesem Handle als ersten Parameter starten.

[LokutusvB]

Das haut alles hinten und vorn nicht in.

Egal wie ich es anstelle, suche ich nach '#32770:Dialog', findet er kein Handle. Sage ich, er soll das nächste Handle zu con finden, findet er main. Sage ich, er soll das nächste Handle zu main finden, findet er nichts. Setzte ich con oder main als parent an, findet es bei beiden keine Child-handle.