Beiträge von BiNu

Zitat von i2c

Erklär mir bitte kurz und schlüssig, warum eine au3 Datei für den von dir so herlich oft herangezogenen DAU keine Gefahr darstellt, wenn er sie selbst über den Editor startet statt als kompilierte exe?

Kann der DAU aus deiner Welt, der scheinbar zu dumm ist um falsche Virenwarnungen zu erkennen etwa AutoIt Quellcode lesen und verstehen?

Ich glaube du hast mich falsch verstanden entweder es besteht ein Risiko wenn eine "böse" au3-Datei geöffnet wird oder aber durch den Trick mit dem modifizierten Link besteht kein Risiko mehr weil eine "böse" au3-Datei standardmässig mit dem Windows Editor verlinkt werden kann. Ob der User den Code versteht ist total irrelevant er wird in nicht ausführen können in Windows Editor.

Das verlinkte Script hingegen sollte natürlich kein bösen Code enthalten. Es geht ja darum ein Script einem unerfahrenen User zur Verfügung zu stellen ohne dass er Virenmeldungen bekommt. Wenn man hingegen ein AutoIt "Virus" einem unerfahrenen User geben will und dass ohne Virenmeldung. Dann funktioniert es natürlich auf die selbe weise auch dass ist mir schon klar.

Ein DAU ist übrigens eine fiktive Person in meine Welt existiert keiner .

Läuft hier (die UDF) allerdings gibt es die Funktion _GDIPlus_PathDispose zwei mal was zu einem Error führt. _GDIPlus_PathDispose ist in der GDIPlus.au3 schon vorhanden. Allerdings nicht genau die selbe.

aus der GDIPlus.au3

[autoit]

; #FUNCTION# ====================================================================================================================
; Author ........: Authenticity
; Modified.......: Eukalyptus
; ===============================================================================================================================
Func _GDIPlus_PathDispose($hPath)
Local $aResult = DllCall($ghGDIPDll, "int", "GdipDeletePath", "handle", $hPath)
If @error Then Return SetError(@error, @extended, False)
If $aResult[0] Then Return SetError(10, $aResult[0], False)

[/autoit][autoit][/autoit][autoit]

Return True
EndFunc ;==>_GDIPlus_PathDispose

[/autoit]

aus der LEDTXT.au3

[autoit]

Func _GDIPlus_PathDispose($hPath)
Local $aResult = DllCall($ghGDIPDll, "uint", "GdipDeletePath", "handle", $hPath)
If @error Then Return SetError(1, @error, 0)
Return SetError($aResult[0], 0, $aResult[0] = 0)
EndFunc ;==>_GDIPlus_PathDispose

[/autoit]

Was der unterschied ist kann ich nicht sagen bei mir tut es mit beiden nur natürlich nicht mit beiden gleichzeitig .

Mit UPX hat das nix zu tun das Problem hiesst Faulheit bei den AV Programmieren.
Und die Testsieger werden z.t. auch fragwürdig ermittelt. In welchem Verhältnis steht "False Positiv" zu "False Negativ" für einen erfahrenen User mit upgedateter Brain.exe machen sich AV Software nur bemerkbar durch "False Positiv" Meldungen und andere Probleme die AV so verursachen. Für den klassischen DAU hingegen sollte jede ausführbare Datei gar nicht erst abspeicherbar sein^^.

Eine Lösung für DAUs ist das Script auf dem PC des DAUs abspeichern eventuell obfuscated obwohl eher unnütz wenn's ja ein DAU ist. Dann Autoit installieren und Scripte beim öffnen ausführen nicht bearbeiten wählen. Verknüpfung zum Script erstellen und nettes Icon rein machen.
Hoffen das der DAU nie eine "böse" au3-Datei vor die Maus bekommt .

