Beiträge von Mars

  • Persönliche Weiterbildung bzgl. IT, Programmierung und Co.

    1. Meine Weiterbildung erfolgt meistens privat durch "irgendwelche Sachen die ich sehe" und durch "herumbasteln". Das macht sich natürlich auf dem Papier nicht gut, daher bekomme ich alle Halbjahr irgendeine Weiterbildung gesponsort (ist immer Themenbezogen).

    Trends sind mir persönlich vollkommen egal, ich mache was ich für richtig halte. Da ich aktuell am C++ lernen bin (bzw. es seit ~5 Jahren aktiv nutze, aber man lernt ja nie aus), will ich das erst "perfektionieren" bevor irgendwas anderes um die Ecke kommt. Sowas wie z.B. Rust gefällt mir überhaupt nicht, da es sich anfühlt als würde man mit angezogener Handbremse programmieren. Den "Mit Rust konnte ich meine alten Projekte 3x so schnell neu implementieren" Bias halte ich ebenfalls für lächerlich. Ja, wenn ich ein altes Projekt erneut programmiere, dann bin ich 3x so schnell, selbst wenn ich die Sprache nicht wechsele. Aber gut, das ist Ansichtssache. Jeder soll machen was er für richtig hält.

    2. Ich habe noch keine dollen Papers geschrieben, bin aber gerade dabei. Das scheint wohl gern gesehen zu sein, und da ich soweiso eine Quatschtüte bin ist das kein Problem auch mal ein paar "ordentliche" Sachen zu schreiben. Insgesamt halte ich aber das publizieren für gnadenlos überbewertet. Ja, es ist wichtig neuen Kram für die Welt zugänglich aufzuschreiben, sodass sich das Wissen verbreiten kann. Finde den Fehler im vorherigen Satz. "Für die Welt zugänglich", war der Fehler, da alles was ich "ordentlich" schreibe hinter einer Paywall landen wird (außer auf den sieben Weltmeeren, die ich in diesem Bezug tatsächlich empfehlen kann).
    Wenn es nach mir ginge, gäbe es ein weltweites community moderiertes "Wissenschafts Wikipedia" bei dem eben nur Profs bzw. "Leute aus der Forschung an einer Bildungs/Forschungseinrichtung" Schreibrechte, aber jeder auf der ganzen Welt Leserechte besitzt. Möchte man etwas veröffentlichen muss man sich an jemanden vom Fach wenden. Damit wird direkt 90% Unfug (der sich auch in aktuellen Veröffentlichungen wiederfindet) herausgefiltert. Außerdem kann man "in diesem Wiki" eine Analyse machen ob das eigene Thema dort schon vorhanden ist. (Such mal 50 Journals/Konferenzen weltweit über die letzten 50 Jahre nach etwas durch was du erfunden/gefunden hast. Viel Spaß. Die Wahrscheinlichkeit ist 95%, dass du es nicht findest, selbst wenn es schonmal irgendwo aufgetaucht ist. Vielleicht falsche Keywords? Vielleicht falsche Sprache? etc.). Falls ja (Thema existiert bereits), dann bekommt man schreibrechte für den dazugehörigen Artikel für eventuelle Ergänzungen, falls nein (Thema ist neu bzw. transformativ), dann bekommt man einen eigenen Artikel. Ein super Nebeneffekt sind "Verlinkungen" die es zwar auch jetzt schon gibt [Mar24], mit der unfassbar altertümlichen Methode ([...] verweist auf einen Text der im Anhang steht, den ich googeln muss um das dazugehörige Paper zu finden was ich dann lesen muss um herauszufinden welche Stelle überhaupt zitiert wurde) bin ich aber auf Kriegsfuß. Wie schön wäre es, wenn ich [Mar24] anklicke und in einer Sekunde bin ich im richtigen Artikel in der richtigen Zeile um nachzulesen wo etwas herkommt... Das wird es leider niemals geben, zumindest nicht mehr in meiner Lebenszeit.

    Aber gut, damit kann niemand Geld verdienen, und Wissen wäre ein Grundrecht. So eine Welt haben wir halt nicht.

    Over and Out :D

    M

  • Select Cas in einem Intervall

    Es bringt halt leider auch Granaten wie das Folgende:

    Halbe Seite Text

    Dauert also noch etwas bis wir ersetzt werden :D

    (Bei der Frage habe ich implizit gehofft, dass mein Thread aus dem PU-Bereich gelesen wurde. Da ist ein Beispiel wie man die Pointer von (Globalen) AutoIt-Variablen durch ein paar Tricks herausbekommen kann)

    lg

    M

  • Select Cas in einem Intervall

    Einfach aus Jux habe ich die Frage mal in die KI gefüttert, und siehe da, der Code ist technisch gesehen korrigiert worden.

    Irgendwann werden wir als Supporter überflüssig, es ist nur noch eine Frage der Zeit :)

    Edit: Habe noch nachgefragt, ob man an dem Code noch etwas ändern könnte, und tatsächlich, das zweimalige Verwenden von "left" wurde als potenzieller Fehler markiert.

    lg

    M

  • Ungefähre Funktionswerte Puffern

    Moin,

    wer kennt es nicht. Man hat eine Funktion die irgendetwas stochastisch berechnet (Monte-Carlo) und relativ lange braucht.

    Diese Funktion möchte man aber im Idealfall "oft" aufrufen (ggf. in einer anderen Funktion, die ebenfalls stochastisch arbeitet, usw usw). Im Endeffekt resultiert das in Abermillionen von Funktionsaufrufen, die sehr schnell sehr viel Zeit in Anspruch nehmen.

    Aber es gibt Abhilfe: Ein sich selbst füllender Puffer der Funktionswerte an einigen Stützstellen speichert und dann linear interpoliert (mit Unsicherheitsangabe).

    Vermutlich habe ich darin noch ein Paar Bugs versteckt, aber für meine bisherigen Anwendungsfälle hat es funktioniert, daher gibts jetzt ne "mini-UDF". Wie bei allen Methoden ist es wichtig "sinnvolle" Parameter zu wählen, ansonsten läuft sich der Algorithmus tot (mit Failsave -> MaxIter) oder produziert vollkommen falsche Ergebnisse (z.B. wenn man nur 10 Stützstellen verwendet, obwohl man eigentlich mindestens 100 braucht, oder wenn man eine Genauigkeit von 0.01 haben möchte, obwohl die Funktionswerte die Größenordnung 100 und eine große Streuung haben). Was die Ungenauigkeitsangabe im Returnwert angeht möchte ich meine Hand nicht ins Feuer legen. Da sich der Mittelwert ja mit jedem neuen Sample ändert und die vorherigen Varianzen nicht angepasst werden können (man will ja nicht "alles" speichern) ist dieser Wert nur "ungefähr richtig".

    Die Verwendung ist glaube ich intuitiv ersichtlich wenn man das Beispiel anschaut. FFB heißt "FuzzyFunctionBuffer"


    Edit: Hier noch eine Überarbeitung mit quadratischer Interpolation (so kann man den LUT etwas kleiner wählen, oder man möchte eine sehr weiche Kurve. Die gab es bei der linearen Version nicht).


    lg

    M

  • RAM-Typ auslesen

    Zitat von water

    In der deutschen Übersetzung fälschlich "Blitz"

    Jedes Mal, wenn ich auf der MS Seite etwas nachschlage und diese furchtbaren deutschen Übersetzungen (teilweise von Naturkonstanten wie "BLACKNESS" beim BitBlt) sehe, klicke ich "diese Seite war nicht hilfreich" an und schreibe in den Kommentar rein, dass sämtliche Wörter die mit Programmcode zu tun haben bitte nicht übersetzt werden sollen. Ich hab schon Tabellen mit Enums gesehen die man von Start bis Ende in die Tonne treten konnte weil fast alle Bezeichnungen falsch waren X/

    Ist denen aber egal. Wenn ich nicht 90% der Namen von Sachen die ich dort suche schonmal gehört hätte wäre ich echt sauer, aus genanntem Grund bin ich nur "genervt" von sowas...

    M

  • [GDI+] Kurve zeichnen (3 Methoden)

    Moin,

    wer kennt es nicht: Ich möchte eine Funktion f(t) -> (x(t),y(t)) zeichnen und wähle einfach 100 gleichverteilte Punkte in t um das zu tun. Das Ergebnis sieht mies aus. Ich wähle 200 Punkte. Immernoch mies. 1000 vielleicht? Okay, jetzt sieht es OK aus, aber weil meine Kurve irgendwo ein paar fiese Kanten & Peaks hat ist das Ergebnis immernoch nicht Pixelgenau... Also 10000 Punkte?

    Anbei ist ein Skript mit 3 Methoden um eine Kurve zu zeichnen.

    1. Linear (das was oben beschrieben wurde, 1 f(t) call pro Punkt)

    2. Adaptiv (Zunächst mit niedriger Auflösung Linear, dann "schätzen" wo gute Orte für weitere Punkte sind, 1 f(t) call pro Punkt)

    3. Adaptiv2 (Es wird mehr oder weniger via BruteForce herausgefunden wo gute Orte für weitere Punkte sind, "viele" f(t) calls pro Punkt)

    Es sei angemerkt, dass nicht jede Funktion für jeden Anwendungsfall sinnvoll ist. 1 & 2 eignen sich für Echtzeitanwendungen (sie brauchen für ~100 Punkte nur ein paar Millisekunden, je nach PC). 3 ist dafür geeignet wenn man die Funktion mit den wenigst möglichen Punkten "nahezu" bestmöglich abbilden will und die benötigte Zeit keine Rolle spielt (z.B. wenn man die Punkte irgendwo puffert, dann muss man sie nur 1x berechnen und kann sie anschließend relativ performant anzeigen, weil es so wenige sind).

    Die Geschwindigkeit ist leider ziemlich mies, da ich an einigen Stellen faul war (z.B. lineare Liniensuche statt Newton, etc.). Außerdem fehlen mir gewisse Datenstrukturen in AutoIt die ich, mangels Pointersupport, auch nicht nachbauen konnte (bzw. ich war einfach zu faul alles via DllStruct zu machen).

    PS: Jede Funktion f(x) = ... lässt sich als f(x) = (x, y(x)) umschreiben, wie auch im Beispiel verwendet. Man muss also nicht zwingend f:R->R² Funktionen verwenden :)


    Edit: Um zu demonstrieren, dass es auch mit "echten" R² Funktionen klappt kann man z.B. sowas hier verwenden:

    Code
    Func F($t)
	Local $__[]
	$__[0] = $t * $iGuiW * 0.9 + $iGuiW * 0.05
	$__[1] = 50 * ManyGauss($t * 100 - 60) + 100*(2*$t-1)^2
	Local $a = 0.1, $cx = $iGuiW / 2, $cy = 0
	Local $_[]
	$_[0] = $cx + ($__[0] - $cx) * Cos($a) - ($__[1] - $cy) * Sin($a)
	$_[1] = $cy + ($__[0] - $cx) * Sin($a) + ($__[1] - $cy) * Cos($a)
	Return $_
