_WinAPI_FindTextDlg() - Example --> APPCRASH - Fehlermodulname: StackHash_f32c

  • Moin ;)

    Ab und an nehme ich mir die Zeit und durchforste die AutoIt-Hilfe... vornehmlich Themen, die seltener benötigt werden.

    Vorgestern bin ich dann bei der Funktion _WinAPI_FindTextDlg() gelandet, die allerdings, zumindest bei mir, nicht funktioniert und AutoIt zum Absturz bringt. Nach dem Start des Example tippe ich Alt+E/F und gebe dann "v3" (ohne "" [Alt+W funktioniert nicht]) als Suchbegriff ein... die MsgBox petzt mir, dass der gesuchte Text nicht gefunden wurde... und dann... nichts machen... nur entspannt zurücklehen... ein paar Sekunden später und AutoIt hängt - oder auch nicht, aber dann ist das Menu nicht mehr auswählbar!


    Vorhin habe ich mir die aktuelle Version von AutoIt installiert und die Funktion erneut gestartet, doch der Fehler tritt nach wie vor immer noch auf.

    Im Anhang liegt nun eine Version, bei der ich einige Zeilen geändert/eingefügt habe, um dem Fehler auf die Schliche zu kommen... bei Zeile 108 ist meist Ende im Gelände.

    Wieso AutoIt abstürzt, habe ich leider nicht klären können...

  • Das Beispiel aus der Hilfe der 3.3.10.2 funktioniert.
    Jedenfalls beim ersten Mal "Suchen"!
    Schaut euch mal die Verwendung der Variable $hRichEdit an, in der Funktion WM_FINDMSGSTRING wird sie einmal als Pointer verwendet, und gleichzeitig als Handle für´s Richedit-Control der GUI.

  • Schaut euch mal die Verwendung der Variable $hRichEdit an, in der Funktion WM_FINDMSGSTRING wird sie einmal als Pointer verwendet, und gleichzeitig als Handle für´s Richedit-Control der GUI.

    Was vollkommen richtig ist, weil HANDLE auch nur ein Pointer-Typ ist. Genauer ist HANDLE als PVOID definiert, also ein void-Pointer. Siehe Windows Data Types

    Hat noch wer das Problem, dass bei $iFlags falsche Werte stehen?
    Mir wird angezeigt, dass ich ReplaceAll ausgewählt habe obwohl ich FindNext im Dialog angezeigt habe.

    Einmal editiert, zuletzt von CentuCore (19. Juli 2015 um 12:47)

  • Es sollte keinen Unterschied machen
    .., weil $hRichEdit als lParam übergeben wird und in der Funktion wieder "extrahiert" wird.
    .., weil Pointer und Handle Bit- und Implementierungsweise dasselbe sind.

    Ich find's aber interessant, dass bei jedem was anderes rauskommt. Bei mir kommen falsche Werte in $iFlags vor beim TO crasht gleich das ganze Script.

  • Also AutoIt stürzt ab, weil (worauf hingewiesen haben Oscar und Andy) eine lokale Variable $hRichEdit, in der WM_FINDMSGSTRING, eigtl den Wert der globalen $hRichEdit bekommen sollte, aber in Wahrheit nur irgendein Datenmüll ist.
    Ich hab in msdn nachgeschaut ob man in einer FINDMSGSTRING Funktion sich verlassen kann, dass das Element "lCustData"(in AutoIt heißt es "lParam") der Struktur FINDREPLACE denselben Wert hat wie per _WinAPI_FindTextDlg() angegeben...konnte aber dazu nichts finden und gehe davon aus, dass man da lieber kein Geld drauf wetten sollte.

    Der Crash kommt dadurch zustande
    .., dass die lokale Variable $hRichEdit kein gültiges Handle ist
    .., dass_GUICtrlRichEdit_FindTextInRange() kein Array return'ed wenn zB kein gültiges Handle angegeben ist (das ist aber ein Fehler des/der UDF-ErstellerIn...schlichtweg nicht dokumentiert und man muss den Code der Funktion lesen um das zu bemerken -,- )
    und der Code nicht prüft ob $aPos überhaupt ein Array ist, davon aber ausgeht und dann eben jener "Subscript used on non-accessible variable"-Fehler ausgelöst wird.

  • Andy meint damit, dass $hRichEdit einmal als globale Variable für das Richedit-Control verwendet wird und einmal als lokale Variable für den Pointer.
    Innerhalb der Funktion wird die Pointer-Variable für die Befehle verwendet, was offensichtlich zum Crash führt (Script fehlerhaft).

    Es sollte keinen Unterschied machen
    .., weil $hRichEdit als lParam übergeben wird und in der Funktion wieder "extrahiert" wird.
    .., weil Pointer und Handle Bit- und Implementierungsweise dasselbe sind.

    Ich gebe dir dahingehend Recht, dass ein Handle auch nur ein Pointer auf einen Datenbereich ist.

    Was ich allerdings nicht verstehe ist die Tatsache, dass in derselben Funktion einmal das per LPARAM von der Message übergebene Handle benutzt, uns GLEICHZEITIG das RicheditControl verwendet werden soll. Das kann nur dann funktionieren, wenn sowohl der LPARAM als auch $hRichEdit auf den gleichen Datenbereich zeigen, und das ist definitiv nicht der Fall!
    $hRichEdit hat andere Werte als Ptr(DllStructGetData($tFINDREPLACE, 'lParam'))

    Aber da ich ehrlich gesagt keinerlei Lust habe, dieses Zeugs zu debuggen, bleibt nur der Rat, mal beim UDF-Ersteller nachzufragen. Viel Spass dabei :P