Beiträge von 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

  • Datei von Netzlaufwerk kopieren mit Progressbar

    Moin,

    die Routine entstammt offenbar den Beispielen für _WinAPI_MoveFileEx(). Leider hast Du Dir für den Parameter $iFlags einen 'unglücklichen' Wert ausgesucht.

    5 entspricht $MOVE_FILE_REPLACE_EXISTING (0x0001) + $MOVE_FILE_DELAY_UNTIL_REBOOT (0x0004).

    $MOVE_FILE_DELAY_UNTIL_REBOOT ist laut Doku für Dateien auf Netzlaufwerken nicht zulässig. Außerdem soll, wenn eine Datei auf ein anderes Laufwerk kopiert werden soll, das Flag MOVE_FILE_COPY_ALLOWED (0x0002) gesetzt werden.

    Ein 'glücklicherer' Wert für $iFlags wäre meiner Meinung nach deshalb 3.

  • Mit Shellexecute neue Programminstanz öffnen

    Moin,

    Zitat von hipfzwirgel

    So, mit dem folgenden Code geht es:

    Code
    $Homepage = "https://IP-Adresse
			If Not ProcessExists("firefox.exe") Then
				; Wenn Firefox nicht gestartet ist, starte eine Instanz
				ShellExecute($Homepage)
			Else
				; Wenn Firefox bereits gestartet ist, starte eine neue Instanz
				Run("C:\Program Files\Mozilla Firefox\firefox.exe -new-window " & $Homepage)
			EndIf

    Wenn immer Firefox in einem neuen Fenster gestartet werden soll, tut es auch:

    AutoIt
    $HomePage = "www.berlin.de" ; hier geht's zur Hauptstadt
$Browser = "firefox.exe"
ShellExecute($Browser, "-new-window " & $Homepage)

  • Cairo unter Autoit nutzen

    Nachschlag für UEZ

    Code
            DllCall($g_hCairoDLL, "none:cdecl", "cairo_move_to", "ptr", $pSurface, "double", $x, "double", $y)
        DllCall($g_hCairoDLL, "none:cdecl", "cairo_line_to", "ptr", $pSurface, "double", $iW, "double", $iH)
        DllCall($g_hCairoDLL, "none:cdecl", "cairo_stroke", "ptr", $pContext)

    Das kann nicht funktionieren, weil Du versuchst, auf $pSurface zu zeichnen.

  • Cairo unter Autoit nutzen

    Moin,

    ich habe mich gestern lange und intensiv mit den Beipielen beschäftigt. Dabei hatte ich immer wieder Rückschläge, die ich mir nicht erklären konnte. Kurz vor dem endgültigem Aufgeben entstand dann aber doch noch eine (überwiegend) funktionierende Lösung. Nach verdienter Nachtruhe habe ich die noch etwas aufgebohrt und bin jetzt recht zufrieden damit.

    Ich wollte von vornherein ohne Umwege über Bitmaps/BitBlts direkt mit dem DC arbeiten. Nach vielem Try&Error habe ich dann folgendes in der Cairo-Doku gelesen:

    Zitat

    The resulting surface will always be of format CAIRO_FORMAT_RGB24; should you need another surface format, you will need to create one through cairo_win32_surface_create_with_format() or cairo_win32_surface_create_with_dib().

    Windows unterstützt seit Version 8 nur noch 32-Bit (A)RGB. Das scheint nicht so recht zu cairo_win32_surface_create () passen. Ich habe deshalb für Win 10 die Funktion Cairo_CreateWin32SurfaceWithFormat mit $CAIRO_FORMAT_ARGB32 aufgerufen, und siehe, alles lief deutlich besser. Beim Versuch, ein Control als Zeichenfläche zu nutzen, musste ich zunächst feststellen, dass Cairo den gesamten Clientbereich des Elternfensters übermalt. Die Erklärung fand sich hier:

    Zitat

    The DC will be queried for its initial clip extents, and this will be used as the size of the cairo surface.

    Ich habe einfach mal vermutet, dass da etwas nicht passt, und eine passende Clipping-Region gesetzt. Das hatte tatsächlich den gewünschten Erfolg.

    Lange Rede, kurzer Sinn, hier kommt das Ergebnis all meiner Mühe. Es läuft hier stabil mit den DLLs aus dem ersten Beitrag mit 32 und 64 Bit:

  • Cairo unter Autoit nutzen

    Moin UEZ

    ich bin nicht sicher, meinst Du so etwas?

  • Hook auf die MsgBox

    Moin, noch ein Vorschlag, der allerdings statt der MsgBox einen Taskdialog verwendet:

    TaskDialogConstants.au3
    RadioBox.au3

    Vielleicht gefällt es dir ?

  • Verschiedene Werte beim Auslesen eines NFC-Tags

    Moin hipfzwirgel,

    Zitat von hipfzwirgel

    @ Velted: beim Abbruch stand immer die Zahl 1 in der Variable drin. Da er beim D bereits ausgestiegen ist.

    Ich habe nach dem Inhalt der Variablen $tKEYHOOKS.vkCode gefragt. Ich glaube nicht, dass die mit Inhalt 1 zum Abbruch führt. Aber ...

    Zitat von hipfzwirgel

    Ich glaube wir können das Thema nun als erledigt betrachten, da das Problem ja ohnehin schon gelöst ist.

    Danke für die Info.

  • Verschiedene Werte beim Auslesen eines NFC-Tags

    Moin,

    AutoIt
    Global $sHex = "1D70536A031080"