Im Prinzip reicht auch AutIt als Zip zu laden und irgend wo zu entpacken dann die Verknüpfung für das Script wie folgt zu verlinken.
"C:\Whatever\AutoIt3\AutoIt3.exe" script.au3
Die au3-Datei kann dann standardmässig mit Scite oder Editor geöffnet werden und heruntergeladene au3-Datein stellen kein Risiko mehr dar.

Natürlich nur praktikabel wenn man dass vor Ort einrichten kann oder via Interviewer o.ä.

Der Bug wo GAME OVER über dem Feld bleibt kann reproduziert werden wenn man einfach Pfeil nach unter drück und hält.
Game Over wird dann scheinbar mehrmals übereinander gelegt und bei Neustart nur einmal entfernt. (Nur ne Theorie basierend auf der Beobachtung nicht dem Code )

SCORE 490 xD

Also hab das jetzt nur 3 mal gespielt und hat mit deinem Problem nix zu tun aber da sind zum teil schwebende imaginäre Blöcke. Die haben keine Wirkung die andern fallen einfach durch die hindurch und z.t. "putzen" die sie weg.

Nach Game Over > Neustart bleibt manchmal der Game Over Balken/Schrift vor dem Spielfeld.

und manchmal crasht es einfach spontan mit

==> Array variable has incorrect number of subscripts or subscript dimension range exceeded.:
GUICtrlSetBkColor($g_lblGameBoard[$g_nShapeX+$i][$g_nShapeY+$j], $g_aGameShape[$i][$j])
GUICtrlSetBkColor(^ ERROR

Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist. Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist. Der Inhalt kann nicht angezeigt werden, da er nicht mehr verfügbar ist.

Weiss zwar nicht ob man hier auch Fehler in der Hilfe melden sollte aber ich machs einfach mal .

Die ganzen TCP Funktionen bei denen Erfolg: 1 und Fehler: 0 steht geben in Wirklichkeit True und False zurück kein Plan wieso. Im englischen auch falsch.

Bei TCPListen sollte noch ein Hinweis hin für TCPCloseSocket. TCPShutdown macht dass nämlich nicht und eine erneutes TCPListen für dann zu nem Error.

Zitat von chesstiger

Mein 3.3.10.2 verhält sich genau so. Auch das hier geht nicht:

Spoiler anzeigen

[autoit]

AdlibRegister("IntervalFunc", 1000)

[/autoit] [autoit][/autoit] [autoit]

$i = 0

[/autoit] [autoit][/autoit] [autoit]

While True
ConsoleWrite("MainLoop[" & $i & "]" & @LF)
$i += 1
Sleep(500)
WEnd

[/autoit] [autoit][/autoit] [autoit]

Func IntervalFunc()
AdlibUnRegister("IntervalFunc")

[/autoit] [autoit][/autoit] [autoit]

ConsoleWrite("Interval" & @LF)
Sleep(1000) ; 1000 ms + call zu consolewrite und sleep => die ausführungszeit von IntervalFunc() ist > 1000 ms

[/autoit] [autoit][/autoit] [autoit]

AdlibRegister("IntervalFunc", 1000)
EndFunc

[/autoit]

Alles anzeigen

Genau das war auch mein Gedanke und weil dass nicht klappte hab ich den Code Joke noch weiter gezogen. Und siehe da es funktioniert sogar.
Gut hat der Interpreter keine Gefühle :D.

[autoit]

Global $hTimerInit = TimerInit()
Global $time = 1000
AdlibRegister("IntervalFunc", $time)

[/autoit][autoit][/autoit][autoit]

$i = 0

[/autoit][autoit][/autoit][autoit]

While True
ConsoleWrite("MainLoop[" & $i & "]" & @LF)
$i += 1
Sleep(500)
If $i = 5 Then
AdlibUnRegister("IntervalFunc")
AdlibUnRegister("AdlibDummyFunc")
EndIf
WEnd

[/autoit][autoit][/autoit][autoit]

Func IntervalFunc()
AdlibRegister("AdlibDummyFunc", $time)
ConsoleWrite("Interval " & Round(TimerDiff($hTimerInit), 0) & "ms" & @LF)
;Sleep($time) ; 1000 ms + call zu consolewrite und sleep => die ausführungszeit von IntervalFunc() ist > 1000 ms
EndFunc ;==>IntervalFunc

[/autoit][autoit][/autoit][autoit]

Func AdlibDummyFunc()
AdlibUnRegister("IntervalFunc")
ConsoleWrite("AdlibDummyFunc" & @LF)
AdlibRegister("IntervalFunc", $time)
EndFunc ;==>AdlibDummyFunc

[/autoit]

Auf diese weise entspricht $time ca. der Zeit zwischen den Funktionsaufrufen also die Zeit in der die Main Schleife abgearbeitet wird.
Interessanterweise wird die DummyFunc nur ausgeführt wenn die IntervalFunc länger dauert als $time. Man kann also $time ein bisschen grösser wählen als die erwartete Lehrlauf Zeit der IntervalFunc. Und dass ohne zu riskieren dass auf langsamerer Hardware die Main Schlaufe nicht mehr ausgeführt wird.

Zitat von Make-Grafik

Prinzipiell würde ich sowieso von AdlibRegister abraten und die Timer Funktionen empfehlen.
Da das Skript sowieso während der Ausführung der registrierten Funktion gestoppt wird macht das kein Unterschied.
Nur der Bug von AdlibRegister wird eben so umgangen.

Dauernd wird vom Gebrauch von AdlibRegister abgeraten wieso nur? Das ist als ob man von MsgBox abraten würde, die pausiert nämlich alles und ist deshalb böse . Eigentlich sollte man es nur mit bedacht einsetzten genau wie die MsgBox. Manchmal ist Pausieren ja genau dass was man will.
Mit Timer Funktionen meinst du TimerInit/Diff? Damit lässt sich wohl gut Zeit messen aber beim Einsatz von AdlibRegister spielen die Millisekunden meist eher keine Rolle. Ziel ist etwas abzufangen. Ein Fehler eine User Aktion oder Rückmelden von anderen Programmen etc. Die Abfangfunktion einfach in die Main Schleife zu packen ist wohl kaum zu empfehlen. Die kann ja z.b. so ausehen.

[autoit]

While 1
For
Next

[/autoit][autoit][/autoit][autoit]

Select
Case
Case
Case
EndSelect

[/autoit][autoit][/autoit][autoit]

Do
Until

[/autoit][autoit][/autoit][autoit]

For
For
Next

For
Next

Do
Until

[/autoit][autoit][/autoit][autoit]

For
Next
Next
WEnd

[/autoit]

Wo hin jetzt mit der Funktion? Nach jedem While/For/Do/Case einmal aufrufen :wacko:. Was wenn eine andere Funktion Aufgerufen wird die Zeit benötigt und die Main Schlaufe somit pausiert? AdlibRegister .
Laut der englischen Hilfe mach AdlibRegister übrigens genau dass was da steht d.h. die alte Version hat sich nicht so verhalten wie beschrieben. Die neue schon nur die alte kaputte Funktion war wohl einiges Sinnvoller.
Hab das selbe alte Script, auf alter AutoIt Version, auf einem viel langsameren Laptop, ausprobiert und da wird die Main Schlaufe nie ganz abgewürgt. Wenn die IntervalFunc länger dauert als der AdlibRegister Zeit Parameter dann wird zwischen den Aufrufen immer mindestens eine Zeile Code aus der Main Schleife ausgeführt. Es kann also nur sehr sehr langsam werden.

BTW der Workaround wurde heute Nacht um 4 Uhr geschrieben und ist nicht getestet . WIe sich das ganez verhaltet wenn man mehrere Funktionene registriert hab ich auch nicht zuendegedacht. Weitere Vorschläge/Workarounds immer her damit .

Hab mal eben ein älteres Script benutzen wollen welches mit AdlibRegister parallel zum eigentlichen Script Daten aus einer Datei ausliest.
Leider musste ich feststellen das dies nicht mehr funktioniert.

Das Problem scheint die Zeit zu sein welche die registrierte Funktion benötigt. Ist diese >= der Zeit die bei AdlibRegister als Parameter angegeben ist, dann wird nur noch die registrierte Funktion ausgeführt für immer.

Hier das Beispiel ist aus der Hilfe. Default ist 250ms also hab ich ein Sleep(250) in die Funktion gesetzt um das Verhalten zu simulieren.
Konnte im Changelog nichts dazu finden wurde anscheinend nur ein Bug behoben der mehrere gleichzeitig registrierte Funktionen betrifft.
Trotzdem bin ich mir sehr sicher, dass dies in früheren Versionen nicht so war. Ist ja auch irgendwie Sinnlos anzugeben nach wie viel ms die Funktion aufgerufen wird. Stattdessen sollte man doch angeben wie viel Zeit zwischen den Aufrufen vergehen sollte. Man kann ja nicht wissen wie lange die Funktion braucht und je nach dem brauch die ja auch unterschiedlich lange. Normal sehr kurz und bei Reaktion auf ne Veränderung dann eventuell einiges länger. Zudem ist das ja auch Hardware abhängig.

Kann jemand bestätigen dass die Funktion geändert wurde? Gibt es ein Workaround?

[autoit]

#include <MsgBoxConstants.au3>

[/autoit][autoit][/autoit][autoit]

If ProcessExists("SciTE.exe") = 0 Then
MsgBox($MB_SYSTEMMODAL, "", "You will need SciTE.exe to be running for ConsoleWrite to display.")
EndIf

[/autoit][autoit][/autoit][autoit]

Example()

[/autoit][autoit][/autoit][autoit]

Func Example()
; Register the function MyAdLibFunc() to be called every 250ms (default).
AdlibRegister("MyAdLibFunc")

[/autoit][autoit][/autoit][autoit]

; Sleep does not stop AdLib functions from running.
Sleep(1000)

[/autoit][autoit][/autoit][autoit]

; AdLib functions don't run while a blocking function is shown e.g. MsgBox, InputBox, WinWait, WinWaitClose etc.
MsgBox($MB_SYSTEMMODAL, "", "No console message(s) will be shown whilst the messagebox is displayed.")

[/autoit][autoit][/autoit][autoit]

; The AdLib function MyAdLibFunc() will start again.
Sleep(2000)

[/autoit][autoit][/autoit][autoit]

; Unregister the function MyAdLibFunc() from being called every 250ms.
AdlibUnRegister("MyAdLibFunc")
EndFunc ;==>Example

[/autoit][autoit][/autoit][autoit]

Func MyAdLibFunc()
Sleep(250)
; Assign a static variable to hold the number of times the function is called.
Local Static $iCount = 0
$iCount += 1

[/autoit][autoit][/autoit][autoit]

ConsoleWrite("MyAdLibFunc called " & $iCount & " time(s)" & @CRLF)
EndFunc ;==>MyAdLibFunc

[/autoit][autoit][/autoit][autoit][/autoit]

Hab auf verschiedenen Geräten verschiedene Versionen im Einsatz aber bin dabei überall auf die neuste Stable (v3.3.10.2) umzusteigen.
Die v3.3.10.2 hat ein paar nette neue Features und es wird wohl bald nur noch neue Scripte und UDFs dafür geben.
Der Umstieg ist zugegebene etwas mühsamer als frühere Versionswechsel. Hatte doch schon diverse Scripte relativ zeitaufwendig anpassen müssen. Und gewisse Sachen kommen einem schon ein bisschen BETA like vor.
Z.B. verhindert #AutoIt3Wrapper_Res_Language=**** das korrekte compilieren obwohl Autoit3Wrapper die Zeile weiterhin so einfügt wenn man die Sprache der exe ändert.
Oder die Zeilen

#AutoIt3Wrapper_Run_Obfuscator=y
#Obfuscator_Parameters=/striponly

werden In Scite nicht mehr eingefärbt etc.
Alles kleine Bugs aber irgendwie sollte so was doch bis einem Stabelrelease gefixt sein. Gibt halt ein unschönes Gefühl könnten ja genau so gut kleine Bugs sein mit erheblicher Auswirkung sein.

Das Ding ist echt spitze :D. Persönlich lade ich mir fast nur Alben oder ganze Diskografien und dafür gibt's andere Möglichkeiten. Aber für einzelne Tracks ist dass einiges bequemer als Youtube. Und versteht auch jeder DAU. Was mit ein Grund ist dass ich das Tool schon 5 Personen weiterempfohlen habe .
Sind alle begeistert aber wird sich wohl keiner hier anmelden und sich bedanken also Zähle mein Danke glich 6 Mal .

Zitat von Cheater Dieter

Kann ich leider (oder zum Glück?) nicht reproduzieren, wie/wo genau kam der Absturz?

Meinte:
Doppelklick in leere Listview lässt das Tool crashen.
Frag mich nicht wieso ich dass gemacht hab vielleicht hab ich nach Easter Eggs gesucht.
Wenn etwas in der Liste ist dann passiert es nur wenn nichts zuvor angewählt wurde. Andernfalls fügt es das zuvor angewählte zur Downloadliste obwohl man ins leere Doppelklickt. :pinch:

Eben die neue Version getestet der andere Bug scheint behoben in der exe. Das Script crasht unter AutoIt v3.3.8.1
Nehme an dass wurde mit neuerer Version geschrieben. Konnte ich also nicht testen.

*nörgelnörgel*

Bei Tab "Suche" der Button "Doppelte Titel entfernen" entfernt manchmal alle doppelten Titel. Was wohl eher nicht Sinn der Sache ist.

Konnte nicht herausfinden wo genau der Bug hockt aber versuch's mal mit Suche nach "The Best Thing (That Never Happened)" da krieg' ich 3 Treffer und nach "Doppelte Titel entfernen" ist gar nix mehr da. An den Sonderzeichen scheint es nicht zu liegen. passiert auch ohne ()

Edit:
Noch was kleines. Klick in leere Listview lässt das Tool crashen.

Subscript used with non-Array variable.:
$SongInfosFuerDLListe[$a][0]=$SongInfo[$i][0]
$SongInfosFuerDLListe[$a][0]=$SongInfo^ ERROR

Ja ich wieder will Dinge tun die AutoIt nicht kann

Titel sagt alles

[autoit]

Opt("WinTitleMatchMode", 2)
Opt("WinTextMatchMode", 2)

[/autoit][autoit][/autoit][autoit]

ConsoleWrite(WinMove("Task-Manager", "", 0, 0, 1000, 700, 7) & " Task-Manager" & @CRLF)
;oder
ConsoleWrite(WinMove("[CLASS:TaskManagerWindow]", "", 0, 0, 1000, 700, 7) & "[CLASS:TaskManagerWindow]" & @CRLF)

[/autoit][autoit][/autoit][autoit][/autoit][autoit][/autoit]

Gibt brav Handle zurück aber tut sich rein gar nix.

Output:
0x00080596 Task-Manager
0x00080596 CLASS:TaskManagerWindow

AU3Info sagt mir aber das Handle sei 0x0000000000080596 keine Ahnung was die zusätzlichen Nullen zu bedeuten haben.

AU3Info Output

>>>> Window <<<<
Title: Task-Manager
Class: TaskManagerWindow
Position: 279, 1553
Size: 660, 600
Style: 0x14CF0000
ExStyle: 0x00000100
Handle: 0x0000000000080596

>>>> Control <<<<
Class:
Instance:
ClassnameNN:
Name:
Advanced (Class):
ID:
Text:
Position:
Size:
ControlClick Coords:
Style:
ExStyle:
Handle:

>>>> Mouse <<<<
Position: 386, 1572
Cursor ID: 0
Color: 0xEBEBEB

>>>> StatusBar <<<<

>>>> ToolsBar <<<<

>>>> Visible Text <<<<
TaskManagerMain

>>>> Hidden Text <<<<

Tipp?

Vielen Dank für beiden Lösungsvorschläge. Werde mir die mal anschauen und austesten =).

