Beiträge von alpines

Du hast glaube ich dein Skript angepasst da jetzt keine Dezimalwerte ausgegeben werden sondern die Hex-Werte abgeschnitten sind im Dump (81 müsste 0x81 sein oder 129).

Kannst du dein neues Skript nochmal posten? Das angepasste von mir liefert ganz andere Werte (von der Hex/Dec-Verwechslung mal abgesehen.)

#include <WinAPIConstants.au3>
#include <WinAPISys.au3>
#include <WinAPIvkeysConstants.au3>

Local $vkCode = 0x51
Local $ScanCode = 0x10

Local $tKeyboardState = _WinAPI_GetKeyboardState()

DLLStructSetData($tKeyboardState, 1, 0x81, $VK_CONTROL + 1)
DLLStructSetData($tKeyboardState, 1, 0x81, $VK_MENU + 1)

Local $kbdState = DllStructGetPtr($tKeyboardState)

DLLStructSetData($tKeyboardState, 1, 0x80, $VK_LSHIFT)
DumpDLLArray($tKeyboardState, 256, "Keyboard State", 1)

Local $Result = ""
Local $ret = _User32_ToUnicodeEx($vkCode, $scanCode, $kbdState , $Result, 5,0, _WinAPI_GetKeyboardLayout(_WinAPI_GetDesktopWindow ( )))

ConsoleWrite("ScanCode - " & $scanCode & @TAB & "vkCode - " & $vkCode & " [" & $Result &"]" & @CRLF)


Func _User32_ToUnicodeEx($wVirtKey, $wScanCode, $lpKeyState, ByRef $pwszBuff, $cchBuff, $wFlags, $dwhkl)
    Local $vRetVal = DllCall("user32.dll", "int", "ToUnicodeEx", "UINT", $wVirtKey, "UINT", $wScanCode, "ptr", $lpKeyState, "wstr", $pwszBuff, "int", $cchBuff, "UINT", $wFlags, "hwnd", $dwhkl)
    $pwszBuff = $vRetVal[4]
    Return $vRetVal[0]
EndFunc

Func DumpDLLArray($Array,$LengthOfArray,$NameOfArray,$ElementNumber = 1)
   ConsoleWrite("Dump of " & VarGetType($Array) & " " & $NameOfArray & @CRLF)
   ConsoleWrite("-------------------------------" & @CRLF)
   For $i = 1 to $LengthOfArray
      If MOD($i,16) = 1 then
         ConsoleWrite(StringFormat("[%4d]",$i))
      EndIf
      ConsoleWrite(StringFormat("%4s",DllStructGetData($Array,$ElementNumber,$i)))
      If MOD($i,16) = 0 then
         ConsoleWrite(@CRLF)
      EndIf
   Next
   ConsoleWrite(@CRLF)
endfunc

Dump of DLLStruct Keyboard State
-------------------------------
[   1]   0   1   1   0   0   0   0   0   0   0   0   0   0   0   0   0
[  17]   0 129 129   0   0   0   0   0   0   0   0   0   0   0   0   0
[  33]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  49]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  65]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  81]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[  97]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 113]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 129]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 145]   1   0   0   0   0   0   0   0   0   0   0   0   0   0   0 128
[ 161]   1   1   0   0   1   0   0   0   0   0   0   0   0   0   0   0
[ 177]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 193]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 209]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 225]   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
[ 241]   1   0   0   1   0   0   1   0   0   0   0   1   0   0   0   0

ScanCode - 16    vkCode - 81 [@]

Interprozesskommunikation ist das Stichwort.

AutoIt hat da NamedPipes als UDF im Angebot, google mal einfach danach und schau dir ein paar Beispiele an.

Zitat von aSeCa

Scheint doch leider nicht rund zu laufen: GUI hängt sich immer auf, wenn ich via GuiCtrlSetOnEvent eine Anpassung an einer der GUIs mache.

Ich schätze mal, dass sich dort das ganze im Kreis dreht. Dein Event triggert die UDF welche wiederum dein Event triggert.

Zitat von ArminLinder

Gerne! Da das Gesamtprojekt doch etwas größer ist, habe ich einen Teil herausgetrennt, der das Problem zeigt.