Global $sRev = ""
Global $iPos = 14 - 1
While $iPos > 0
	$sRev &= StringMid($sHex, $iPos, 2)
	$iPos -= 2
Wend
Global $iSNR = Dec($sRev, 2)
MsgBox(0, "SN", "Hex: " & $sHex & @LF & "Rev: " & $sRev & @LF & "Dez: " & $iSNR)

    ?

  • Gesamtzeit richtig berechnen

    Moin, auch wenn ich die auf Spiele ausgerichteten Skripte nicht gern unterstütze: Ich kann Dein Problem nicht finden.

    Du verwaltest eine "bisherige Gesamtspielzeit" in der Registrierung. Die kannst Du beim Start des Skripts einlesen. Sie kann sich nicht verändern.

    Das Skript startet das Spiel. Du musst Dir also nur einmal den Startzeitpunkt merken.

    Wenn Du auf "Aktuelle Spielzeit" drückst, musst Du die Differenz zur Startzeit berechnen. Wie Du sagst, klappt das bereits.

    Wenn Du auf "Aktuelle Gesamtzeit" drückst, musst Du die "Aktuelle Spielzeit" berechnen und den beim Start des Skripts eingelesenen Wert aus der Registrierung addieren.

    Wenn das Spiel (btw. das Skript?) beendet wird, musst Du die "Aktuelle Spielzeit" berechnen, den beim Start des Skripts eingelesenen Wert aus der Registrierung addieren und das Ergebnis in die Registrierung zurückschreiben.

    Wo klemmt es?

  • Skript mit F10 starten und mit F9 beenden

    Moin,

    ob mit oder ohne Webdriver, für mich ist noch offen, wann und wie auf F9/F10 reagiert werden soll.

    In den bisher eingestellten Beispielen wird der aktuelle Schleifendurchlauf 'in aller Ruhe' beendet. Das ursprüngliche Beispiel aus Beitrag #1 enthält mehrfach

    AutoIt
    ; Pause for 2 Minutes for changing the Dashboard
			Sleep(120000)

    Das könnte dann schon ein Weilchen dauern, bis das 'Durchschalten' durch die Dashboards beendet wird.

    DivineFaith, soll das so sein? Wenn nicht, was genau soll geschehen?