Setze den Thread mal auf [gelöst]

Wo ist der Code?

Zitat

Warnung: Einen höheren Core-Count als den physikalischen zu wählen verfälscht die Ergebnisse und führt zu Instabilität.

Was für ein Ergebnis?

Hab ein i7 mit 4 Cores (Hardware) aber 8 Core virtualisiert was ist den jetzt von Bedeutung?

Eine verschlüsselte Zahl hat keinerlei Ähnlichkeit mit der Zahl selbst. Damit zu rechnen kann eigentlich zu nix führen.
Dass ist wie wenn du Text verschlüsselst und danach Kommas setzten willst.

Ich kann dir nur den Opt("GUIOnEventMode", 1) empfehlen damit lässt sich in den meisten fällen besser arbeiten als mit den Endlosschleifen. Der Einstieg mag ein bisschen Zeitaufwendiger sein aber hat man das Prinzip mal kapiert ist es um einiges übersichtlicher.
Spätestens wenn du innerhalb der Endlosschleife Funktionen aufrufst ist Spaghetticode vorprogrammiert. Also besser gleich mit Funktionen arbeiten.

Wird auch in der Hilfe empfohlen für GUIs welche nicht die ganze Zeit auf eine User Aktion warten müssen. Sondern z.b. Berechnetes ausgeben, darstellen etc.

