Beiträge von Mars

Es gibt mehrere Möglichkeiten zur UI Gestaltung. Vermutlich ist es am einfachsten das ISN-AutoItStudio zu verwenden, wenn man eine Grafische Benutzeroberfläche haben will (ISN AutoIt Studio). Da ist ein GUI-Editor dabei.

Wenn man es via Code machen will (und sich schon etwas auskennt) habe ich dafür auch eine UDF: ([UIBB.au3] User Interface mit automatischer Anordnung der Ctrls - Vorschläge / Wünsche / Ideen). Die Beispiele dazu verwenden aber auch sehr viele Variablen wie "$hRightBot" etc. Das wurde dort so gemacht, damit man besser versteht wie die UDF arbeitet.

Edit: "UDF" = "User Defined Functions". Im AutoIt-Kontext steht der Begriff stellvertretend für "Bibliothek mit ein paar praktischen Funktionen die man via #include verwenden kann".

lg

M

Aufwandseinschätzung (von jemandem der sich mit AutoIt ein wenig auskennt):
- <15 Minuten (für das was bei dir im Screenshot angezeigt wird)
- ~1-5h (wenn man ein ordentliches UI haben will, ggf. mit Interaktionsmöglichkeiten wie "Spalte hinzufügen", "Items editieren", "Laden & Speichern", etc.. Aufwand abhängig davon wie viel man haben will)

Startpunkt sollte sein: Verwende Arrays (oder Maps)

- Deine Items (also die Tupel aus "Name" und "Preis") -> In ein Array damit.
- Deine UI-Elemente ("ein" möglicher Lösungsweg) -> Jede Zeile in eine Map mit ['Name'] = LabelFürName, ['Anzahl'] = InputboxFürAnzahl, ['Einzelpreis'] = LabelFürPreis, etc. Dann ein Array (oder Map) für alle Zeilen anlegen, sodass man Zeilen dynamisch hinzufügen und entfernen kann.

Ich weiß nicht wie versiert du im Programmieren im Allgemeinen bist, aber sehr viele AutoIt-Anfänger geben jedem UI-Element und allen anderen Sachen eigene Variablen (z.B. $LabelItem1Links, $LabelItem2Links, usw) und haben dann 500+ Zeilen an Copy&Paste um eine Tabelle anzuzeigen. Deshalb der Hinweis auf Arrays und Maps

Edit: Ich glaube du bist hier im falschen Forenabschnitt. Vermutlich wolltest du "Hilfe und Unterstützung" ?

lg

M

Ich weiß nicht ob dir das hilft, aber vor urzeiten (10 Jahre her) habe ich mal eine UDF geschrieben um Arrays auf die Platte zu schreiben (als einzelner String). Damals war der Map-Datentyp noch sehr experimentell, weshalb er nicht supported wird.

Ich kann leider keine Garantie dafür geben, dass alles so funktioniert wie es soll, da sich in der langen Zeit wohl irgendwas in der AutoIt-Internen Handhabung von "Binary" geändert hat (musste da eben ein paar Sachen fixen, vermutlich sind aber immernoch irgendwelche Fehler drin).

Was die UDF macht (bzw. machen soll):

- Nimm ein beliebiges 1D oder 2D Array (auch verschachtelt) und mache "einen einzigen String" daraus. (Es gibt Optionen dafür um GDI+Bitmaps, oder "Dateien" nicht als Pointer/String, sondern als "Bitmap" oder "Datei" zu interpretieren. In dem Fall werden die Bitmapdaten (mit .png Kompression, also nicht als Rohdaten) bzw. die komplette Datei eingefügt. Damit lässt sich die UDF auch als Container für Bitmaps und Dateien verwenden)

- Rekonstruiere dieses Array (incl aller Datentypen) wieder aus diesem String. Importierte Dateien werden NICHT automatisch irgendwo niedergeschrieben, sie sind als String im resultierenden Array. Importierte Bitmaps werden automatisch geladen und ein Pointer im Array hinterlegt.

- Dieser String lässt sich auch auf der Platte speichern (als Datei) und zu jedem späteren Zeitpunkt wieder auslesen.

Zur Sicherheit empfehle ich folgendes: Wandle dein Array in einen String um, speichere es als temporäre Datei. Lies diese Datei und mache wieder ein Array daraus. Vergleiche die Arrays vollständig. Nur wenn dieser Vergleich erfolgreich war ist das was auf der Platte liegt wirklich "das was du haben willst". Fall nicht -> Irgendwo ist ein bug den du mir gerne mitteilen kannst, dann schaue ich in der UDF und fixe das.

lg

M

Das liegt daran, weil es für diese Art von Problemen so viele Lösungen gibt
Jetzt haben wir:

- Verschachtelte Arrays (Indexbasiert)
- Verschachtelte Maps (Indexbasiert)
- Verschachtelte Maps (Stringkey basiert)
- SQLite (DB basiert, ist teil des Standards in AutoIt)
- JSON (Stringkey basiert, falls man es damit machen möchte, dann geht das auch, da gibts ne gute UDF)
- Dict (Stringkey basiert, mit BuiltIn Funktionen, oDict)
- Irgendwo habe ich neulich auch eine Table-UDF (für Tabellen) gesehen. Habe aber vergessen wo.

lg

M

Ich bin bei Enums ganz altbacken und verwende Großbuchstaben und Unterstriche (auch wenn ich das im Fließtext nicht gemacht habe) ohne Datentyp (typisch für #Define in C).

Hier wäre das also sowas wie:
...
$OLIST_WIDTH, _ ; Spaltenindex in der Objektliste (die 2D Map) für das Feld "Breite"
...

Das sieht dann zwar aus wie Code aus den 80ern (obwohl ich da noch nichtmal gelebt habe), ist für mich aber am besten Lesbar. Dann sieht man direkt was Globale Konstanten sind.

lg

M

Damit habe ich sowas gemeint wie _ObjectList_AddItem($mmList, $mItem), _ObjectList_GetItemByKey($mmList, $iFuesse), etc. Die üblichen Verdächtigen. Oder DB-Ähnliche Queries wie _ObjectList_GetAllItemsWith($mmList, $iKey, $xValue). (Den prefix 'mm' kann man auch weglassen. Der ist zur Übersicht, dass man nicht vergisst dass "List" eine "Map of Maps" ist. "x" steht für "Unbekannter Typ" und "i" für Integer)

Noch ein Hinweis zu Maps (der eigentlich offensichtlich ist, aber der hat mich schon einige Nerven beim debuggen gekostet): MapRemove erzeugt Löcher.

Local $_[]
$_[0] = 'Null'
$_[1] = 'Eins'
$_[2] = 'Zwei'
MapRemove($_, 1)
For $i = 0 To UBound($_) - 1 Step 1 ; Falsch. Wirft aber keinen Error.
	ConsoleWrite($i & ' ' & $_[$i] & @CRLF)
Next
For $i In $_ ; Man hat keinen Index, bekommt aber alle Elemente (Alternative zu MapKeys)
	ConsoleWrite($i & @CRLF)
Next

lg

M

Richtige Klassen und richtige Structs gibt es in AutoIt nach wie vor nicht. (DllStructs zählen nicht, die muss man von Hand verschachteln, und wenn man Strings als Datentyp hat muss man immer char[] verwenden was oft etwas nervig ist)

Maps verwende ich inzwischen quasi exklusiv, wenn es um "kleine Arrays", oder "Fake Klassen" geht. Mein Vorgehen ist dabei eigentlich immer wie folgt:

Global Enum $TYPE_VECTOR2

Func Vector2($vx = 0, $vy = 0)
	Local $_[]
	$_[0] = $vx
	$_[1] = $vy
	$_[99] = $TYPE_VECTOR2
	Return $_
EndFunc

Der Trick ist nun, dass du via Switch $_[99] aussortieren kannst welche "Typen" wie behandelt werden.

Soweit ich das sehen kann sind Maps inzwischen stabil, haben keine Memory Leaks (zumindest keine die ich noch finden konnte, ich habe selbstverständlich danach gesucht), und zu allem Überfluss sind sie für Integer-Keys in den meisten Fällen schneller als Arrays (bis zu einer gewissen Größe).

Von daher:
- Mach dir eine 2D Map (Map of Maps). Die kann man via $Map[][] in 2D auch direkt lesen und schreiben und sie verhält sich bei Integer-Keys exakt wie ein 2D Array. Hat aber den Vorteil dass man Zeilen hinzufügen kann, während man ein Array nicht einfach erweitern kann. Ich persönlich verwende immer Integer-Keys und ein "Global Enum mit $Name, $ID, $Fuesse, $Teileliste" direkt zu Beginn. Maps "kann" man auch mit String-Keys verwenden, aber damit verwirre ich mich meistens eher selbst als dass es was bringt.
- In die erste Zeile kommen wie üblich die Eigenschaften (Name, ID, Füße, Teileliste, etc)
- Teilelisten kannst du auch als Map direkt dort ablegen und dann via "$Map[15][$TeileListe][0] = Erstes Teil" lesen und schreiben.
- Noch ein Vorteil von Integer-Keys (wenn du dich daran hältst sie von 0 an aufsteigend zu verwenden, ohne Lücken): UBound kann verwendet werden statt MapKeys -> Eine Map mit aufsteigenden Integer-Keys kann exakt wie ein Array verwendet werden. (Edit: Das gilt natürlich nicht für "Fake-Klassen" bei denen in der [99] der Typ steht)

Du müsstest natürlich sämtliche Funktionen dieser "Informationsliste" selbst schreiben. Fast alle davon sollten aber trivial sein.
Falls deine Objekteliste 10.000+ Einträge hat ist diese Methode vermutlich zu langsam / zu aufwendig. Dann brauchst du vermutlich eine DB und damit kenne ich mich nicht aus
Edit: Genau für diesen Fall hat AspirinJunkie vermutlich eine geeignete UDF.

lg

M

Hatte vor Urzeiten auch mal was angefangen: Eine Makrosammlung für C++ (die hinten und vorne nicht funktioniert hat und inzwischen unauffindbar verschwunden ist, vermutlich irgendwann gelöscht beim PC neu aufsetzen...).

Die Idee dahinter war, dass man AutoIt-Code "fast" 1:1 als C++ laufen lassen kann, sofern man die richtigen Makros/Klassen definiert hat (ein bisschen Preprocessing ist trotzdem notwendig). Als jemand der ausschließlich Windows nutzt war der Plan dahinter aber nicht, dass Linux unterstützt wird (das könnte ich gar nicht machen, da kenne ich mich kein Stück aus). Das war einfach eine Spielerei.

M

Wahnsinn, wer hätte gedacht dass es es mal AutoIt-Videos auf Deutsch gibt

So ein paar verstreute Beispiele habe ich irgendwo schonmal gesehen, aber mehr ist mehr

lg

M

Das ist doch alles nur Spaß

(Ich habe meinen Beitrag noch 5x editiert, aber da war die Antwort schon da )

Je komplizierter desto besser. Hmm... stimmt. Die Entropie muss auch noch an anderer Stelle ergänzt werden, weil die "Ziehungen" nicht unabhängig voneinander sind (es ist ja eine Ziehung ohne Zurücklegen) was in der Entropie nicht berücksichtigt wird... (also Wahrscheinlichkeitsverteilung nach jedem Schritt renormieren). Und dann noch das mit den Fehlversuchen die man erst weiß nachdem man danebenlag... Und die Wahrscheinlichkeitsverteilung von Nutzereingaben die sich von der üblichen Buchstabenhäufigkeit unterscheidet...

Ich glaube das wird mir zu kompliziert.

Zitat von AspirinJunkie

1. Die Anzahl der Versuche richtet sich nach dem zufällig ausgewähltem Wort:
   Mein Vorschlag (mit nicht ganz trivialer Stochastik) zur Berechnung der Anzahl der Fehlversuche wäre daher hierzu folgender:

Da habe ich direkt an folgende Methode gedacht:
Die Entropie eines Worts ist (ungefähr) proportional zur Anzahl Bits, die eine Huffman-Kodierung (mit einem Tree der mit Wahrscheinlichkeiten für deutsche Buchstaben erstellt wurde) von diesem Wort ergibt. Mit unseren bereits implementierten Huffman-Kodierern sollte das trivial machbar sein (bzw. einfach mit der Entropieformel und der Wahrscheinlichkeitsverteilung der Buchstaben, den Kodierer braucht man ja nicht).

Ein Problem ist natürlich, dass beim Galgenraten automatisch "alle" Vorkommen des Buchstabens und nicht nur das erste aufgedeckt werden, sodass die reine Entropie hier einen "zu großen" Wert liefert. Vermutlich reicht es das Wort auf die ersten Vorkommnisse zusammenzustauchen: "vorkommnisse" -> "vorkmnise", und dann die Entropie zu berechnen. Der Wert dafür müsste eigentlich ein guter Indikator dafür sein wie kompliziert es ist das Wort "zufällig, aber mit dem Wissen über die Buchstabenverteilung" zu erraten.

In deiner stochastischen Analyse gehst du von einer Gleichverteilung der Buchstaben aus. Das sollte ein wenig zu kleine Ergebnisse liefern. Vielleicht kann man das irgendwie kombinieren und den "Ultimativen Galgenraten Versuchsanzahl Abschätzer" entwickeln

lg

M

Mir wäre das zu viel Text. Wenn ich eine 100 Zeichen Nachricht verschlüsseln will hätte ich keine Lust, dass 300 Zeichen herauskommen. Erst recht wenn man das im Kopf machen muss, so viel RAM hab ich gar nicht

Zitat von Alina

Aber es kann nicht passieren, das hier ein Fehler auftritt.

Das schreibe ich in Zukunft in meine Codekommentare direkt neben "this should never happen".

Zitat von Andy

Auf ein Beispiel was du wirklich meinst, wäre ich ECHT gespannt!...und ich bin ziemlich sicher...DU AUCH!

Tatsache. Ich habe nur die Hälfte von dem geschrieben was ich mir dabei gedacht habe, so ergibt das natürlich keinen Sinn (bzw. es ist einfach falsch)

Eigentlich wollte ich da auf die Unterschiede zwischen Clamp und BitAnd eingehen (also aus einer Zahl das 0x00??0000 via BitAnd und Div 256^n rausholen vs: Die gesuchte Zahl berechnen und clampen). Dann dachte ich mir, dass das wahrscheinlich nichts bringt und habe den halben Text irgendwie trotzdem geschrieben. Mysteriös.

lg

M

Schau dir BitOr, oder die Addition im Hexadezimalsystem an.

Beispiel:

Du hast: 0xRRGGBB (hex). Jeder dieser Teile hat 8 Bit. Es sind also 0xRR0000 + 0x00GG00 + 0x0000BB

Du möchtest: 0xAARRGGBB, es fehlt also der 0xAA000000 Teil. Je nachdem wie du das angehen möchtest kannst du also "einfach" 0xFF000000 addieren, oder (was sicherer ist, da es das Überlaufen in benachbarte Bytes verhindert, falls einzelne Werte größer als 255 sind. Das sollte bei hardgecodeten Werten nicht passieren, wenn die Werte aber berechnet werden und ein Clamp fehlt macht das beim einfachen Addieren die Farben kaputt) ein BitOr verwenden. Noch eine Alternative wäre das Zerlegen in Strings, sodass man via Int("0xFF" & "1A49BC") ebenfalls zum Ergebnis kommt (das wäre die "nicht mathematische Lösung").

lg

M

Mit "das größte Problem sind Datenstrukturen" habe ich natürlich ne steile These hingelegt. Sobald man mit "auto", "impl", Templates oder überladenen Operatoren anfängt (da weiß schon intellisense manchmal nicht mehr was der Code eigentlich macht) ist das Spiel sowieso vorbei

Mit der Geschwindigkeit (also dass man Code ziemlich doll umschreiben muss damit er in AutoIt ebenfalls "schnell" läuft) habe ich "relative geschwindigkeit" gemeint. Natürlich ist AutoIt 1000x langsamer, wenn man mies übersetzt ist es aber 5000x.

Mein Trip endet, sobald meine aktuelle Aufgabe endet.

Dann kommt die nächste Aufgabe und damit der nächste Trip

lg

M

Gerade bei der Geometrieverarbeitung erwartet dich in AutoIt nur Trauer und Schmerz. Ich habe selbst einiges aus C++ nach AutoIt übersetzt um einfache Tools zu basteln, und man merkt immer und immer wieder wie Pointer und Datenstrukturen fehlen.

Das ist auch das allergrößte Hindernis an einem Übersetzungsprogramm: Datenstrukturen. (das 2t größte Hindernis sind die 10.000 Stunden Aufwand die ein Übersetzer kostet)

Ja, wir haben DllStruct in AutoIt, die können aber nur primitive Datentypen halten. Möchte man verschachtelte Datenstrukturen verwenden muss man das mit Pointern erledigen. Um Pointer effektiv nutzen zu können muss man via DllstructCreate und kernel32-alloc manuell dafür sorgen, dass die Datenstruktur nicht gelöscht wird sobald keine AutoIt-Variable mehr vorhanden ist die sie hält (man will ja nur den Pointer haben), zusätzlich muss man aber irgendwie trotzdem dafür sorgen, dass der Speicher später freigegeben wird (ist möglich, aber unschön). Möchte man Datenstrukturen "in place" verwenden (z.B. Ball = (float x, float x, float diameter), BallPark = (Ball[10])) um z.B. direkt über alle "Ball" zu loopen muss man im Prinzip rekursives unrolling und alignment betreiben (sodass in der endgültigen Struct nur noch primitive vorhanden sind, die man dann auf umständliche Art und Weise via in Place erzeugter Struct anspricht). usw usw. Da kann man sich auch gleich nen eigenen Speichermanager schreiben. Was wahrscheinlich sowieso mal bitter nötig wäre, wenn man jemals über die "Struct die Primitive enthält" hinauskommen möchte.

Außerdem sind DllStructs in AutoIt deutlich langsamer als z.B. Arrays (oder seit einiger Zeit Maps mit IntegerKeys... die aus "Gründen" schneller sind als Arrays, solange die Größe < 256 Elemente ist). Was in C++ ein immenser Geschwindigkeitsvorteil ist (z.B. loop über alle "Ball", wenn sie aligned im Speicher liegen) ist in AutoIt unfassbar langsam (loop in verschachtelten Arrays/Maps). Apropos verschachtelte Arrays/Maps: Es gibt in AutoIt KEIN same scope ByRef. Du kannst den Inhalt eines Verschachtelten Arrays nicht direkt ansprechen. In der Klammersyntax ($A[0])[0] kann ein Array das in $A[0] liegt nur gelesen, aber nicht geschrieben werden, außerdem wird jedes Mal dereferenziert, wenn man das macht -> Langsam. Einziger Umweg ist über Funktionen mit ByRef Parameter, dann hat man aber den Overhead eines Funktionsaufrufs, was sich nur lohnt, wenn das Array das man beschreiben will eine gewisse Größe hat, für kleine Arrays ist 2x Kopieren schneller als 1x Funktionsaufruf mit ByRef.
Was ich damit eigentlich sagen will: Code der in C++ richtig schnell läuft muss komplett umstrukturiert werden um in AutoIt ebenfalls schnell zu laufen.

Es ist schon echt nervtötend "einfache" Sachen aus C++ von Hand zu übersetzen (ich meine nicht platten C-Code (flat API), der geht natürlich easy), und ich bin nicht in der Lage mir ein automatisches Programm dafür auch nur vorstellen zu können...

Edit: Hier mal ein Beispiel das wirklich nur für diesen einen Spezialfall funktioniert:

- Zeigt wie man "in place" eine Liste aus Structs in einer Struct bastelt, die auch (nur in diesem Fall hier) korrekt im Speicher liegt und daher von C++ 1:1 übernommen werden könnte (falls man 32bit aligned ist. bei 128 wird die Ball Struct noch 32Bit padding am Ende bekommen. Wenn man Vektorisierung angeschaltet hat wird das wahrscheinlich so sein, dann kann der Compiler auch automatisch sse verwenden, dann mag er 4x32er Blöcke lieber).

- mit "Spezialfall" meine ich z.B.: Der Typ "BALL" und der Feldname "ball" muss im UpperCase-Fall identisch sein. Man kann nicht mehrere Felder mit "BALL" Typ haben. "BALL" darf keine Feldnamen wie x, y, d haben. Und unendlich + 2 weitere Einschränkungen. Das ist kein Code den ich für irgendwas sinnvolles verwenden würde, er dient nur als Minimalbeispiel.

- Wenn man das "allgemein" Lösen will ist man Monate dran (und nicht die 15 Minuten die mich dieses Beispiel gekostet hat) und hat danach immernoch unendlich viele Bugs.

#include <Array.au3>
#include <Memory.au3>

Global $_DN[] ; Structnamen hinterlegen
Global $_DS[] ; Sizes

DllStructRegister('BALL;float;float;float')

; numBalls ist nur hier damit man zeigen kann wie man "in diesem Fall hier" das Offset berechnen kann. numBalls wird nicht verwendet.
$balls = DllStructCreate2('int numBalls;BALL ball[10]')

$oneBall = DllStructCreate2('Ball')
DllStructSetData($oneBall, 1, 1)
DllStructSetData($oneBall, 2, 2)
DllStructSetData($oneBall, 3, 3)

For $i = 0 To 9 Step 1
    DllStructSetData($oneBall, 1, Random(0, 10, 1))
    DllStructSetData($oneBall, 2, Random(0, 10, 1))
    DllStructSetData($oneBall, 3, 7)
    DllStructSetData2($balls, 'ball', $i, $oneBall) ; memcpy
Next

For $i = 0 To 9 Step 1
    $v = DllStructGetData2($balls, 'ball', $i) ; $v ist jetzt die "Ball" Struct (Kopie)
    ConsoleWrite('Type: ' & VarGetType($v) & ' size: ' & DllStructGetSize($v) & ' -> ')
    ConsoleWrite('Ball[' & $i & ']: ' & DllStructGetData($v, 1) & ', ' & DllStructGetData($v, 2) & ', ' & DllStructGetData($v, 3) & @CRLF)
Next


Func DllStructSetData2($v, $sName, $i, $xValue)
    If MapExists($_DS, StringUpper($sName)) Then
        Local $size = $_DS[StringUpper($sName)]
        Local $sStruct = $_DN[StringUpper($sName)]
        Local $iOffset = DllStructGetPtr($v, $sName) - DllStructGetPtr($v)
        Return _MemMoveMemory(DllStructGetPtr($xValue), DllStructGetPtr($v) + $iOffset + $size * $i, DllStructGetSize($xValue))
    EndIf
    DllStructSetData($v, $sName, $xValue, $i)
EndFunc

Func DllStructGetData2($v, $sName, $i)
    If MapExists($_DS, StringUpper($sName)) Then
        Local $size = $_DS[StringUpper($sName)]
        Local $sStruct = $_DN[StringUpper($sName)]
        Local $iOffset = DllStructGetPtr($v, $sName) - DllStructGetPtr($v)
        Return DllStructCreate($sStruct, DllStructGetPtr($v) + $iOffset + $size * $i)
    EndIf
    Return DllStructGetData($v, $sName, $i)
EndFunc

Func DllStructCreate2($sStruct)
    Local $a = StringSplit($sStruct, ';', 2), $b, $s = '', $c, $d
    For $i = 0 To UBound($a) - 1 Step 1
        If StringInStr($a[$i], '[', 0, 1) Then
            $b = StringSplit($a[$i], '[', 2) ; TYPE name
            $c = StringSplit($b[0], ' ', 2)
            If MapExists($_DN, StringUpper($c[0])) Then
                $d = StringSplit($_DN[StringUpper($c[0])], ';', 2)
                $s &= $d[0] & ' ' & $c[1] & ';'
                For $j = 1 To UBound($d) - 1 Step 1
                    $s &= $d[$j] & ';'
                Next
                For $j = 0 To Number(StringTrimRight($b[1], 1)) - 2 Step 1
                    $s &= $_DN[StringUpper($c[0])] & ';'
                Next
            Else
                $s &= $a[$i] & ';'
            EndIf
        Else
            If MapExists($_DN, StringUpper($a[$i])) Then
                $s &= $_DN[StringUpper($a[$i])] & ';'
            Else
                $s &= $a[$i] & ';'
            EndIf
        EndIf
    Next
    ConsoleWrite($s & @CRLF)
    $s = StringTrimRight($s, 1) ; remove ';'
    Return DllStructCreate($s)
EndFunc

Func DllStructRegister($sStruct)
    Local $sName = StringSplit($sStruct, ';', 2)[0]
    $sStruct = StringTrimLeft($sStruct, StringLen($sName) + 1)
    $_DN[StringUpper($sName)] = $sStruct ; String Key
    Local $_ = DllStructCreate($sStruct)
    $_DS[StringUpper($sName)] = DllStructGetSize($_)
EndFunc

lg

M

Die Einzige Version dich ich eine Weile lang parallel mitbenutzt habe ist die Beta 3.3.9.5. Grund war, weil das die einzige Version von AutoIt ist in der man das "$" bei Variablen weglassen kann, und ich so eine Rarität selbstverständlich zu schätzen weiß.

lg

M

Seit ich Visual Studio verwende, habe ich auch die Farbgebung in SciTE entsprechend angepasst.

(Ist eine Kombi aus dem Standard VSC++ Dark Theme und dem alten Dark Theme von SciTE für AutoIt)

Das verwende ich bereits so lange, dass ich AutoIt gar nicht mehr lesen kann, wenn das Farbschema "original" ist

(Nur als Input, falls das auch jemand verwenden möchte, jeder hat ja andere Präferenzen )

Edit: Sehe gerade, dass die Datei von BugFix doppelt so groß ist wie meine. Habe nicht ausprobiert was beim Einfügen meiner Datei in ein anderes Setup passiert. Ggf. muss man also ein wenig von Hand herumbasteln bis es klappt.

Edit2: Meine ".properties" Datei ist NICHT wie von Bugfix vorgeschlagen eine eigenständige Datei die in die eigentliche .properties eingebunden wird. Ich habe die Datei vor langer Zeit so angepasst wie sie jetzt ist und einfach aus meinem Ordner kopiert. Wenn man es "richtig" machen will nimmt man die Version von BugFix

lg

M

EDIT BugFix:

Ich war mal so frei und hab daraus eine reine Theme.properties erstellt, zu laden mit import dark_theme_mars

Für "einzelne" Flags ist BitOr und "+" das Selbe, da hier immer nur ein einziges Bit gesetzt ist. Für Kombinierte Flags ist das nicht mehr gegeben.

(nur zur Info, falls dich das verwirrt. Beide Schreibweisen können richtig sein, sofern man weiß was man tut)

Beispiel (binär):

0001 + 0100 = 0101 ist gleichbedeutend mit BitOr(0001, 0100) = 0101

0101 + 0100 = 1001 ist NICHT gleichbedeutend mit BitOr(0101, 0100) = 0101

Im ersten Fall ist jeweils nur 1 Bit gesetzt -> BitOr und "+" sind identisch.

Im zweiten Fall sind mehrere Bits gesetzt -> BitOr ist die einzige richtige Lösung.

lg

M