Ist alles in Ordnung, Musashi?
Du solltest in deiner Firma mal nachfragen, ob diese Datei auf die Whitelist/Allowlist gesetzt werden kann.
Folgende Frage wurde gestellt von CHmux in der Shoutbox :
Zitat
... Wir haben aber in der Firma eine Whitelist-basierte Programmsperre. Ich kann keine EXE ausführen, für dich ich nicht freigeschaltet bin. AutoIt habe ich offiziell in der Whitelist und kann es also benutzen.
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.
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!? 
Also Problem gelöst?
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.
Hi Bitnugger.
Ich verstehe dein Problem nicht ganz. Wenn ich "ControlFocus()" benutze wie vorgesehen, funktioniert es doch richtig, oder?
ControlFocus($hGUI, '', $idListview)
Hey, coole Sache! Danke fürs Teilen!
Oh ja... ich denke ich habe die fehlerhafte Zeile gefunden:
Gleiches Testszenario wie in Posting #9.
Dein Script hat nun gut gearbeitet und alle Icons richtig positioniert!
Meine Testumgebung: Win 10 Pro, x64, Standard User (Admin)
Testablauf:
- Als erstes zur Sicherheit ein Backup mit ICU! 
- Das jeweilige Test-Script gestartet und die Sicherung der Icon-Positionen ausführen lassen.
- Dann einen neuen Oderner erstellt und 2 der vorhandenen Icons in den neuen Ordner verschoben.
- Icons auf dem Desktop von Hand gründlich durcheinander gewirbelt.
- Restore des jeweiligen Scripts durchgeführt.
Ergebnis:
Script von Veronesi hat das Testszenario bestanden und alle Icons richtig positioniert!
Script von Bitnugger hat mir alle Icons kreuz und quer um die Ohren gehauen!
Edit: Nach Fehlerbehebung hat das Script das Testszenario bestanden und alle Icons richtig positioniert!
ICU (Icon Configuration Utility) von KaFu hat mehr* als tadellos funktioniert! (* Setzt z.B. nach der Sicherung neu hinzugekommene Icons an eine vorher bestimmte Stelle.)
Wie wäre es mit dem Icon Configuration Utility von KaFu?
Noch bevor ich es auf autoitscript.com kannte, hatte ich ICU schon seit Jahren auf mehreren Rechnern in Betrieb, damals von KaFu's Webseite.
Falsch ist sie nicht... kombinieren kannst du die Flags beliebig... macht nur in einigen Fällen keinen Sinn,
Wow, strebst du eine Kariere als Politiker an? 
Ok, wenn ich dazu komme, werde ich es Tweaky und Water melden, dann können die beiden entscheiden. Danke für deine Infos!
Je mehr ich darüber nachdenke, desto unklarer wird es. In der Hilfe steht folgende Aussage:
FileOpen ( "filename" [, mode = 0] )
| mode | [optional] Modus in dem die Datei geöffnet werden soll. Kann auch eine Kombination aus folgenden sein: ... |
Du sagst:
... die Flags schließen sich also gegenseitig aus.
Stimmt... $FO_APPEND + $FO_OVERWRITE macht ja auch Sinn...
Auch wenn es nicht erkennbar ist, vermute ich, dass es sarkastisch gemeint war. Falls dem so ist, stimme ich zu, dass eine Kombination der beiden Werte KEINEN Sinn machen. Auch von den anderen Werten widersprechen sich einige, z.B. die Zeichenkodierungen.
Also, der langen Rede kurzer Sinn, heruntergebrochen auf eine einfache Frage: Ist die oben genannte Aussage in der Hilfe falsch?
$FO_READ ist 0 und ergibt in Kombination mit $FO_APPEND = $FO_APPEND... also entweder $FO_READ, oder $FO_APPEND, oder $FO_OVERWRITE... die Flags schließen sich also gegenseitig aus.
Bist du sicher?
Ja...
Soeben getestet - mit $FO_APPEND ($FO_READ + $FO_APPEND = $FO_APPEND) funktioniert FileReadLine nur in Kombination mit FileSetPos!
Das war wohl falsch, denn die Flags schließen sich NICHT gegenseitig aus!
Wie du siehtst, ist es erstmal nötig, Klarheit reinzubringen. Auch solltest du am Ende alle FileHandles mit FileClose() schließen.
Sehr nett formuliert...
Vielen Dank!
die Zeile hast du wohl übersehen?
Nein! Ich baue eigentlich ständig ein paar kleine Schriebfleher ein, nur um dich zu testen! 
$FO_READ ist 0 und ergibt in Kombination mit $FO_APPEND = $FO_APPEND... also entweder $FO_READ, oder $FO_APPEND, oder $FO_OVERWRITE... die Flags schließen sich also gegenseitig aus.
Bist du sicher? 
In der AutoIt Hilfe zu FileOpen() in Beispiel 2, Zeilen 11 und 12:
; Öffnet eine Datei für den Lese/Schreib-Zugriff.
Local $hFileOpen = FileOpen($sFilePath, $FO_READ + $FO_OVERWRITE)
Hallo Chaspel.
Kann man dieses Script irgenwie umschreiben, damit es schneller geht?
Ich bin mir nicht sicher, was du erwartest. Am besten schreibst du dein Code-Beispiel um, sodass es denen klarer wird, die helfen sollen. 
So hast du z.B. $FileName2, aber ich kann nirgends $FileName1 entdecken. Dann überschreibst du $FileName2 und erhältst $hFilehandle2, das du nirgends benutzt, und $file_name ist in Wirklichkeit ein FileHandle.
Wie du siehtst, ist es erstmal nötig, Klarheit reinzubringen. Auch solltest du am Ende alle FileHandles mit FileClose() schließen.
Leider ist die Liste im .txt File grösser als das Array erlaubt.
Bist du sicher, dass deine Text-Datei 16777216 Zeilen enthält? Das sind fast 17 Millionen. 
Edit: Andy Scheinbar haben wir das Gleiche gedacht, nur warst du 2 Minuten früher.
Gibt es einen Weg beides zu bekommen (Dateien auf C:\ speichern und Drag & Drop?)
Ohne Gewähr und ungetestet: Hast du es mal mit einem Unterordner probiert?
Bei mir funktioniert alles, gestartet in SciTE, PSPad, oder direkt mit der AutoIt3.exe (ohne Editor), ziehen auf das ListView, ziehen auf die GUI => keine Probleme.
Mein System ist Win 10 x64, Standard-Admin (wie er beim Installieren von Windows angelegt wird).
Da waren sie wieder, meine 3 ListView Probleme! ... Prima, dann ist ja 1 gelöst! 
Nun aber zurück zum eigentlichen Thema. Wer kann noch was zum Thema Drag & Drop beitragen
Wie ist denn dein letzer Stand, wie sieht dein Code nun aus? Funktionieren die Tipps von B&B?
Fazit: $WS_EX-Styles mit GUICtrlCreateListView und $LVS_EX-Styles mit _GUICtrlListView_SetExtendedListViewStyle setzen.
Unterstreich! 
Wollte gerade das Gleiche schreiben.
Habe nochwas entdeckt. Wenn du beim Erstellen des ListViews $LVS_EX_GRIDLINES benutzt, wird das 2x ausgewertet:
Kannst du ganz einfach testen, indem du es mal beim ListView1 wegmachst.
In Zeile 22 habe ich den exStyle ausgelesen, in $OldLvwExStyle gespeichert und dann im nächsten BitOr dazu gegeben. Um den Rahmen zu erhalten, braucht man das scheinbar nicht. Dann genügt:
