ControlGetPos($hControl, '', '')

  • So wie im Titel angegeben, mache ich es sehr oft mit ControlGetPos und hatte bis dato kein Problem damit gehabt... aber das hat sich nun geändert!

    Die für den "Fehler" relevanten Zeilen:

    _WinAPI_SetWindowLong($hEdit, $GWL_HWNDPARENT, $hListView) ; Setzt das Handle des Parentfensters für $hEdit auf $hListView - das allein löst aber keinen Fehler aus!

    ControlFocus($hEdit, '', '') ; Das ist der Bösewicht... ControlGetPos($hListView, '', '') und ControlFocus($hListView, '', '') funktionieren danach nicht mehr richtig!

    Lege ich den Fokus auf ein anderes Control, z.B. ControlFocus($hOK, '', ''), funktioniert wieder alles...

    Was sagt ihr dazu?

    Hier das Test-Script:

  • Hi Bitnugger.

    Ich verstehe dein Problem nicht ganz. Wenn ich "ControlFocus()" benutze wie vorgesehen, funktioniert es doch richtig, oder?

    ControlFocus($hGUI, '', $idListview)

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Ich verstehe dein Problem nicht ganz. Wenn ich "ControlFocus()" benutze wie vorgesehen, funktioniert es doch richtig, oder?

    Hehe... ja, sicher, wie vorgesehen... das ist ja auch unverwechselbar... nur gibt es halt auch Controls, für die keine ControlID verfügbar ist... deshalb habe ich mir angewöhnt, nur das Handle des Controls zu nehmen... und unter "normalen" Bedingungen funktioniert das ja auch tadellos.

    Bei ControlGetPos gebe ich dann ja als ersten Parameter auch das unverwechselbare Handle des Controls an... Text und ID kann ich mir somit ersparen, dachte ich... aber wie man sieht, eben nicht immer... und wie schon erwähnt... was machen, wenn das Control keine ID hat?

    ControlGetPos($hGUI, "", "[CLASS:Blabla; INSTANCE n]") wäre eine Möglichkeit... nur blöd, wenn sich die Instanz dann im Laufe des Betriebs ändert...

    Das Problem hier ist, dass ControlGetPos($hControl, '', '') nur dann korrekt funktioniert, wenn der Fokus nicht auf einem der Controls liegt, die durch _WinAPI_SetWindowLong() beeinflußt wurden.

    Die erste Frage ist also: Was hat ControlGetPos mit dem Fokus zu tun?

  • Da fehlt die ControlID:

    Darum geht es doch gar nicht... denn ControlFocus($hEdit, '', '') funktioniert ja... und zwar immer, weil $hEdit ja das Handle des Controls ist und somit auch unverwechselbar ist, weshalb dann für Text und ID ein Leerstring reicht.

    Das Problem ist, dass ControlGetPos dann unterschiedlich reagiert, wenn... siehe Post #3.

  • was machen, wenn das Control keine ID hat?

    _WinAPI_SetFocus($hListView)

    Das Problem hier ist, dass ControlGetPos($hControl, '', '') nur dann korrekt funktioniert, wenn der Fokus nicht auf einem der Controls liegt, die durch _WinAPI_SetWindowLong() beeinflußt wurden.


    Die erste Frage ist also: Was hat ControlGetPos mit dem Fokus zu tun?

    Tja, gute Frage. Ich hatte es vor kurzem auch mit "bösen" AutoIt Funktionen zu tun, darunter "WinGetCaretPos()", "ControlGetFocus()" und "ControlGetPos()". Dabei habe ich auch mit jpm (AutoIt Developer) darüber diskutiert und es ging um das Vodergrund-Fenster, das scheinbar durch verschiedene "böse" Funktionen auch mal aktiviert wird.

    Der langen Rede kurzer Sinn: Es ist wie's ist, eine Änderung der "bösen" Funktionen ist nicht in Aussicht! :(

    Zum Glück konnten mithilfe der User andere Funktionen gefunden werden, die die "bösen" ersetzen. :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

    2 Mal editiert, zuletzt von Professor Bernd (16. Januar 2021 um 20:23)

  • Also Problem gelöst?

    Es ist weniger ein Problem, sondern vielmehr eine Verständnisfrage... denn im ersten Post habe ich ja bereits im Script gezeigt, wie ich zum korrekten Ergebnis komme.

    Was sagt ihr dazu?

    Ich formuliere sie mal anders: Wieso beeinflußt der Fokus das Ergebnis von ControlGetPos($hListView, '', '') und wieso wird der Fokus bei ControlFocus($hListView, '', '') auf "Edit1" gesetzt?

    Letzteres kann ich ja noch halbwegs nachvollziehen... weil $hListView mit _WinAPI_SetWindowLong zum Parent-Window für $hEdit gemacht wurde...

    2 Mal editiert, zuletzt von Bitnugger (16. Januar 2021 um 22:48)

  • Das habe ich in Posting #6 beantwortet:

    Ich hatte es vor kurzem auch mit "bösen" AutoIt Funktionen zu tun, darunter "WinGetCaretPos()", "ControlGetFocus()" und "ControlGetPos()". Dabei habe ich auch mit jpm (AutoIt Developer) darüber diskutiert und es ging um das Vodergrund-Fenster, das scheinbar durch verschiedene "böse" Funktionen auch mal aktiviert wird.

    Es ist weniger ein Problem, sondern vielmehr eine Verständnisfrage...

    Dieses Interesse teile ich mit dir. Wie gesagt, konnte ich keine Antwort darauf erhalten. Ich hatte es aber auch nicht speziell als Verständnisfrage geschrieben. Vielleicht hast du mehr Glück!? :thumbup:

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Allem Anschein nach verhält es sich so:

    Alle Control*()-Funktionen erwarten als ersten Parameter etwas, mit dem das Handle eines Windows identifiziert werden kann. Dort kann alternativ auch direkt das Handle eines Controls angegeben werden, solange dieses selbst keine Child-Windows hat. Ist der erste Parameter eindeutig, kann für die beiden folgenden Parameter einfach ein Leerstring übergeben werden, ohne das Probleme zu erwarten sind.

    Hat das Control allerdings selbst Child-Windows, kann der Fokus nur auf eines dieser Childs gesetzt werden, was dazu führt, dass dann alle Control*()-Funktionen ebenfalls das Handle des Childs verwenden... also das Handle des Controls, dass den Fokus hat.

  • Hat das Control allerdings selbst Child-Windows, kann der Fokus nur auf eines dieser Childs gesetzt werden, was dazu führt, dass dann alle Control*()-Funktionen ebenfalls das Handle des Childs verwenden... also das Handle des Controls, dass den Fokus hat.

    Scheint mir irgendwie logisch. Dadurch dass ein Control ein Child bekommt wird es zu einem Parent-Window. Wenn man dann "Control...()"-Funktionen benutzt und das Handle des Controls mit dem Child an der Stelle des Parent-Windows einfügt (Param 1) und die Control-ID mit "" angibt (Param 3), wird das Parent-Control als Parent-Window genommen und das Child mit dem Fokus als gesuchtes Control angenommen.

    Mir sind auch andere Funktionen begegnet, die einen leeren String "" als aktives Window/Control interpretieren, wie z.B. die "WinGet...()"-Funktionen.

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Wenn Du bei ControlFocus das Child korrekt setzt: ControlFocus($hEdit, '', $hListView), dann geht ControlGetPos auch mit Leerstrings: ControlGetPos($hListView, '', '').

    Danke für dein Feedback... ich denke zwar, dass es so nicht korrekt ist, obwohl es funktioniert, aber es hat mich dennoch auf den Weg der Erleuchtung gebracht!

    Die ersten drei Parameter der Control*()-Funktionen sind ja immer gleich...

    Control* ( "title", "text", controlID ...

    ParameterErklärungBemerkungspez. Beschreibungen
    titleThe title/hWnd/class of the window to access.Parent-WindowTITLE, TEXT, REGEXPTITLE, REGEXPCLASS, LAST, ACTIVE, X \ Y \ W \ H, INSTANCE
    textThe text of the window to access.kann in Verbindung mit title angegeben werdenirgendein Text, den AutoIt sehen kann, z.B. von einem Edit, Input, Button.
    text wird als SubString behandelt.
    Versteckte Fenster können nur durch den title gefunden werden, wenn text leer ist.
    controlIDThe control to interact with.ControlID, TEXT, CLASS, CLASSNN, NAME, REGEXPCLASS, X \ Y \ W \ H, INSTANCE

    Als controlID kann auch das Handle des Controls ($hEdit, $hListView) angegeben werden, was der Hilfe aber nicht zu entnehmen ist... dann dürfen die ersten beiden Parameter auch Leerstrings sein.