Beiträge von AspirinJunkie

    Na das war ja mal ekelhaft zu debuggen...

    Problem war den Fehler überhaupt erst einmal zu detektieren.

    Ursache war ein Stack-Overflow bei der PCRE-Engine aufgrund einem zu exzessiven Backtracking bei langen Strings.

    Die Behebung war dann ein Klacks: Einfach ein + hinzufügen (um einen Quantifier possesiv zu machen).


    Jetzt sollte es aber auch mit deiner Aerosmith_Lesbar.json klappen.

    Selbst die Aerosmith.json parst er nun, obwohl die mir jeder JSON-Validator mir die um die Ohren haut.


    Als Nebeneffekt sollte auch die Performance wieder ein Stück gestiegen sein.

    Ich bin dran wird aber wohl noch ne Weile dauern, da das Debugging in dem Fall echt eklig ist.

    Hab ein paar Vermutungen und auch schon einen ersten Bug gefunden.
    Dürfte die nächsten Tage aber hinreichend Zeit dafür fnden (Quarantäne - Yeah!).

    Mach mal ein Sleep(3000) hinter das_IECreate. Dann sollte es funktionieren (noch abhängig von deiner Verbindungsgeschwindigkeit).

    Ein _IELoadWait bringt in dem Fall nichts, da die Seite ja m Grunde vollständig geladen wurde. Die anderen Inhalte werden ja dynamisch per Ajax nachgeladen.


    Ganz ehrlch: Such dir ne andere Quelle für die Ermittlung der aktuellen JAVA-Version - mit der Seite wirst du nicht viel Freude haben.


    Edit:Hier in bisschen anderer Form formatiert findest du die jeweils aktuellen Versionen hier:

    http://javadl-esd-secure.oracle.com/update/baseline.version

    Die Info steht dort nicht im Quelltext sondern wird erst durch das eingebettete Javascript per Ajax nachgeladen.

    Da InetRead (und damit _InetGetSource) kein Javascript ausführt kommst du also nicht an die Info.


    Du brauchst also eine andere Quelle für deine Info oder du lässt den Code von einem Browser ausführen und liest dann die Infos aus.

    Mit _IEBodyReadHTML glaube ich könntest du weiter kommen.

    Für sowas sind reguläre Ausdrücke ideal.

    Ein Tutorial hierzu findest du >>hier<<.


    Dann sollte dich folgendes ein Stück weiter bringen:

    AutoIt
    #include <Array.au3>
    Global $sFile = FileRead("Test.log")
    For $aMatch In StringRegExp($sFile, "addCoin: (-?\d+) von (\d+)", 4)
    _ArrayDisplay($aMatch)
    Next

    Kannst auch mal so versuchen:

    Die _FileReadToArray kann zwar prinzipiell 2D-Arrays mit Hilfe eines Delimiters erzeugen.

    Jedoch leider nur wenn die Spaltenanzahl gleich bleibt.

    Das ist bei dir ja leider nicht der Fall.

    Eine Möglichkeit wäre die Datei zeilenweise einzulesen und sich das ganze selbst zu schreiben.


    Eine andere wäre einfach eine UDF zu nehmen welche für csv-Dateien vorgesehen ist.

    Mit >>dieser UDF<< würde der Code bei dir folgendermaßen aussehen:


    AutoIt
    #include "parsecsv.au3"
    $aArray = _parsecsv("Test.csv")
    _ArrayDisplay($aArray)


    Alternativ kann man auch deinen Code abwandeln mit dem kleinen Nachtteil, dass du vorher die maximale Anzahl an Spalten kennen musst:


    Will man völlig flexibel sein, was die Anzahl der Spalten angeht könnte man deinen Code folgendermaßen abwandeln:

    Die While und die Do-Schleife haben bereits Abbruchbedingungen in ihrer Syntax. Daher bietet es sich an diese auch gleich hierfür zu verwenden anstatt einem Endlosschleifenkonstrukt mit Abbruchabfrage innerhalb der Schleife:


    AutoIt
    Local $hTimer = TimerInit()
    Do
    ; ... Code
    Until TimerDiff($hTimer) > 30000

    bzw.

    AutoIt
    Local $hTimer = TimerInit()
    While TimerDiff($hTimer) < 30000
    ; ... Code
    WEnd

    Wie funktioniert die Berechnung der ASIN bei Amazon?

    Gar nicht. Die ASIN ist kein Hash die aus irgendwelchen Produktinformationen berechnet wird sondern lediglich ein eindeutiger Bezeichner innerhalb der Amazon-Datenbank.
    Die wird automatisch vom System vergeben (z.B. durch Hochzählen) und bei der Vergabe darauf geachtet, dass die ID nicht bereits in der Datenbank vorkommt.


    Wie kann ich sowas eindeutiges und kurzes mit AutoIt aus der Datei c:\test\test.au3 generieren?

    (Also eine "eindeutige Gruppen von 10 Buchstaben und/oder Ziffern", die stellvertretend für die Datei c:\test\test.au3 steht?)

    Einen Hash-Algorithmus nehmen, der weniger Stellen hat. CRC-32 z.B.

    Auch den md5-Hash kürzen geht ebenso.

    In beiden Fällen hat man jedoch einen kleineren Pool möglicher Varianten und damit eine höhere Wahrscheinlichkeit von Kollissionen.

    Ich kenne mich mit Kombinatorik / Permutationen nicht aus und kann aus dem ff nicht sagen, wie viele Varianten es bei 10 Buchstaben und/oder Ziffern gibt.

    Weiß das jemand von Euch?

    Eine md5 Checksumme hat 128 Bit - also 2^128 verschiedene Möglichkeiten = 3,4028237 * 10^38
    In hexadezimaler Schreibweise braucht man weniger Stellen - da sind es 32 Stellen (16^32 = 3,4028237 * 10^38).
    Wenn man nun also nur die ersten 10 Stellen der hexadezimalen md5-Checksumme nimmt, dann hätte man noch 16^10 = 1,0995116 * 10^12 Möglichkeiten übrig.

    Und wenn du es mit einem ganz eigenen Satz eines Alphabetes kodierst - z.B. alle Groß/und Kleinbuchstaben sowie Zahlen dann hätte man bereits mit 7 Stellen schon 62^7 = 3,5216146 * 10¹² verschiedene Möglichkeiten. Als Base64 hingeschrieben sogar noch nen Tick mehr: 64^7 = 4,3980465 * 10¹².


    Wieviele Kombinationen nun hingegen CRC-32 bietet und wieviel Stellen man hierfür bei hexadezimaler Darstellung braucht, kannst du dir nun selbst anhand der Info ausrechnen, dass CRC-32 32-Bit zur Verfügung hat.

    Ich meine damit dass es keinen generellen Parser gibt den du für jede Programmiersprache einfach nutzen kannst. Einen JSON Parser in Form einer DLL zum Beispiel.

    Es gibt JSMN den du als DLL kompilieren und einbinden kannst und es gibt jq den du von jeder beliebigen Programmiersprache aus über die Kommandozeile bedienen kannst..

    Wurde beides übrigens schon für AutoIt umgesetzt.


    Und warum muss überhaupt unbedingt ein und derselbe Parser in allen Programmiersprachen zur Verfügung stehen? Es reicht doch das alle Parser in den jeweiligen Programmiersprachen sich an den Standard halten und gut ist. Wo ist da ein Mehrwert? Zumal dein Dateiformat an diesen Umstand ja auch gar nichts ändert - es liegt ja nur für AutoIt ein Parser vor und der kann eben nicht z.B. als DLL in anderen Programmiersprachen weiterverwendet werden.


    Mal abgesehen davon, dass mit JSON halt noch viel viel mehr möglich ist - insbesondere Verschachtelung von Daten.

    Sagen wir mal, ich hab jetzt eine Programmiersprache die keinen JSON Parser von sich aus hat, viel spaß den Parser zu schreiben.

    "Sagen wir mal" - welche denn genau? Selbst für COBOL gibt es JSON Impementierungen.


    Und zum Thema "viel Spaß den Parser zu schreiben": Jo hat wirklich Spaß gemacht ;)

    So:

    AutoIt
    $d = Dec(StringTrimLeft("0x00000021", 2))
    MsgBox(0,"", $d)

    oder so:

    AutoIt
    $d = Execute("0x00000021")
    MsgBox(0,"", $d)


    Edit: Tja wenn es so ist wie alpines sagt - es sich also nicht um einen String handelt, dann gibt es kein Hex oder Decimal - es ist alles das selbe.

    Wow - wirklich klasse Ding :thumbup:


    Ein paar Fragen / Anmerkungen dazu:

    So wie ich das verstehe, ist ein direkter Zugriff auf die nativen AutoIt-Objekte selbst nicht vorgesehen (bzw. noch keine Funktion hierfür implementiert)?
    Also der Zugriff auf diese soll ausschließlich über die Funktionen der UDF erfolgen?
    Eigene Anpassungen der Controls sind damit also nicht möglich?

    Z. B. möchte ich einen Baloon-Tip auf einen Button setzen. In der XML-Struktur gibt es bislang keine Funktionalität hierfür und eine Funktion welche mir von einem der Elemente aus der XML-Struktur die Control-ID zurückgibt, habe ich auch nicht.

    Wenn du hier noch ein Möglichkeit schaffen würdest auf die darunterliegenden AutoIt-eigenen-Elemente zuzugreifen würde dies die Flexibilität und Einsatzmöglichkeiten wohl deutlich erhöhen.


    Du hast eine Pure-Basic-Dll als XML-Wrapper verwendet. Die Abhängigkeit zu dieser dll (die hier nur in 32Bit vorliegt und damit 64-Bit-Programme verhindert) ist sicher verschmerzbar aber eine Alternative wäre ja das Microsoft.XMLDom-Objekt gewesen welches ja bereits in Windows enthalten ist. Gibt es einen bestimmten Grund warum du den Pure-Basic-Wrapper bevorzugt hast?


    Zu der XML/JSON: Diskussion:
    Ne - XML ist schon die richtige Sprache dafür. Bisherige Formate für GUIs (Mozillas XUL, Microsofts XAML, das UI-Format vom Qt-Designer und und und) sind nicht ohne Grund XML-basiert.

    JSON kann zwar die Verschachtelung darstellen und damit die hierarchische Beziehung der Elemente gut abbilden, aber es existiert keine syntaktische Trennung von Elementattributen und Elementinhalt.

    Das müsste man über speziell benannte Attribute machen die schon optisch auf der selben Ebene stehen wie die Attribute des Elementes selbst.


    Wenn man es mit XML dann weiter treibt, kann man mit XSD die Struktur bis ins kleinste Detail festzurren so dass Abweichungen/Fehler gleich beim Parsen erkannt werden können (das geht sogar soweit, dass Wertebereiche für Values angegeben werden können und so weiter). In JSON müssten diese Checks wieder mit in den Programmcode und würden den entsprechend aufblähen (ja ich weiß es gibt JSON-Schema - aber mir ist kein in AutoIt verwendbarer Parser hierfür bekannt).

    Also XML ist schon die vernünftigste Wahl hierzu.

    Neue Version hab ich hochgestellt.


    Deine xlsx hat Zellen die keinen Inhalt haben aber einen Style besitzen.

    Für die Ausgabe als Array sollten die also ignoriert werden.
    Nun ist es jedoch so, dass die UDF zwei Wege hat die Ausmaße des Arrays zu bestimmen.

    Zum einen schaut sie ob ein dimension tag existiert, denn dort trägt Excel ein bis wohin die beschriebenen Zellen gehen.

    Problem hierbei: Gestylte, aber leere Zellen werden hier mit reingezählt.

    Wenn kein solches Tag existiert geht die UDF einfach alle Zellen durch und schaut wo das jeweilige Maximum liegt.
    In deinem Fall wäre diese Vorgehensweise aber meiner Meinung nach besser da du sonst am Ende noch einige leere Zeilen hast.


    Vielleicht sollte ich daher prinzipiell auf die Auswertung des dimension-tag verzichten?


    Vielleicht auch und statt oder? ;)

    Ja hab es natürlich mit ergänzt.


    Edit: Ach hab es jetzt einfach komplett auf die empirische Bestimmung der Dimension umgestellt.
    Der dimension-tag ist nun draußen.

    In Verbindung mit den neuen Zeilenauswahlparametern kann man übrigens Headerzeilen und sowas ignorieren.

    Bei deiner Testdatei z.B könnte daher folgendes die Weiterverarbeitung wohl vereinfachen: _xlsx_2Array("text.xlsx", 1, 5)


    Edit 2: Ach und weil ich gerade sehe, dass du Datumswerte mit drin hast - die kannst du im Nachhinein mit der bereits enthaltenen aber etwas versteckten Funktion __xlsxExcel2Date() in ein normales Datum umrechnen.

    Ich musste letztens xlsx-Dateien einlesen und mochte die Variante über Excel.au3 nicht wirklich, da diese durch Excel selbst ziemlichen Overhead hat und außerdem ist man darauf angewiesen dass Excel auch installiert ist. Also hab ich mir mal so eine xlsx-Datei näher angesehen und daraufhin eine kleine Funktion geschrieben, welche mir direkt mit Bordmitteln ein Worksheet aus der Datei in ein Array einliest.


    Das ganze ist jetzt nicht wahnsinnig auf alle Spezialfälle hin ausgebaut sondern deckt bislang die Fälle ab, welche bei mir bisher aufgetreten sind. Es gibt wohl auch schon andere UDFs die das gleiche machen aber selbst machen, macht mehr Spaß!


    Da die xlsx-Dateien entpackt werden müssen empfehle ich eine >>7za.exe<< mit zum Skript dazuzupacken, sonst wird auf die Shell.Application-Methode ausgewichen und die ist laaaaaaangsam...


    Große Erklärung ist nicht notwendig:

    AutoIt
    #include <Array.au3>
    #include "xlsxNative.au3"
    Global $aWorksheet = _xlsx_2Array("Test.xlsx", 1)
    _ArrayDisplay($aWorksheet)

    Changelog:

    2020/08/07 __xlsxExcel2Date: Stringausgabe (lokal formatiert) der Datums/Zeit-Werte implementiert
    2020/07/31

    Fix: Zellen mit hybriden Zellinhalten wurden ignoriert


    Leere aber gestylte Zellen werden nicht mehr prozessiert (Leerzeilen werden vermieden und etwas schneller)

    2020/07/30 Verbesserung der Namespace-Behandlung
    2020/07/29 Parameter um auf bestimmte Zeilen einzugrenzen hinzugefügt

    Dateien

    • xlsxNative.au3

      (13,28 kB, 48 Mal heruntergeladen, zuletzt: )

    Kann man die Suche nach unbalancierten Quotes so begrenzen, dass sie nur innerhalb 1 Zeile gewertet werden?

    Klar:

    Code
    (?mi)^\h*Func\h+((?(DEFINE)(?<brackets>\((?|''(?>[^''\v]+|'''')*''|"(?>[^"\v]+|"")*"|[^\(\)\r\n"'']*|(?&brackets))*\)))\w+\h*(?&brackets)\h*(?=\R\h*EndFunc))

    Edit: Evtl. wichtig dazu zu sagen: Das ist das Pattern für den String in AutoIt, da die Hochkommas bereits esaped sind.