Zitat von OnEvent Mode

This mode is best for GUIs where the GUI is of secondary importance and your script has other tasks to perform in addition to looking after the GUI.

Die MsgBox darf nicht in der Schleife sein.

Die Daten die du anzeigen willst in der MsgBox schriebst du stattdessen in eine Variable.

mit $var &= $neuedaten kannst du eine Variable bei jedem Durchgang der Schleife mit neuen Daten füllen

mit $var &= @crlf & $neuedaten wird dir dabei helfen das es auf mehreren Zeilen ausgegeben wird

Hab mich noch nie mit Lua befasst. Ob ich dass in meinem Script verwenden könnte kann ich also nicht sagen.
Wenn du trotzdem ausprobieren willst interessant wäre es jedenfalls =).

Echte Daten hab ich hier keine und wäre auch nicht wirklich geeignet zum Posten. Aber der Inhalt Ist Text also deutsche Zeichen wie in der Zeitung.

Getestet hab ich damit. dass erzeugt ein vergleichbaren String.
ca. 830'000 Zeichen lang. Also nur ~800 KB. Sind für heutige Verhältnis gar keine gossen Datenmengen die 65'000 Limit ist einfach mager.
Dauert auf meinem i7 ca. 30 Sekunden und 60 MB RAM zu generieren.