Hervorragend, genau so wollte ich es haben.

Zitat von ArminLinder

Problem 1: DumpDLLArray hat ein Problem, da es BEIM dUMP VON $kbdState 256 Nullwerte ausgibt. Es muss aber mindestens 3 Werte <> 0 geben, da ich in der Zeile vorher ja einen zu setzen versuche, und auzßerdem bevor ich das Scriupt gestartet habe Caps-Lock nd Num-Lock aktiviert habe. Selbst wenn mein Versuch, DLLStructSetData zu verwenden, irgendwie faul gewesen wäre, müssten noch die Bytes VK_CAPITAL (0x14) und VK_NUMLOCK (0x90) den Wert 0x80 haben. Der Dump sagt, haben sie nicht, aber die Konsole sagt,:

Das Problem ist hier schnell identifiziert. Du greifst auf den DllStruct falsch zu.

Zitat von ArminLinder

ConsoleWrite(StringFormat("%4s",DllStructGetData($Array,$ElementNumber,$i)))

$Array ist der 1. Parameter deiner Funktion, und du übergibst

Zitat von ArminLinder

Local $kbdState = DllStructGetPtr(_WinAPI_GetKeyboardState())

$kbdState als $Array.

Die DllStructSetData/DllStructGetData-Funktion kann allerdings mit DllStruct-Pointern NICHTS anfangen. Du musst innerhalb der Funktion erst ein DllStruct erzeugen.

DllStructCreate akzeptiert als 2. Parameter einen "pointer". Dieser Pointer ist genau das was DllStructGetPtr zurückgibt.

Wenn du nun DllStructCreate mit dem selben Struct erstellst wie in _WinAPI_GetKeyboardState() und als Pointer $kbdState übergibst, dann kannst du innerhalb deiner Funktion auch die Werte lesen.

Du kannst dir die Arbeit auch sparen und einfach den Struct übergeben den _WinAPI_GetKeyboardState erzeugt.

Hier die Variante nur mit dem DllStruct ohne Pointer:

#include <WinAPIConstants.au3>
#include <WinAPISys.au3>
#include <WinAPIvkeysConstants.au3>

Local $vkCode = 0x31        ; VK_Code der "1"
Local $ScanCode = 0x02        ; testennumemr auf dem PC Keyboard

Local $tKeyboardState = _WinAPI_GetKeyboardState()
Local $kbdState = DllStructGetPtr($tKeyboardState)

DLLStructSetData($tKeyboardState, 1, 0x80, $VK_LSHIFT)
DumpDLLArray($tKeyboardState, 256, "Keyboard State", 1)

Local $Result = ""
Local $ret = _User32_ToUnicodeEx($vkCode, $scanCode, $kbdState , $Result, 5,0, _WinAPI_GetKeyboardLayout(_WinAPI_GetDesktopWindow ( )))
If $ret > 0 Then
   ConsoleWrite("ScanCode - " & $scanCode & @TAB & "vkCode - " & $vkCode & " [" & $Result &"]" & @CRLF)
EndIF

Func _User32_ToUnicodeEx($wVirtKey, $wScanCode, $lpKeyState, ByRef $pwszBuff, $cchBuff, $wFlags, $dwhkl)
    Local $vRetVal = DllCall("user32.dll", "int", "ToUnicodeEx", "UINT", $wVirtKey, "UINT", $wScanCode, "ptr", $lpKeyState, "wstr", $pwszBuff, "int", $cchBuff, "UINT", $wFlags, "hwnd", $dwhkl)
    $pwszBuff = $vRetVal[4]
    Return $vRetVal[0]
EndFunc

Func DumpDLLArray($Array,$LengthOfArray,$NameOfArray,$ElementNumber = 1)
   ConsoleWrite("Dump of " & VarGetType($Array) & " " & $NameOfArray & @CRLF)
   ConsoleWrite("-------------------------------" & @CRLF)
   For $i = 1 to $LengthOfArray
      If MOD($i,16) = 1 then
         ConsoleWrite(StringFormat("[%4d]",$i))
      EndIf
      ConsoleWrite(StringFormat("%4s",DllStructGetData($Array,$ElementNumber,$i)))
      If MOD($i,16) = 0 then
         ConsoleWrite(@CRLF)
      EndIf
   Next
   ConsoleWrite(@CRLF)
endfunc

Hier mal wie du es mit dem Pointer hättest machen müssen:

#include <WinAPIConstants.au3>
#include <WinAPISys.au3>
#include <WinAPIvkeysConstants.au3>

Local $vkCode = 0x31        ; VK_Code der "1"
Local $ScanCode = 0x02        ; testennumemr auf dem PC Keyboard

Local $tKeyboardState = _WinAPI_GetKeyboardState()
Local $kbdState = DllStructGetPtr($tKeyboardState)

DLLStructSetData($tKeyboardState, 1, 0x80, $VK_LSHIFT)
DumpDLLArray($kbdState, 256, "Keyboard State", 1)

Local $Result = ""
Local $ret = _User32_ToUnicodeEx($vkCode, $scanCode, $kbdState , $Result, 5,0, _WinAPI_GetKeyboardLayout(_WinAPI_GetDesktopWindow ( )))
If $ret > 0 Then
   ConsoleWrite("ScanCode - " & $scanCode & @TAB & "vkCode - " & $vkCode & " [" & $Result &"]" & @CRLF)
EndIF

Func _User32_ToUnicodeEx($wVirtKey, $wScanCode, $lpKeyState, ByRef $pwszBuff, $cchBuff, $wFlags, $dwhkl)
    Local $vRetVal = DllCall("user32.dll", "int", "ToUnicodeEx", "UINT", $wVirtKey, "UINT", $wScanCode, "ptr", $lpKeyState, "wstr", $pwszBuff, "int", $cchBuff, "UINT", $wFlags, "hwnd", $dwhkl)
    $pwszBuff = $vRetVal[4]
    Return $vRetVal[0]
EndFunc

Func DumpDLLArray($Array,$LengthOfArray,$NameOfArray,$ElementNumber = 1)
    Local $tInstanced = DllStructCreate("byte[256];", $Array) ;Array ist in diesem Fall der Pointer $kbdState

   ConsoleWrite("Dump of " & VarGetType($Array) & " " & $NameOfArray & @CRLF)
   ConsoleWrite("-------------------------------" & @CRLF)
   For $i = 1 to $LengthOfArray
      If MOD($i,16) = 1 then
         ConsoleWrite(StringFormat("[%4d]",$i))
      EndIf
      ConsoleWrite(StringFormat("%4s",DllStructGetData($tInstanced,$ElementNumber,$i)))
      If MOD($i,16) = 0 then
         ConsoleWrite(@CRLF)
      EndIf
   Next
   ConsoleWrite(@CRLF)
endfunc

Beide liefern mir 0en und 1en und einmal 128.

Herzlich Willkommen im Forum.

Zitat von ArminLinder

Wer kann mir einen Tipp geben wod er Wurm steckt?

Wenn du uns ein lauffähiges Skript bereitstellst können wir uns das gerne mal näher anschauen, du hast nur einen kleinen Abschnitt gepostet der so nicht läuft.

Ein paar Kommentare dran was wo rauskommen sollte bzw. was nicht klappt wäre auch sehr hilfreich (neben der textuellen Beschreibung). Ansonsten können wir auch nur spekulieren.

Update 06.05.2019:

Ups, eine Clear-Funktion kann ja nicht schaden

• UDF um _RingBuffer_Clear erweitert
• Beispiel um _RingBuffer_Clear erweitert
• au3.user.calltips um _RingBuffer_Clear erweitert

Servus,

da ich in meinem aktuellen Projekt einen RingBuffer gebraucht habe, habe ich fix diese UDF geschrieben. Ob es bereits sowas gibt weiß ich ehrlich gesagt nicht, ich habs einfach selber gemacht.

Damit kann man einen FIFO RingBuffer erzeugen welche den ältesten Wert überschreibt wenn man die Kapazität überschritten hat.

Vielleicht kann das ja auch jemand von euch gebrauchen. Ein Beispiel inklusive au3-Calltips für SciTE ist angehangen.

Funktionsliste RingBuffer.au3:

• _RingBuffer_Create($iCapacity)
• _RingBuffer_Destroy(ByRef $aRingBuffer)
  
