Beiträge von Velted

  • AutoIt Skript 32bit oder 64bit

    Moin,

    wenn eine 32-Bit-Anwendung auf einem 64-Bit-Windows laufen soll, stellt das System dieser Anwendung eine spezielle 32-Bit-Umgebung zur Verfügung. Das nennt sich WOW (Windows on Windows). Dabei kann natürlich immer mal etwas schief laufen. Ich würde deshalb prinzipiell auf einem 64-Bit-System AutoIt64 benutzen, soweit es möglich ist.

    Es gibt allerdings einige Kommunikationsprobleme zwischen 32- und 64-Bit-Anwendungen. Wenn man 32-Bit-Anwendungen nutzt, die man mit AutoIt steuern will, kann das mit AutoIt32 leichter sein.

  • Icon extrahieren - Skript läuft nicht

    Das klappt! ;) (Win 10)

  • au3-Datei Doppelklick - mit SciTE ausführen

    Moin,
    wenn Du in SciTE F5 (Go) drückst, wird Folgendes aufgerufen:

    Code: au3.properties
    # Commands to compile / run your script
command.go.$(au3)="$(SciteDefaultHome)\..\AutoIt3.exe" "$(SciteDefaultHome)\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "$(FilePath)" /UserParams $(1) $(2) $(3) $(4)

    Auf meinem Rechner entspricht das:

    Code
    "C:\Program Files (x86)\AutoIt3\AutoIt3.exe" "C:\Program Files (x86)\AutoIt3\SciTE\AutoIt3Wrapper\AutoIt3Wrapper.au3" /run /prod /ErrorStdOut /in "%1"

    Wenn Du das in der Registrierung unter HKEY_CLASSES_ROOT\AutoIt3Script\Shell\Open\Command ablegst, sollte bei Doppelklick der AutoIt3Wrapper die Ausführung gemäß der im Skript gefundenen Direktiven anstoßen.

    Alternativ kannst Du das auch beim Run Schlüssel ablegen. Du musst das Skript dann aber über das Kontextmenü starten.

    Ich habe das nicht probiert, weil ich bei Doppelklick das Script in SciTE anzeigen lasse.

  • Kontextmenü - Absturz

    Yepp!

    Der dritte Parameter hat den Windows-Typ wParam. wParam hat ptr Größe. Er hat nur in 32-Bit Umgebungen dieselbe Größe wie long (4 Bytes). In 64-Bit Umgebungen sind es 8 Bytes.

    DllCallbackRegister("_MyWindowProc", "ptr", "hwnd;uint;ptr;ptr") funktioniert auch, beschreibt die Parameter aber nicht so konkret.

  • _WinAPI_ShellChangeNotifyRegister 64bit - Absturz

    Hallo Oscar ,

    das ist eine von den 'Shell-Ausrichtungsfallen'. Die Struktur SHChangeNotifyEntry ist in ShlObj_core.h definiert. Da steht am Anfang ein
    #include <pshpack1.h>   /* Assume byte packing throughout */,
    das auch für die Struktur gilt und ein 'Byte-Packing' erzwingt.

    Deshalb:

    Code
    Func _WinAPI_ShellChangeNotifyRegister64($hWnd, $iMsg, $iEvents, $iSources, $aPaths, $bRecursive = False)
    Local $iPath = $aPaths, $tagStruct = 'align 1;' ; <<<<<<<<<<

  • _WinAPI_ShellChangeNotifyRegister 64bit - Absturz

    Moin,

    frohes neues Jahr! Hoffen wir mal, dass sich der Temperaturanstieg in 2025 gegenüber 2023 und 2024 wieder umkehrt und weniger Flächen überflutet werden.

    Zum Thema:

    Code
    For $i = 0 To UBound($aPaths) - 1
		$aPaths[$i] = _WinAPI_ShellILCreateFromPath(_WinAPI_PathSearchAndQualify($aPaths[$i]))
		DllStructSetData($tEntry, (@AutoItX64 ? 4 : 2) * $i + 1, $aPaths[$i]) ; bei 64Bit ist PIDLIST_ABSOLUTE = 64 Bit (4 Byte)
		DllStructSetData($tEntry, (@AutoItX64 ? 4 : 2) * $i + 2, $bRecursive)