[autoit]

#include <Crypt.au3>

[/autoit][autoit][/autoit][autoit]

$String = ""
For $i = 0 To 10000
$Random = Hex(_Crypt_HashData(Random(0, 999999999999), $CALG_MD5))
$Random = StringTrimLeft($Random, Random(0, 32, 1)) & StringTrimLeft($Random, Random(0, 32, 1)) & StringTrimLeft($Random, Random(0, 32, 1)) & StringTrimLeft($Random, Random(0, 32, 1)) & StringTrimLeft($Random, Random(0, 31, 1))
$String &= "[" & $Random & "],"
Next
ConsoleWrite($String & @CRLF)
ConsoleWrite(StringLen($String) & @CRLF)

[/autoit][autoit][/autoit][autoit]

Exit

[/autoit]

Zitat von BugFix

Alternativvariante:
- Lösche alle "[" "]" und ","
- übrig bleibt der gewünschte Inhalt
- jetzt häckseln in Teile fester Länge

[autoit]

$s = StringRegExpReplace("DEIN_STRING", "[\[\],]", "")
$aMatch = StringRegExp($s, ".{1, " & $iMaxLen & "}", 3)

[/autoit]

Erstens bleibt hier das Limit genau gleich $iMaxLen kann auch hier nicht grösser als ~65500 sein.
Zweites wird dadurch doch auch innerhalb von [] geteilt bzw. es wird alles aneinander gehängt und eine Trennung nur beim Koma ist nicht mehr möglich.
Das Problem ist dass $iMaxLen nicht grösser sein kann. Der Patter in meinem Beispiel würde sonst genau das machen was er soll.