• _RingBuffer_GetCapacity(ByRef $aRingBuffer)
  
• _RingBuffer_GetCount(ByRef $aRingBuffer)
  
• _RingBuffer_Add(ByRef $aRingBuffer, $vItem)
  
• _RingBuffer_Clear(ByRef $aRingBuffer)
  
• _RingBuffer_Remove(ByRef $aRingBuffer)
  
• _RingBuffer_GetOldest(ByRef $aRingBuffer)
  
• _RingBuffer_GetNewest(ByRef $aRingBuffer)
  
• _RingBuffer_GetAll(ByRef $aRingBuffer, $bNewestFirst = False)

Update 06.05.2019: _RingBuffer_Clear-Funktion hinzugefügt.

Bisherige Downloads (alte Versionen): 2

Deine Daten sehen aus als kämen sie von einem JSON-String, dafür gibt es UDFs die du direkt nutzen kannst um diese zu parsen.

Sollte das nicht so sein kannst du RegEx nehmen, ist wesentlich angenehmer.

#include <Array.au3>

$sSuche = "Himmel"
$sTest = '"Auto1":"20000km","Auto2":"30000km","Haus1":"5Jahre", "Haus2":"100Jahre", "Himmel":"Blau", "Gras:Grün"'

Local $aRegEx = StringRegExp($sTest, """" & $sSuche & """:""(.+?)""", 3)
_ArrayDisplay($aRegEx)

Inline war das Stichwort. Die Zeichenfolge hinter data:image/png;base64,  ist das Base64 encodete Bild.

<img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
    9TXL0Y4OHwAAAABJRU5ErkJggg==" />

So einfach ist das vermutlich nicht, da du ja keine feste HTML hast und die Datei praktisch im RAM erzeugt wird, zumindest wenn du about:blank nutzt.

Wenn du eine leere HTML-Datei erzeugst und dessen Verzeichnis übernommen wird, kannst du Pfade zu Bildern übergeben, du brauchst also praktisch nur eine Dummy-HTML.

Spontan fällt mir nur ein (ohne Dummy-HTML):

• Absolute Pfade nutzen, was kein Problem ist da du ja die Datei generierst.
• Die Bilder base64 encoden und einfach inline mitgeben, dann funktioniert das alles ohne irgendeine Datei.

Du kannst mit _IEDocWriteHTML direkt in das IE-Control schreiben. Mit _IEDocInsertHTML kannst du zwischendrin Sachen schreiben.

Also kannst du entweder die gesamte HTML erzeugen und dann anzeigen oder erst die Tabelle und sie nachträglich mit Daten füttern.

Zitat von Code4Fun

Habe das ganze jetzt völlig anders angegangen und bin damit sehr zufrieden.

Du bist herzlichst eingeladen uns an deinem Code teilhaben zu lassen oder wenigstens kurz zu beschreiben wie du es nun gelöst hast.

Threads, welche mit den Worten "nvm, habs selber rausgefunden" vom TE enden, kann wirklich keiner leiden.

Zitat von AK-IT

So sieht es aus. Ich denke für den Einsteig ist AutoIT das richtige für mich.

Ich hau dir jetzt schon mal auf die Finger damit sich das nicht wiederholt, es heißt AutoIt, nicht "AutoIT"

Zitat von AK-IT

Mit Sicherheit nicht.

Wer keine Fragen stellt lernt nicht dazu, trau dich einfach, es gibt keine dummen Fragen.

Zitat von Bitnugger

Hier mal ein "auf die Schnelle geschriebenes" Beispiel, das zeigt, warum ich dazu rate, Laufvariablen nicht im globalen Kontext zu benutzen.

Dazu schrieb ich bereits:

Zitat von alpines

Den Fehler den Bitnugger anspricht ist einfach selbst geschuldet, da man nicht Variablen referenzieren darf die vorher nicht explizit auf dem aktuellen Pfad deklariert wurden.

Ich schreibe bei jeder Deklaration immer das Scope davor um ganz sicher zu gehen, dass ich auch die Variable anspreche die ich möchte.

Zitat von alpines

Des Weiteren sollten UDF-interne Variablen immer mit einem Präfix versehen sein wenn sie global verwendet werden.

Dein Beispiel ist auch nicht ganz sauber, du implizierst, ohne es zu sagen, dass $iCount > 0 sein muss.

Zitat von Bitnugger

If UBound($aFiles) Then $iCount = $aFiles[0]

Das ist aber Quatsch. Wenn ich in einen Codepfad laufe indem UBound($aFiles) > 0 ist, so ist $iCount von mir gesetzt worden - alles ok.

Laufe ich allerdings in einen Codepfad in wo UBound($aFiles) = 0 ist, so stehen mir nur zwei Optionen zur Verfügung:

1. Ich verzichte komplett auf $iCount und füge überall manuell 0 ein, bzw. spucke eine Fehlermeldung aus, dass es nicht geklappt hat weil keine Daten selektiert worden sind.
2. Ich nutze $iCount so ähnlich wie im Pfad als ob Daten da wären. Allerdings würde ich hier nicht wie du $iCount nur setzen wenn UBound($aFiles) > 0 ist, sondern würde lieber das ganze mit dem ternären Operatoren vorher lösen, sprich $iCount = UBound($aFiles) ? $aFiles[0] : 0.

Deine Prämisse $iCount nur zu setzen wenn UBound($aFiles) > 0 ist, ist schlecht, da du den anderen Codezweig nicht abdeckst.

Außerdem kann man bei dem Beispiel direkt anders argumentieren:

Ich bin mir bewusst, dass du hier nur einen Punkt illustrieren möchtest und auf die schnelle ein Beispiel gesucht hast, jedoch ist der Zugriff auf den 0-Index nicht von Nöten (das Thema hatten wir ja schon oft genug hier) wenn man direkt mit UBound arbeitet. Dann kann dieser Fehler überhaupt nicht auftreten.

Zitat von Code4Fun

Laut Hilfe ist aber 0 = Fehler.

Und in welcher Hilfe hast du nachgesehen? @error wird in GUISetState nicht mal erwähnt.

Zitat von Code4Fun

Ich dachte mit GUISetState(@SW_SHOW, $hGUI) erzeugt man einen Refresh der GUI?

Was ist denn ein "Refresh" von einer GUI?

GUISetState setzt nur den State einer GUI, diese kann unter anderem Versteckt, Angezeigt und Gesperrt sein.

Mit GUICtrlSetData kannst du neue Werte der Controls auf der GUI setzen welche dann direkt übernommen werden.

Zitat von Code4Fun

Ich habe ursprünglich mal den Wert 0xFAA731 eingegeben. Jetzt bin ich in einer anderen Lokation, wo der LCD Monitor hier den Wert 0xFAA732 erkennt. Kann man das irgendwie einstellen, das ein paar Farbnuancen noch oben und unten als Toleranz gewertet werden?

Schau dir mal den Parameter der PixelSearch-Funktion an der nach "color" kommt.

Zitat von Code4Fun

Ich prüfe ja mit $aCoord = PixelSearch(-2833, 835, -2771, 872, 0xXXXXXX) auf die Existenz eines Farbcodes 0xXXXXXX (wobei hier 0xXXXXXX als Variable für meine anderen Farben zu sehen ist). Im konkreten Fall prüfe ich auf die Farben grün, orange und rot. Wie muss ich denn eine 4. Prüfung schreiben, die mir z.B. eine MsgBox hochpoppt, wenn an diesen Koordinaten eine andere Farbe als diese 3 zu sehen ist. Ich will damit sicherstellen, das ich mein Monitorfenster wieder nach vorne hole, falls ich es mal temporär mit einem anderen Fenster überdeckt habe.

Schlagen die PixelSearches, für die Farben die dort sein sollten, alle fehl, dann hast du doch eine andere Farbe dort. Das kriegst du mittels einer If-Abfrage hin.

Zitat von Musashi

Die Aussage bezog sich auf den o.a. Link und wurde von mir wohl etwas stark verkürzt .

Zitat von alpines

Den Fehler den Bitnugger anspricht ist einfach selbst geschuldet, da man nicht Variablen referenzieren darf die vorher nicht explizit auf dem aktuellen Pfad deklariert wurden.

Ich schreibe bei jeder Deklaration immer das Scope davor um ganz sicher zu gehen, dass ich auch die Variable anspreche die ich möchte.

Setze ich im If- und Else-Zweig eine Variable, so definiere ich sie vorher mit Local $vVar und setze sie nachträglich mit $vVar = 1337.42.

Niemals definiere ich sie im If-Zweig und verwende sie im Scope darüber (was bei Ifs in AutoIt ambivalent wäre, "Level" trifft es eher).

Das ist mir schon klar, allerdings ist sowas sehr leicht umgehbar wenn man nicht mit inkonsistenten Deklarationen um sich wirft.

Antrainierbar ist das ganze, verzichtet man gänzlich darauf Variablen ohne explizite Deklaration zu nutzen tritt das Problem überhaupt nicht auf.

Wenn ich auf eine Variable zugreife schaue ich erstmal nach ob sie existiert (global/lokal) und deklariere sie wenn nötig vorher.

Zitat von Musashi

Eine Sache sollte man sich unbedingt abgewöhnen... For...Next-Schleifen im globalen Kontext!

Das kann ich so nicht stehen lassen.

Ich verwende die sehr häufig wenn es bspw. darum geht Events zu setzen.

Global $aSettingsGUI_Settings[11]
Global $hSettingsGUI_SettingsTV = GUICtrlCreateTreeView(8, 8, 137, 369, -1, $WS_EX_CLIENTEDGE)
$aSettingsGUI_Settings[0] = GUICtrlCreateTreeViewItem("Users", $hSettingsGUI_SettingsTV)
$aSettingsGUI_Settings[1] = GUICtrlCreateTreeViewItem("General", $hSettingsGUI_SettingsTV)
;...

For $i = 0 To UBound($aSettingsGUI_Settings) - 1
    GUICtrlSetOnEvent($aSettingsGUI_Settings[$i], _SettingsGUI_LoadPage)
Next

Schreibt man kleinere Skripte die keine wirklichen Programme sind (Makros oder dergleichen) ist das ebenfalls gut nutzbar.

Den Fehler den Bitnugger anspricht ist einfach selbst geschuldet, da man nicht Variablen referenzieren darf die vorher nicht explizit auf dem aktuellen Pfad deklariert wurden.

Ich schreibe bei jeder Deklaration immer das Scope davor um ganz sicher zu gehen, dass ich auch die Variable anspreche die ich möchte.

Setze ich im If- und Else-Zweig eine Variable, so definiere ich sie vorher mit Local $vVar und setze sie nachträglich mit $vVar = 1337.42.

Niemals definiere ich sie im If-Zweig und verwende sie im Scope darüber (was bei Ifs in AutoIt ambivalent wäre, "Level" trifft es eher).

Des Weiteren sollten UDF-interne Variablen immer mit einem Präfix versehen sein wenn sie global verwendet werden.

Zitat von AK-IT

Und welchen Hintergrund hat es eigentlich, auf die Laufvariable $i zu verzichten?

Du zählst bereits in der Schleife von $i = 1 bis $iAnzahlSeiten, wozu dann noch eine zweite Variable einführen die genau dasselbe zählt? Verwende doch lieber die die schon existiert.

Deine Funktion würde in ZaehlerDateien $i von 1 bis $iAnzahlSeiten hochzählen und 0 zurückgeben (weil du nichts returnst).

Du rufst also eine Funktion aus die 10x eine Schleife hochzählt und 0 zurückgibt, mehr nicht. Außerdem ist $i in deiner Funktion in einem lokalen Scope, d.h. wenn du dort $i beschreibst, hat das keine Auswirkungen auf das $i das außerhalb der Funktion existiert.

Wenn du innerhalb einer Funktion den Zähler haben möchtest muss deine Funktion den Zähler zurückgeben und bei jedem Aufruf um eins erhöhen.

So etwa:

ConsoleWrite(ZaehlerDateien() & @CRLF)
ConsoleWrite(ZaehlerDateien() & @CRLF)

Func ZaehlerDateien()
    Local Static $iCounter = 0 ;Static bedeutet, initialisiere $iCounter innerhalb der Funktion einmal und behalte den Wert für den nächsten Aufruf der Funktion bei.

    $iCounter += 1
    Return $iCounter
EndFunc