Beiträge von AspirinJunkie

    So - mal schnell dahingerotzt:


    Ach bitte, wozu soll das den gut sein? Ist der Sinn nicht klar?

    Weil du Hilfe willst.
    Und ich persönlich habe keinen Bock wenn ich dir schon eine Lösung schreibe noch erst umständlich mir Testeingabedaten und Check-Daten selbst zu basteln.

    Es gilt immer die Grundregel "Warum sollte sich jemand mehr Mühe für die Lösung deiner Frage machen als du selbst in die Fragestellung gesteckt hast?".


    und jetzt gib mir mal nen Moment...

    Ich gehe aber davon aus, dass IniRead und Konsorten für jede Abfrage die Ini öffnen und schließen, oder? Bei über 1.000 Einträgen wäre das suboptimal.

    Jepp - wobei es bisschen darauf ankommt. Wenn du mit IniReadSection arbeitest landet eine ganze Sektion in einem Rutsch in einem Array.
    Allerdings werden von der blödsinnigerweise nur die ersten 32767 Zeichen ausgewertet (Hängt mit der zugrunde liegenden Win-API-Funktion zusammen).
    Wenn die Sektionen in deiner Ini entsprechend klein sind könntest du das also verwenden.


    Meinst du Ini- oder Script-Dateien?

    Ich meine ini - und zwar alle drei: "Ist"-Ini, "Soll"-Ini und "gewünschtes Resultat"-Ini

    Zum einen handelt es sich hierbei aber um eine Ini mit gemischtem Inhalt, nämlich mit Kommentaren, die Infos zu Einstellungen geben. Z.B. zum Schlüssel FarbSchema könnte es einen Kommentar FarbSchema: hell, dunkel, auto geben.

    Mit Kommentaren kommt IniRead und Konsorten doch klar.
    In Ini-Dateien werden Kommentare am Zeilenanfang mit ; eingeleitet.


    Ansonsten tun Beispieldateien gut.

    Definiere mal "auf der Softwareseite stabil".
    Ich kann damit gerade nichts anfangen.

    Meine Kinder nutzen die Amazon Fire HD primär zum Video schauen.
    Für den Preis ist es schwierig vergleichbare Hardware zu finden.
    Wenn man (wie ich) nicht mit der Anpassung von Amazon leben will kann man mit Tools wie Fire Toolbox das Tablet entsprechend anpassen.

    Früher hatte ich auch mal ein Fire HD 7 und konnte dort LineageOS draufhauen - das war dann natürlich ein Traum. Tolle Hardware zum günstigen Preis mit super Software.
    Bei den neuen geht es wohl nicht mehr so einfach aber aktuell haben wir auch keinen wirklichen Leidensdruck um von der jetzigen Konfiguration wegzugehen.
    Es macht was es soll.

    Mal zum Verständnis da zumindest ich das anscheinend erst falsch verstanden habe.
    Du hast nicht einen Wrapper für die DLL erstellt sondern eine eigene AutoIt-UDF auf Basis des Quellcodes von LMMath gebaut?

    Das wäre schon gut das herauszustellen, da eine reine AutoIt-UDF schon attraktiver ist da man keine externen Abhängigkeiten hat.
    Außerdem ist der Aufwand für eine solche UDF ungleich größer und das darf man dann schon mal herausstellen. :thumbup:


    Ist ne ziemliche Fleißarbeit gewesen - ich weiß das ganz gut, da ich genauso eine UDF ebenso in AutoIt geschrieben habe.

    Eine neue Version steht bereit und bringt eine Funktion zum Schreiben von AutoIt-Arrays direkt in XLSX-Dateien mit.

    Die erzeugten xlsx-Dateien sind arg minimal aufgebaut.
    Das hat (noch) den witzigen Nebeneffekt, dass so erzeugte Dateien nicht wieder mit der _xlsx_2Array eingelesen werden können.
    Das baue ich aber noch irgendwann mal in Ruhe ein.


    Edit: Nun können auch die erzeugten Dateien wieder eingelesen werden

    dabei ist mir aufgefallen, dass ich ja aus der zweiten CSV Datei noch die ersten beiden Spalten löschen möchte

    Dann macht es nun auf einmal doch Sinn die als 2D-Array zu behandeln.
    Wobei es natürlich auch mit der stringbasierten Variante geht:

    AutoIt
    Local $aDatei1 = FileReadToArray("Datei1.csv"), $aDatei2 = FileReadToArray("Datei2.csv")
    $hOut = FileOpen("zusammen.csv", 2)
    For $i = 0 To UBound($aDatei1) - 1
    FileWriteLine($hOut, $aDatei1[$i] & "," & StringTrimLeft($aDatei2[$i], StringInStr($aDatei2[$i], ',', 1, 2)))
    Next
    FileClose($hOut)


    Ansonsten ist noch Oscars Frage nach der gleichen Zeilenanzahl zu beantworten.

    Man muss nicht unbedingt erst ein 2D-Array draus basteln.
    Dann wird es "ganz einfach" (diesmal wirklich... ;) )

    AutoIt
    Local $aDatei1 = FileReadToArray("Datei1.csv"), $aDatei2 = FileReadToArray("Datei2.csv")
    $hOut = FileOpen("zusammen.csv", 2)
    For $i = 0 To UBound($aDatei1) - 1
    FileWriteLine($hOut, $aDatei1[$i] & "," & $aDatei2[$i])
    Next
    FileClose($hOut)

    Mich wundert btw, dass es sich mit \A und \a nicht analog verhält.

    Naja das eine Datei auf ein Zeilenumbruchzeichen endet kommt halt ziemlich häufig vor.
    Z.B. bei Log-Dateien wo jede Info zeilenweise rausgeschrieben wird.
    Daher macht es schon Sinn einen entsprechenden Shortcut für diesen Fall einzubauen (eben das \Z).
    Das eine Datei hingegen mit einem Zeilenumbruch anfängt ist eher atypisch und daher hat man sicherlich auf einen derartigen Shortcut verzichtet da man stattdessen einfach nur ein \R? voranstellen müsste und man hat den selben Effekt.

    Oder meintest du, dass es einer entsprechenden Logik folgend stattdessen \a anstatt \A heißen müsste?

    Immerhin geht "\A(a|b|c)\Z". Ist zwar hässlich und wird mich irgendwann zwingen \A und \Z nachzuschlagen, wenn ich den Code überarbeite,

    Wenn es eventuell intuitiver für dich ist dann würde auch ^ als Stringanfang und $ als Stringende gehen (solange du nicht irgendwo ein (?m) einbaust): ^[abc]$


    aber scheinbar muss das in Autoit dann so. Danke.

    Kommst du zufällig aus dem Java, C++, oder Python-Bereich?
    Bei Java wird halt explizit zwischen .matches und .find unterschieden.
    Auch C++ und Python verhält sich so (match() vs. search()).


    Diese haben da halt eine explizite Unterscheidung getroffen. Die meisten anderen regex-Implementierungen (PHP, C#, vim, sed...) hingegen verhalten sich hingegen genauso wie AutoIt, welches im Grunde nur die weit verbreitete PCRE-Engine anbietet.


    Was nun intuitiv ist oder nicht hängt dann halt schlicht nur davon ab mit welchem Konzept du zuerst in Berührung gekommen bist.


    Um die Frage zu klären was denn korrekt wäre sage ich nur dass bereits Kenneth Thompsons qed-Implementierung aus den 60ern sich bereits so verhalten hat wie AutoIt heute auch schon :P


    Wenn dich das jedoch dermaßen stört kannst du dir jedoch einfach eine entsprechende Wrapper-Funktion erstellen:

    AutoIt
    ConsoleWrite(RegExWholeString("a", "a|b|c"))
    Func RegExWholeString($sString, $sPattern)
    Return StringRegExp($sString, "\A(" & $sPattern & ")\z")
    EndFunc


    Und um jetzt ganz gemein zu werden muss ich dir leider mitteilen, dass auch deine Lösung \A(a|b|c)\Z nicht in jedem Fall das macht was du erhoffst.
    Nämlich dann wenn noch ein Zeilenumbruch am Ende des Strings steht. \Z stört das nicht und matcht trotzdem.
    Um das Verhalten zu umgehen müsstest du ein \z statt einem \Z verwenden: StringRegExp("a" & @CRLF, "\Aa\z")

    Da es nur ein normaler String ist kann man ihn auch ganz normal wie ein String bearbeiten.

    Die Möglichkeiten hierzu wären ebenso vielfältig.

    Eine einfache Methode wäre:

    AutoIt
    $Logfile = StringReplace($Logfile, "\\", "\", 0, 1)


    Oder gleich eine Funktion verwenden die deine Pfade sauber aufbereitet:

    AutoIt
    #include <WinAPIFiles.au3>
    [...]
    $Logfile = _WinAPI_GetFullPathName($Logfile)

    Irgendwie bisschen wirr.

    Oben schreibst du erst was vom WinTextMatchMode, dann willst du wieder stattdessen den Titel suchen.


    Ich habe noch nicht ganz verstanden was das mit den Fragezeichen soll.
    Du parst einen AutoIT-String aus VB heraus irgendwie?
    Keine Ahnung was du da machst aber in VB werden einfache Anführungszeichen durch Backslash escaped: ' --> \' und in AutoIt durch Dopplung: ' --> ''.
    Je nach dem wo der String jetzt nun geparsed wird musst du halt die entsprechende Escape-Variante verwenden.

    In dem Text muss auch noch der String EJicyqvP ausgewechselt werden in myani_draw und myani_fade.

    Hm hier muss man eher wieder auf StringRegEx zurück, da der Inhalt ne eigene Struktur aufweist.
    Aber zumindest die Elementauswahl kann man über XML-Funktionen lösen: