Beiträge von alpines

    Solche "Benchmark"-zahlen sind ja schön und gut, aber kann das bitte jemand mal in einem realistischeren Szenario testen?

    Wo liegt denn genau das Problem? Werden Befehle generell langsamer ausgeführt? Brauchen Zeilen länger zum interpretieren?


    In dem Test wird nur eine Variable drei * fünf Millionen Mal inkrementiert, das ist gerade nicht aussagekräftig, da Skripte nicht nur Variablen inkrementieren.

    Fallen die Zeiten langsamer aus wenn bspw. fünf Befehle in einer Zeile ausgeführt werden oder ähnliches?

    Ich würde gerne, dass der Ladebalken flüssig ist.

    Dies geht aber nur, wenn ich ein 2tes Skript dafür habe, wie kriege ich das hin, das das zweite auf das erste zugreift usw.

    Das ist etwas komplizierter, und definitiv nicht der Weg den du gehen solltest.


    Was du bräuchtest wäre eine Kopiefunktion, welche deinen Thread nicht blockiert, so, dass das Skript ohne zu stocken weiterläuft.

    Spontan fallen mir zwei Lösungen ein:

    Entweder du benutzt eine Drittanwendung (robocopy) und überwachst den Fortschritt darüber, oder verwendest https://www.autoitscript.com/autoit3/docs/libfunctions/_WinAPI_CopyFileEx.htm wobei du durch einen Callback den Fortschritt bekommst.


    Ich weiß nicht ob es hier im Forum UDFs gibt welche bereits die Callback-Variante vereinfacht implementiert haben, aber du kannst ja mal nach ein paar Begriffen suchen, vielleicht findest du ja was, wenn du es nicht selber basteln willst.

    Auch nicht falsch verstehen, aber das ist eine ganz normale Darstellung einer Syntax. Vielleicht ist dir das noch nie aufgefallen, aber SciTE macht das genau so. Und meiner Meinung nach ist das richtig.

    Lässt sich drüber streiten. Wenn ein Parameter einen Standardwert besitzt ist er automatisch optional, dann braucht man auch keine Klammern drumherum, das macht es nur redundant.

    Es ist in AutoIt nicht möglich nach optionalen Parametern, nicht-optionale Parameter zu verwenden.


    Um ehrlich zu sein würde ich mich hier gar nicht aufhängen, implementier einfach eins und weiter gehts. Ändern kann man es immer.

    Finde die Variante ohne Klammern mit fetter Markierung am besten.


    GUICreate ( ... , top = -1 , style = -1 , exStyle = -1 , parent = 0 )


    Die Klammern kann man da lassen um SciTE4AutoIt "nachzuäffen" aber ich glaube die ignoriert sowieso jeder.

    Das würde in der Tat irritieren, denn dann wäre das Komma optisch irgendwie seltsam platziert, halb in dem einen Parameter, halb im anderen. :P Sieht schon seltsam aus:

    Das Komma nicht markieren, ich meinte das passende ].


    GUICreate ( ... [, top = -1 [, style = -1 [, exStyle = -1 [, parent = 0]]]]]]] )


    Finde diese Darstellung aber besser:


    GUICreate ( ... [, top = -1 [, style = -1 [, exStyle = -1 [, parent = 0]]]]]]] )


    Vielleicht auch:


    GUICreate ( ... [, top = -1 [, style = -1 [, exStyle = -1 [, parent = 0]]]]]]] )

    Derzeit wird dieses Feature nur für AutoIt eigene Funktionen und UDFs zur Verfügung stehen, also nicht für Funktionen, die man (gerade erst) selbst in einen Script definiert hat.

    Wenn du das aber einbaust wäre das ein richtiges Killerfeature. Das liebe ich so sehr in Visual Studio, und vermisse es in AutoIt.

    Bezüglich der Doppelten ", ich persönlich mach das nihct so gerne (komme dann immer durcheinander wie viele da jetzt wirklich sind :rolleyes: , daher mache ich das Lieber mit mit ' am Anfang und am ende.

    Oder ist das eher kontraproduktiv? hat das Nachteile? oder birgt das Fehler ?

    Das ist Stilsache, es gibt da keinen "wahren" Weg. Ich machs mit doppelten, weil ich das " viel schneller tippen kann als '.

    Forwardslashes / müssen in AutoIt escaped werden, deshalb schreibe ich das Backwardsslash \ davor.

    ( ) ist eine Capturegruppe, und gibt das zurück was drin enthalten ist, du kannst mit ?: also (?: ) sagen, dass die Gruppe nicht zurückgegeben werden soll.


    Die doppelten Gänsefüßchen sind dazu da, um bei einem String der mit " definiert ist, nicht ständig auf ' zu wechseln. Einfach zwei " nebeneinander und es wird als einzelner interpretiert.

    "Hallo ""ich"" bin ein Text." ~> Hallo "ich" bin ein Text.

    'Hallo "ich" bin ein Text.' ~> Hallo "ich" bin ein Text.

    "Hallo" & '"ich"' & "bin ein Text." ~> Hallo "ich" bin ein Text.

    Das, was man von einem Debugger sonst so geliefert bekommt, ist in AutoIt aufgrund der Sprache von vornherein ausgeschlossen: z.B. Prüfen auf Typunverträglichkeit Diese Fehler kann man in AutoIt nicht aufdecken durch den allmächtigen Datentyp "variant".

    Das würde ich so nicht unterschreiben, auch in AutoIt ist ein Datentyp zum Debuggen von Vorteil. Ich erinnere mich da an ein eher ekelhaftes Problem, bei dem _GUICtrlListView_GetSelectedIndices mit _GUICtrlListView_GetItemText nicht funktionieren wollte, da der Rückgabewert ein String war.

    Trotz LVS_SINGLESEL hat er den String nicht als Zahl interpretiert, und da hilft es einfach zu wissen welcher Datentyp da reinkommt. Schadet doch nicht?


    Aber einen Debugger bräuchte ich in AutoIt auch nicht. Ich lese mittlerweile auch gar nicht mal mehr die Konsolenzeilen wenn Fehler aufpoppen, ich gehe in die Zeile und sehe den Fehler meistens direkt selber.
    Ansonsten bin ich ein großer Anhänger von dieser Debugvariante :D

    Das ist für eine Interpretersprache nicht realisierbar.

    Na klar ist das realisierbar. Siehe AutoIt Debugger (den hat sogar PSblnkd angesprochen). Darüber, dass das alles andere als perfomant ist, brauchen wir uns aber glaube ich nicht zu streiten.


    Das wäre übrigens auch ein Killer-Plugin was Professor Bernd vielleicht selbstgebastelt in sein PSPad4AutoIt-Projekt einbauen möchte :^)

    Ist denn meine Lösung für Textdateien prinzipiell richtig, oder ist deine Methode die bessere Wahl? Wie gesagt es geht mir erst mal nur um Textdateien.

    Das kommt ganz darauf an wie groß die Dateien sind.


    Die Crypt-Bibliothek hasht glaube ich mit nativen Maschinencode und sollte daher schneller laufen.

    Es besteht zwar eine sehr kleine Chance (wirklich 'seeehr' klein), dass zwei verschiedene Dateien nicht erkannt werden aber das ist vernachlässigbar.