EndFunc

    Eine gewöhnliche f(x) -> R Funktion könnte soetwas nicht abbilden, da einige x-Werte mehrere y-Werte besitzen. Fälle die in diesem Skript "nicht" abgedeckt sind, sind unstetige Funktionen. Falls es irgendwo einen "echten" Sprung in der Funktion gibt (z.B. Funktionen die aus mehreren Teilen bestehen die in einem Plot zu mehreren Linien führen), kann die hier gezeigte Methode nicht verwendet werden.


    lg

    M

  • Zeitreihe Regressionsanalyse Trendberechnung

    Meine Frage wäre: Was möchtest du konkret aus den Daten herauslesen?
    Soweit ich das verstehe sind die Daten wie folgt: Eintrag1 = [#Artikelnummer1 #Ankaufszahl1 #Verkaufszahl1, #DatumBzwZeitraum1, #WeitereInfos1], ... usw. für tausende Produkte und verschiedene Zeitpunkte/Zeiträume.

    Eine übliche Methode um ein Gefühl für Große Datenmengen zu bekommen ist erstmal die Ansicht verschiedener Scatterplots/Heatmaps (z.B. x-Achse = Datum, y-Achse = Verkaufszahl, Fabcode = Produkttyp. Hier muss man einiges an Kombinationen durchprobieren). Darin ergeben sich dann eindeutige Muster (je nachdem wie man den Plot parametrisiert), die man anschließend weiter auswerten kann.

    Bin aber nicht sicher, ob dir hier AutoIt weiterhelfen kann... Also einen Scatterplot kann man schnell und einfach basteln, aber das kann z.B. Gnuplot ebenfalls (ganz ohne Programmieraufwand). Die "Analyse" wird sich bei AutoIt auch auf lineare Regression einzelner Plotabschnitte beschränken (siehe oben), der Informationsgewinn hält sich dabei aber in Grenzen. Den Trend erkennt man ja schon am Plot.

    Edit: Falls du Trends extrapolieren willst wird es auch eher knifflig und ich vermute da bist du bei Machine-Learning-Leuten besser aufgehoben. Die kennen sich mit Voodoo aus :D

    lg
    M

  • _ConsoleWriteMap

    Sieht fast genauso aus wie etwas das ich immer verwende um Maps in die Konsole zu verfrachten :D

    Falls gemischte Keys (Integer-Keys & String-Keys) verwendet werden ist hier noch eine kleine Ergänzung:

    $sOut &= StringFormat('%s%-20s%s%s\n', $aC[$n], (IsString($k) And StringIsInt($k)) ? '"' & $k & '"' : $k, $vValue).

    Damit sieht man eindeutig womit man es zu tun hat.

    lg

    M

  • Rollende Kugel mit Textur

    Das ist ein super Beispiel. Hier wird Die Kugel einfach "Scheibchenweise" mit einer linearen Matrix gezeichnet, sodass insgesamt der Eindruck entsteht man hätte es irgendwie nichtlinear gelöst. Dafür muss man aber ein Sleep(100) einbauen und $iStep = 15 setzen, sonst sieht man das nicht weil es zu schnell und zu fein aufgelöst ist :D

  • Rollende Kugel mit Textur

    Sehr interessant. Hier noch eine Idee: Finde eine Transformation um die Einzelpixelrechnung komplett aus dem Spiel zu nehmen.

    Der Texturabdruck dieser Formel ist auch nicht ganz richtig für eine "korrekte" perspektivische Projektion einer Ebene auf eine Kugeloberfläche (Das Abbild ist eine um 45° gedrehte Raute). Da ich hier kein Profi bin ist Folgendes nur eine Vermutung: Die 3x2 Matrizen aus GDI+ werden hierfür wahrscheinlich nicht reichen, weil sie die Verzerrung nicht abbilden können. Dafür müsste man dann doch wieder nichtlineare Elemente einbringen die GDI+ nicht abbilden kann sodass man sie doch von Hand ausrechnen muss... Ist wahrscheinlich im Endeffekt kein Vorteil, aber ganz kurz dachte ich "vielleicht reicht die GDI+ übliche Matrix ja doch". Bin da kein Profi, von daher: Vielleicht bringt die Idee ja irgendwen weiter :D

    Den Texturfootprint kann man mit folgendem Skript einsehen:

    lg

    M

  • Frage zu seltsamen Verhalten von _WinAPI_CopyFileEx

    Zitat von hipfzwirgel

    p.s. für einen Hook hat MS ja 4ms als Wert festgelegt. Also müsste schon bei 10ms eigentlich die Progressproc abbrechen...

    Hinweis: Das "Sleep()" von AutoIt kann keine kleineren Schritte als 10ms verwenden. Du kannst zum Spaß mal 1000x Sleep(4) laufen lassen und jeweils mit TimerInit & Timerdiff stoppen wie viel Zeit tatsächlich geschlafen wurde. Leider funktionieren auch alternative Methoden wie delayexecution oder nanosleep mit AutoIt nicht zuverlässig (manchmal schon, manchmal aber auch nicht... Zumindest nach meiner Erfahrung).

    Das hilft dir jetzt nicht bei deinem Problem, aber die Info wollte ich loswerden, nicht dass du versuchst "Sleep(4)" anzuwenden und dich dann wunderst was hier eigentlich los ist :D


    lg

    M

  • Holen Sie sich aus den Ressourcen der ausführbaren Dateien Daten in Form einer Zeile ab

    The problem is:
    - This is impossible as long as noone knows everything about map/struct itself (what exactly is TdlgDXImages2, Font, TcxImageList, etc.). You cannot assemble a mapping without knowing all members.
    - This looks like a "map" from another programming language. If "everything" is known one might construct something with nested maps (in AutoIt) to represent the data but the memory layout will be vastly different. Also AutoIt does not allow to reinterpret_cast<map*>(ptr), so noone will be able to even get a memory dump of a map here (and vice versa) :D. A dedicated function to r/w is needed.
    - Wrapping this into a "struct" requires the knowledge of the whole memory layout. This is impossible, especially for maps with variant datatypes or other "unknown inner workings" like: What exactly is "[]" in memory? This looks like an empty list but only god knows how this is represented in RAM (assuming the shown binary data is a memory dump).
    - etc.

    Most people here are skilled in reading/writing code but I fear your request cannot be fulfilled by anyone without "the whole picture".

    To sum it up:
    - If "everything" about this map is known, it is possible to write a "ReadBinaryToNestedMap/WriteNestedMapToBinary" function.
    - If you find someone who wants to do this (after "everything" is known) is another story.

    M

  • Einfaches Preprocessing zum Komprimieren (nur eine Spielerei)

    Mit Ausgangspunkt ist gemeint, dass man das als Vorstufe für einen Kompressionsalgorithmus verwenden kann. Üblicherweise bekommt man eine bessere Kompression, wenn irgendeine Struktur in den Daten vorliegt die man ausnutzen kann. In diesem Fall: Sehr viel mehr Nullen als Einsen, dafür aber etwas unstrukturierter. (Ist also für einen Kodierer der Muster erkennt ungeeignet, die Muster wurden ja quasi in Nullen umgewandelt)

    Mögliche Folgeschritte wären:
    - Lauflängenkodierung (ist intuitiv das erste was mir einfällt)
    - Falls Lauflängenkodierung im Binärformat -> Arithmetische Entropiekodierung als Folgeschritt (huffman geht hier nicht besonders gut, da die Symbole nicht mehr aligned sind).
    - Falls Lauflängenkodierung mit Tokens -> Irgendeine Entropiekodierung (hier hat man die Symbole einzeln -> Jede Methode geht) als Folgeschritt -> Fertig.

    Probleme der aktuellen Methode:
    - Je größer der LUT, desto länger ist die Warmlaufphase, da der LUT erstmal gefüllt werden muss
    - Je größer der LUT, desto besser das Ergebnis nach der Warmlaufphase, aber man ist auf 16 Bit beschränkt.

    Lösungsansatz den ich irgendwann ausprobiere:
    - Baue einen beliebig großen "pseudo" LUT aus mehreren 8Bit Blöcken zusammen.
    - So siehts aus: [Block n-2][Block n-1][Block n][Bit x] -> Akuell wird nur [Block n] verwendet um x vorherzusagen. Man könnte allerdings auch alle anderen Blöcke einbeziehen. Da hier (aus Stochastik-Sicht) keine Unabhängigkeit vorliegt (es ist also ein Unterschied ob ich ausgehend von [Block n-1 (8Bit)] und [Block n (8Bit)] das x vorhersage, oder ob ich einen einzigen 16Bit Block nehme) muss man für halbwegs gute Ergebnisse vermutlich eine Art Interleaving verwenden.

    Trivialbeispiel mit 4 x 8Bit Blöcken -> [aaaaaaaa][bbbbbbbb][cccccccc][dddddddd][x] -> 4 Vorhersagen mit den Blöcken ohne Änderung (habe keine Nummern drangeschrieben, die aaaaaaaa sind eigentlich a1a2a3...usw)
    Zusätzlich mit Interleaving [abcdabcd][abcdabcd][abcdabcd][abcdabcd][x] -> 4 Weitere Vorhersagen für x
    Eine Linearkombination (mit irgendwelchen Koeffizienten die ich nicht kenne) dieser 8 Vorhersagen dient als Approximation der Vorhersage die ein einziger 32Bit Block liefern könnte. Je mehr Vorhersagen mit verschieden Verwobenenen 8 Bit Blöcken man verwendet, desto besser die Approximation. Gleichzeitig sinkt die Warmlaufphase, da man nicht 2^32 Zustände, sondern (im Beispielfall) nur 8 * 2^8 = 2048 Zustände vollmachen muss. Ich schätze damit sind auch bei "normalem Text" 90%+ Nullen möglich (statt 79%). Wäre zumindest lustig, wenn das gehen würde :)

    Danach kommt die "swap Methode" (aus dem Permutationen Komprimieren Thread) zum Einsatz (wobei hier die Nullen und Einsen geswappt werden um sie zu sortieren). Dann sind die Daten in folgender Form: [Bits zur Steuerung der Swaps][alle Einsen][alle Nullen]. Alle Einsen und Alle Nullen können als 2 Integer gespeichert werden, sodass die komprimierten Daten nur noch aus Swap-Positionen + 2 Int bestehen. Hehehe. Damit werde ich die Welt erobern.

    M

  • Einfaches Preprocessing zum Komprimieren (nur eine Spielerei)

    Moin,

    habe neulich nochmal über die LZ77 Methode nachgedacht und überlegt, dass man einen ähnlichen Effekt vermutlich auch deutlich einfacher bekommen kann. Die Idee ist folgendes:

    - Die Daten sind Binär '010101...' und wir wollen eine "Mustererkennung" ohne wirklich irgendwas zu rechnen.

    - Baue einen Lookuptable auf, der für jede Bitfolge (von z.B. 8 Bit) angibt, wie wahrscheinlich eine "0" oder eine "1" auf diese 8 Bit folgt.

    - Laufe alle Daten durch und ersetze sie durch "0" oder "1", je nachdem ob die Vorhersage gestimmt hat. Aktualisiere den LUT entsprechend nach jedem Schritt.

    - Das Ganze ist trivial reversibel.

    - Für einen Lookuptable mit >8Bit wird eine Map mit Stringkeys verwendet (das ist langsam). Falls man das mal in einer anderen Sprache programmiert müsste die Methode extrem schnell sein (es ist im Prinzip nur triviales Bitgeschiebe und Lookups), sollte auch ASM-freundlich sein.

    - Aktuell wird nichts komprimiert, sondern nur "die Anzahl der Nullen in den Binären Daten maximiert". Vielleicht kann man die Methode aber für irgendwas als Ausgangspunkt verwenden (z.B. Lauflängenkodierung, etc). Daher "Preprocessing", es ist ein Vorverarbeitungsschritt der redundante Daten durch Nullen ersetzt.

    Vermutlich hatten schon hunderte Leute dieselbe Idee, und was besonderes ist es auch nicht (daher in Off-Topic). Vielleicht kann damit ja trotzdem jemand etwas anfangen :)

    Beispiel mit zwei Datensätzen (oben im Skript via "GetSomeData" und "GetSomeData2") abrufbar. In der Konsole kann beobachtet werden die der Algorithmus "warmläuft", zu Beginn ändert sich fast nichts am Input (da jede Vorhersage daneben liegt), später bestehen die Daten aber zum Großteil aus Nullen (im Redundanten Fall bestehen sie quasi exklusiv aus Nullen). Getestet wurde nur rudimentär.

    (Edit: Genau das Gleiche habe ich vor Urzeiten schonmal gebastelt (nur viel umständlicher) und den Code nicht mehr gefunden)

    lg

    M

  • Kalkulator mit festen Variablen

    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

  • Kalkulator mit festen Variablen

    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 :S

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

    lg

    M

  • Array über Programmdauer hinweg speichern

    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

  • Data Collection-Variables / Maps in AutoIt - Status?

    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

  • Data Collection-Variables / Maps in AutoIt - Status?

    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

  • Data Collection-Variables / Maps in AutoIt - Status?

    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.

    lg

    M