Next

    Ich denke, dass sich der Feldindex (@AutoItX64 ? 4 : 2) * $i + 1 von 32- zu 64-Bit nicht ändert.

  • Ordner mit laufender Nummer

    Moin Moombas,

    Zitat von Moombas

    Zunächst einmal machst du auch eine doppelte Erstellung einer Variable (Zeile 5 und 8). Zeile in Zeile 5 auf 0 setzen, Zeile 8 weg lassen.

    Wenn man das macht, wird die jeweils erste Datei mit 0 geschrieben. Ich glaube nicht, dass das sein soll.

    Zitat von Moombas

    Dann bedenke bitte, wenn dies dein komplettes Skript ist, das "Local" hier die falsche Wahl ist, sondern "Global" genutzt werden muss, ...

    "muss" ist falsch, weil "Lokale" Variable im "global scope" automatisch "Global" sind. Es schafft allerdings Klarheit.

  • Ordner mit laufender Nummer

    Moin,

    weil Du Dich noch in einem frühen Stadium befindest möchte ich Folgendes anmerken:

    P202400001
    Solltest Du vorhaben, das Jahr in die Nummer aufzunehmen, wäre das 'doppelt gemoppelt', weil das Jahr ja schon im Datum steht ($sDatum = (@YEAR & "-" & @MON & "-" & @MDAY)). Außerdem musst Du dann bedenken, dass Du die laufende Nummer beim ersten Start in 2025 wieder auf 1 setzen musst.

    Wofür brauchst Du diese Nummer überhaupt?

    Grüße, Velted

  • sortieren nach IP

    Zitat von BugFix

    Das ist mir jetzt unklar. Was meinst du mit Speicherort?

    Die sogenannte 'Control-ID' (ListView-Einträge sind nunmal keine Controls) wird im Feld lParam der LVITEM Struktur abgelegt, die dem Eintrag zugeordnet ist. Dieses Feld kann aus Sicht des ListView-Controls mit beliebigen Informationen belegt sein. In AutoIt sollte man sich aber hüten, den Inhalt zu verändern. Die interne Verbindung von ListViewItem und ListView ginge dann wohl verloren.

    casi4712, ich möchte mich auch für die Offtopic-Nutzung Deines Beitrags entschuldigen. Das sollte sich jetzt auch erledigt haben.

  • sortieren nach IP

    Zitat von BugFix

    Wer hat dir denn diesen Bären aufgebunden?

    Moin,

    das war ich selbst. Ich vergesse immer wieder, dass AutoIt die ListView-Einträge wie eigenständige Controls behandelt. Danke für den Hinweis.

    Der Klick auf eine Zeile wird also tatsächlich signalisiert. Im OnEvent-Mode muss man aber jedem betroffenen 'Listvieweintragscontrol' eine eine Eventfunktion zugewiesen haben. Geliefert wird dann die Control-ID des Eintrags in @GUI_CtrlId. Die kann man in GUICtrlRead() benutzen, um den Inhalt der Zeile auszulesen. So weit, so gut.

    Leider hat das eigentliche ListView-Control von alldem keine Ahnung. AutoIt speichert zwar die Control-ID im Eintrag, der Speicherort hat aber für das ListView-Control keine besondere Bedeutung. Wenn man den Index des Eintrags auslesen will, den man für die 'normale' Bearbeitung der ListVieweinträge braucht, muss man den 'per Hand' ermitteln, z.B. mit _GUICtrlListView_FindParam().

    Zitat von BugFix

    Listview sind die am effektivsten verwertbaren Control überhaupt.

    Ich würde sagen, sie sind ebensogut verwertbar wie die anderen Controls, wenn man die zugehörigen UDFs einsetzt.

    Für das, was casi4712 vorhaben mag, sollte es in jedem fall reichen.

  • sortieren nach IP

    Moin casi4712,

    je intensiver ich mich mit deisem Beitrag beschäftige, als desto dürftiger entpuppen sich die Möglichkeiten, die AutoIt als native Funktionen anbietet, um auf Inhalte eines ListView-Controls zuzugreifen.

    ListViews gehören zu den 'geschwätzigsten' Controls. Sie neigen dazu, das Elternfenster mit Nachrichten zu 'fluten'. Nun stellt sich heraus, dass AutoIt sich von all den vielen Nachrichten genau eine herausgreift, die dem Skript gemeldet wird: Den Klick auf eine Spaltenüberschrift im Header! Alles, was mit Klicks im ListView-Bereich zu tun hat, wird schnöde unter den Tisch gekehrt. Das gilt sowohl für den GetMsg- als auch für den OnEvent-Modus. Wenn Du also per GUIGetMsg() oder EventFunc() eine Nachricht vom ListView erhältst, kannst Du Dir sicher sein, dass der Benutzer sich gerade mit dem Header beschäftigt. Ich bin erschüttert.

    Du hast nun das einzige 'Event' dafür verbraucht, die Spaltensortierungzu unterstützen. Mehr ist ohne 'Verrenkungen' auch nicht möglich. Was soll denn der Spaltenklick sonst noch auslösen?

  • Frage zu seltsamen Verhalten von _WinAPI_CopyFileEx

    Moin, in der Beschreibung zu Volatile steht:

    Zitat

    Callback Funktion: Während der Ausführung der Funktion wird die Nachrichtenverarbeitung des Skripts nicht blockiert, wie es normalerweise für nicht-volatile Funktionen erfolgt.

    Die Funktion wird damit "von einer Art Schutzschicht" befreit.

    Wenn Du versuchst, das Progressfenster zu bewegen, werden entsprechende Nachrichten an das Skript gesendet. Windows wartet standardmäßig etwa 5 Sekunden darauf, dass diese Nachrichten verarbeitet werden. Das geschieht offenbar nicht rechtzeitig, weil die laufende Callbackfunktion die Nachrichtenbearbeitung verhindert. Nach Ablauf der 5 Sekunden erstellt Windows ein Geisterfenster (eine Bitmap des Fensters mit dem Zusatz "Not Responding") als Ersatz für das nicht reagierende Fenster. Dieses Fenster kann bewegt werden, tut aber sonst nichts.

    Ergänzende Erläuterungen findest Du hier: IsHungAppWindow function

    Man kann das anscheinend auch für den laufenden Prozess abschalten, siehe DisableProcessWindowsGhosting()

  • Ordnerverzeichnis auslesen und in Array speichern, anschließendes weiterverarbeiten

    Moin,

    ich weiß nicht so recht, was Du erreichen willst. Wie ich es verstehe, soll das Skript im Profilmanager nacheinander alle vorhandenen Profile auswählen. Ist es das, was Du willst?


    AutoIt
        ; Alle Einträge kopieren, beginnend beim Startindex
    For $i = $startIndex To UBound($dirList) - 1
        ClipPut($dirList[$i])
        Send("^v")
        MouseClick("left", 1089, 722)
        $startIndex = $i + 1 ; Aktualisieren des Startindex für den nächsten Durchlauf
    Next

    Diese Schleife wird mit maximaler Geschwindigkeit ausgeführt und soll nacheinander alle vorhandenen Verzeichnisnamen in den Profilmanager kopieren. AutoIt wartet nach dem Send("^v") nicht, und der Profilmanager braucht Zeit, um die Daten aus dem Clipboard zu holen. Im schlimmsten Fall werden alle Verzeichnisnamen sich überschreibend in das Clipboard gestellt, bevor der erste Name ausgelesen wird. Die äußere While-Schleife bringt dann nichts mehr, weil Startindex auf den letzten Eintrag im Array zeigt.

    Mein Vorschlag wäre deshalb:

    • Äußere While-Schleife inklusive Sleep(9000) entfernen.

    • Nach Send("^v") etwas Zeit für die Verarbeitung einräumen.

      AutoIt
          ; Alle Einträge kopieren, beginnend beim Startindex
    For $i = 1 To UBound($dirList) - 1
        ClipPut($dirList[$i])
        Send("^v")
        Sleep(100) ; bei Bedarf verlängern
        MouseClick("left", 1089, 722)
        ; Sleep(100) ; evtl. noch eine Verarbeitungspause
    Next

    Auf gutes Gelingen,

    Velted