Nochmals zur Aufgabe.
Der String enthält viele Teilstrings unterschiedlicher Länge welche erhalten bleiben müssen.
Es darf also nur beim Komma getrennt werden.
Es soll nach so vielen Teilstrings getrennt werden dass der String möglichst genau die Länge $iMaxLen hat.

Bsp.

String: "Teilstring,Nocheiner,Ich-bin-ein-Teilstring-und-muss-zusammen-beliben,Ich-bin-das-auch-aber-kürzer,ich-auch-sogar-mit-z4hlen,blablabla,loremipsum,usw und so fort"

Maxlen = 25
Also trennen nach 25 zeichen
"Teilstring,Nocheiner,Ich-bin-ein-Teilstring-und-muss-zusammen-beliben,.....

Aber halt da darf nicht getrennt werden also trenne beim vorherigen Komma.

"Teilstring,Nocheiner,Ich-bin-ein-Teilstring-und-muss-zusammen-beliben,....

Also das Grüne im Array speichern und mit dem übrigen String das Gleiche mach so lange bis nichts mehr übrig ist.
MaxLen ist dabei immer länger als der längste Teilstring so das sicher jeder Teilsting verarbeitet wird.

Zitat von bollen

in der vollständigen beschreibung der PCRE Pattern steht was den fehlschlag erklärt wen die 2 zahl größer ist.

