Beiträge von Bitnugger

    Gibt es eine Möglichkeit, in einer Function die Zeile des Aufrufs zu verarbeiten ohne diese als Parameter zu übergeben? Also etwas wie @CallingScriptLineNumber?

    Nein, gibt es nicht. Du kannst der Funktion aber einfach einen optionalen Parameter übergeben und ihn mit @ScriptLineNumber vorbelegen.

    AutoIt
    _Test()
    _Test(1, 3)
    Func _Test($iScriptLineNumber = @ScriptLineNumber, $iError = @error)
    ConsoleWrite('$iScriptLineNumber = ' & $iScriptLineNumber & @CRLF)
    ConsoleWrite('$iError = ' & $iError & @CRLF)
    EndFunc


    Und: gibt es einen Weg, die @ScriptLineNumber auch im kompilierten Programm beim Debuggen oder bei Fehlermeldungen anzuzeigen?

    So evtl.:

    AutoIt
    #AutoIt3Wrapper_Run_Au3Stripper=y ; Run Au3Stripper before compilation (Default=n)
    #Au3Stripper_Parameters=/rsln ; Replace @ScriptLineNumber with the actual line number in the merged source. This is for debug purposes with compiled scripts.
    ; All master lines will show 2 numbers in the format xxx/yyy where xxx is the original master script line number and yyy the
    ; merged script line number.

    Bei mir funktioniert es so:

    In Dein While/WEnd musst Du aber noch eine ExitLoop-Bedingung einbauen, sonst läuft Dein Skript ewig - oder länger

    Genau das soll es ja auch... warten, bis ein Fenster mit dem Titel "Hinweis" den Fokus bekommt, dieses dann schließen und wieder auf das nächste Fenster mit dem Titel "Hinweis", das den Fokus bekommt, warten.


    Hi Bitnugger ich weiß nicht ob das ressourcenschonender ist, aber statt so einem Code, den wohl niemand nutzen würde, wäre es vllt. besser allgemein die Nutzung von ControlClick oder ControlSend vorzuschlagen.

    So ist es definitiv ressourcenschonender, weil nur das gemacht wird, was gemacht werden soll.


    Kann mir nicht vorstellen, dass es Leute gibt, die nachvollziehen können, was der Code genau macht und ihn trotzdem nicht nutzen.


    Besser allgemein die Nutzung von ControlClick oder ControlSend vorzuschlagen... indirekt habe ich das ja, indem ich anstelle von Send ControlClick verwendet habe.

    Send ist niemals erste Wahl... wenn möglich besser ControlClick oder ControlSend verwenden!!!


    Hier noch mal mein Code mit einer Verbesserung: REGEXPTITLE


    Close_Hinweis.au3 starten und laufen lassen:

    AutoIt: Close_Hinweis.au3
    While 1
    ControlClick(WinWaitActive("[REGEXPTITLE:^Hinweis$]"), '', '[CLASS:Button; Instance:1]')
    WEnd


    Open_Hinweis.au3 starten:

    AutoIt: Open_Hinweis.au3
    For $i = 1 To 3 Step 1
    MsgBox(64, 'Hinweis', 'Wird von Close_Hinweis.au3 geschlossen...')
    Next
    Exit MsgBox(64, 'Hinweisrichtlinien', 'Wird nicht von Close_Hinweis.au3 geschlossen...')

    Danke, jetzt fehlt mir noch eine Idee, wie ich bei einer GUI unterscheiden kann, ob der User Esc oder das X oben rechts gedrückt hat, da $GUI_EVENT_CLOSE bei beiden = True ist.

    ESC kannst du evtl. mit @HotKeyPressed oder mit Execute('@HotKeyPressed') ermitteln.


    Wenn oben rechts das X gedrückt wurde, bekommst du die Message $GUI_EVENT_CLOSE, und dann kommt es darauf an, wie du darauf reagierst:

    • ExitLoop ? dann ist der Exit-Mode = $EXITCLOSE_NORMAL
    • Exit ? dann ist der Exit-Mode = $EXITCLOSE_BYEXIT

    glaube ich zumindest... 8o

    Heißes Teil! Funktioniert soweit. Mal sehen, wie es sich Performance-mäßig schlägt.

    Ja, ist in der Tat ein heißes Teil... könnte man ja noch etwas perverser... so dass alle Keywords von AutoIt... :rofl:

    Wenn du mit den vielen RegExen fertig bist, kannst du dann eine Art "Sammlung von RegExen zum parsen von AutoIt" veröffentlichen?

    Das kann man sicher für irgendetwas gebrauchen

    Ja, gute Idee... und evtl. auch alle in einem Pack als Zip-Archiv. ;-)

    Da ich aber sowohl bei normalem Beenden wie auch bei Logoff in die gleiche Terminate-Funktion springe und dort @exitMethod abfrage, bekomme ich bei "normalem" Ende einen Fehler wegen der nicht existierenden @exitMethod (genau verstanden habe ich das allerdings nicht).

    Das Makro @exitMethod in der Terminate-Funktion ist nur dann verfügbar, wenn die Funktion von OnAutoItExitRegister aufgerufen wird und dies passiert nur dann, wenn eine der Exit-Mode-Bedingungen erfüllt ist.


    Springst du von anderer Stelle in diese Funktion, dann gibt es das Makro nicht, weil dann keine der Exit-Mode-Bedingungen erfüllt ist. Anstatt also die Terminate-Funktion direkt aufzurufen, könntest du einfach ein Exit machen, wodurch die Funktion dann auch aufgerufen wird und dann auch das Makro verfügbar ist.


    Testen ob das Makro existiert könnte man z.B. so:

    Das ist mbMn. aber kein guter Programmierstil...

    Was du suchst nennt sich AppBar.


    Hier ein kleines Example:

    Da ich mein SciTE auf UTF-8 umgestellt habe, rufe ich via Ownhotkeys ein Script auf, dass mir das Script, das in SciTE im aktuellen Tab angezeigt wird, nach UTF-8 konvertiert.


    Gestern ist mir aufgefallen, dass die shell.dll (File/Product version : 1.5.0.0 / 1.5.0.0), die ich zum Starten des Scripts benutze, das Script nicht findet, wenn der Pfadname länger als 141 Zeichen ist, bzw. die Gesamtlänge der Befehlszeile > 270 Zeichen ist.


    sCmd = "C:\Program Files (x86)\AutoIt3\SciTE\..\autoit3.exe" /AutoIt3ExecuteScript "f:\AutoIt\AutoIt3_Tools\_ConvertFileToUTF8.au3" "M:\Temp\Test_01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234.au3"

    shell.exec(sCmd) -- funktioniert nicht, weil sCmd > 270 Zeichen!


    sCmd = "C:\Program Files (x86)\AutoIt3\SciTE\..\autoit3.exe" /AutoIt3ExecuteScript "f:\AutoIt\AutoIt3_Tools\_ConvertFileToUTF8.au3" "M:\Temp\Test_0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123.au3"

    shell.exec(sCmd) -- funktioniert, weil sCmd <= 270 Zeichen!



    Ich habe zwei Versionen der shell.dll, die allerdings beide File/Product version : 1.5.0.0 / 1.5.0.0 haben:

    shell_1.zip 133.120 KB

    shell_2.zip 35.328 KB


    Leider ist der Link zur shell.dll und auch zum Quellcode nicht mehr aktuell... und hier wird auch nur die Version 1.2 angezeigt: https://scite-ru.bitbucket.io/pack/tools/LuaLib/shell.html


    Hat evtl. jemand den Quellcode der shell.dll?

    Dateien

    • shell_1.zip

      (54,48 kB, 14 Mal heruntergeladen, zuletzt: )
    • shell_2.zip

      (33,24 kB, 9 Mal heruntergeladen, zuletzt: )

    Ich habe hier zwei Scripts für euch...


    ScanArpCache.au3 - ist von mir und erfordert erhöhte Rechte für das Löschen des Arp-Cache!


    Examples:

    ScanArpCache.exe <MAC-Address>|<HostName>|<IP-Address> [<Wait>]

    ScanArpCache.exe <SubNet> [<Start>] [<End>] [<Wait>]



    arpscan.au3 - erste Version ist von SoulA, hier aber die von mir geänderte Version von dexto und diese erfordert keine erhöhten Rechte!

    Zusätzlich benötigt wird (ist aber alles im Archiv arpscan.zip enthalten):

    winpcapau3.zip - Hiervon wird die winpcap.au3 von arpscan.au3 als include geladen.

    npcap-0.9994.exe - Packet capture library for Windows - um (ARP-)Pakete mitlesen zu können, muss installiert werden, damit arpscan.au3 funktioniert.

    Alle nötigen Links sind in arpscan.au3 enthalten.


    PS: Habe winpcap.au3 entpackt und ein paar Zeilen geändert, das Archiv winpcapau3.zip ist aber original.

    Examples:

    arpscan.exe 192.168.1.1

    arpscan.exe 192.168.1.1-192.168.1.10


    Und so ne Schleife über alle IPs ist auch in AutoIt schnell gebastelt - nur halt unheimlich langsam.

    In ScanArpCache.au3 habe ich das so gelöst:

    AutoIt
    ; Sorgt dafür, dass die angepingten IPs inkl. MAC im ARP-Cache landen, wenn das Gerät erreichbar ist.
    Func _PingSubNet($sSubNet, $iStart = 1, $iEnd = 254, $iWait = 0)
    RunWait(@ComSpec & StringFormat(' /C FOR /L %%L IN (%i,1,%i) DO @ping >nul -4 -n 1 -w %i %s.%%L', $iStart, $iEnd, $iWait, $sSubNet), '', @SW_HIDE)
    EndFunc ;==>_PingSubNet

    Dateien

    • ScanArpCache.zip

      (455,83 kB, 19 Mal heruntergeladen, zuletzt: )
    • arpscan.zip

      (1,26 MB, 18 Mal heruntergeladen, zuletzt: )

    Bist du sicher?

    Ziemlich...


    arp -a Zeigt aktuelle ARP-Einträge durch Abfrage der Protokoll-Daten an.


    Arp-Cache löschen: arp -d

    arp -d funktioniert nicht ohne einen zweiten Parameter.

    So...

    arp -d Inet-Adr.

    oder so...

    arp -d *


    Aktuelle Einträge (arp -a) zu löschen macht wenig Sinn, da sich diese bei der nächsten Abfrage mit arp -a (ohne vorheriges Ping) wieder im Cache befinden.


    Ein Ping auf die Broadcast-Adresse des Subnetzes

    Das wäre natürlich sehr bequem, doch leider mit hoher Wahrscheinlichkeit nicht erfolgreich... ein Ping an jeden Host im Subnetz zu senden, ist sicherer.

    Ich hatte ja das Gefühl, dass "_WD_Loadwait($sSession)" nicht funktioniert...

    Kontrolliere doch einfach, was _WD_Loadwait zurückgibt:

    AutoIt
    Local $hTimer = TimerInit()
    Local $iLoadWait = _WD_Loadwait($sSession)
    ConsoleWrite("@@_Debug_line" & @TAB & @TAB & @ScriptLineNumber & " var: $iLoadWait --> " & $iLoadWait & @LF & "!@ " & @TAB & "#Error: " & @error & @LF) ; 1 (Success)
    ConsoleWrite('! ********************************************************* DiffTime --> ' & TimerDiff($hTimer) & @CRLF) ; 16.6406 ms

    Ob And aber (in AutoIt) eine höhere Priorität als Or besitzt, da bin ich mir nicht so sicher.

    Laut Operatoren liegen sie auf der gleichen Prioritätsebene.

    And und Or haben also dieselbe Priorität...


    ist es also zu betrachten wie in der Mathematik Punkt vor Strich Klammer zuerst? In diesem Fall And vor Or Klammer zuerst?

    Ja, genau wie in der Mathematik... nur musst du in AutoIt die Regeln beachten, die für die Operatoren festgelegt wurden und mit runden Klammern kannst du erzwingen, dass die darin enthaltenen Ausdrücke vorrangig ausgewertet werden.