ich würde die Maximalanzahl der Zeichen so umgehen das ich einfach 2x den Ausdruck hintereinander verwende. Ceiling und Floor müssten die .5 bei ungeraden Zahlen beheben. (ungetestet)

[autoit]

StringRegExp($string ,"\[.{1,"&Ceiling($MaxLen/2)&"}.{1,"&Floor($MaxLen/2)&"}\],??",3)

[/autoit]

natürlich

Genau das Limit ist das Problem dass steht da schon im ersten Post seit immer^^.
Der Pattern einfach zu wiederholen macht leider nicht das selbe.
Zwischen MaxLen und der tatsächlichen Länge gibt ja mit sehr grosser Wahrscheinlichkeit einen Unterschied. Der String ist zu 99% ein bisschen kürzer. Diese Differenz summiert sich bei verdoppeln des Patterns logischerweise. Die Differenz kann also zusammen länger sein als der nächste Teilstring.
Zudem müsste ich den Pattern nicht doppelt haben sonder eher 10-30 mal damit ich zuverlässig die 65000 Limit nicht überschreite.
Auch müsste man die wiederholten Pattern noch optional machen denn der letzte String kann ja aus nur einem Teilstring bestehen und würde bei doppeltem oder gar 10 fachem Pattern dann kein Mach mehr geben.

Das genau gleiche würde ich erreichen indem ich MaxLen halbieren und jeweils 2 Stringes wieder zusammen hänge. Damit gäbe es auch kein Problem wenn am Schluss nur ein Teilstring übrig ist. Die Abweichung summiert sich jedoch auch bei dieser Variante und bei 10-30 mal macht das schon was aus.

Aber es sieht wohl so aus also ob es keine andere Möglichkeit gibt. Jede Programmiersprache hat seine Grenzen. Bei AutoIt sind sie leider manchmal schnell erreicht. Aber gut kann man Arrays mit 64 Dimensionen machen .

Weitere Lösungen oder Tims sind natürlich erwünscht.