Data Collection-Variables / Maps in AutoIt - Status?

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

Zitat von aSeCa

In den alten Threads ist viel die Rede davon, dass Maps nur Beta sind, das sollte sich ja mittlerweile geändert haben, oder?

In den alten Threads war das auch so - es war nur ein Feature der Beta-Versionen.
In irgendeinem der letzten Stable-Releases haben Maps auch Einzug in diese gefunden.
Ganz aus dem Fenster lehnen möchte man sich hier jedoch nicht aber defacto ist die Nutzung von Maps mittlerweile so verbreitet, dass diese auch in Zukunft mit ganz großer Wahrscheinlichkeit drin bleiben.
Wenn du AutoIt verwendest dann kannst du im Grunde also ziemlich beruhigt auf Maps setzen.

Zitat von aSeCa

Und wie gesagt, mir gehts darum, Informationen zu bestimmten Objekten abzulegen. z. B. Möbelstücke, es kann mehrere geben (das ist die eine Dimension meines Arrays) und dann gibt es etliche Eigenschaften, wie Höhe, Breite, Gewicht, Anzahl der Füße, Name, usw., aber auch weitere nested Arrays, z. B. eine Liste der Teile mit ID / Name / Anzahl.

Klingt für mich spontan eher weniger nach Maps und Co. als mehr nach einer Datenbank.
Insbesondere SQLite ist (fast) direkt in Autoit integriert, performant und lokal.
Je mehr Infos und evtl. Beispieldaten du gibst, umso eher könnte man dir ein Beispiel für so eine Datenbank inklusive deren Verwendung in AutoIt mal zeigen.
Auch interessant wäre wo die Daten herkommen und wie du sie Daten ins Programm bekommst.
Evtl. hätte ich da von deiner Beschreibung her eine UDF, welche eher dem entspricht was du erreichen willst.

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

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

Ich denke, das hier duerfte die meisten Verwendungszwecke von Maps abdecken:

Local $mData[]
$mData["value1"] = "Value 1"
ConsoleWrite($mData.value1&@crlf)
Local $mMapOther[]
$mData["value2"] = $mMapOther
$mData["value2"]["something"] = "Some Thing"
ConsoleWrite($mData.value2.something&@crlf)
$mData.value2.something = "Some Other Thing"
ConsoleWrite($mData.value2.something&@crlf)
ConsoleWrite("--------------------------"&@crlf)
For $i in $mData
	ConsoleWrite(VarGetType($i)&": "&$i&@CRLF)
Next
ConsoleWrite("--------------------------"&@crlf)
For $key in MapKeys($mData)
	ConsoleWrite($key&" = "&VarGetType($mData[$key])&": "&$mData[$key]&@CRLF)
Next
ConsoleWrite("--------------------------"&@crlf)
If MapExists($mData, "value1") Then ConsoleWrite("Value 1: "&$mData["value1"]&@crlf)
MapRemove($mData, "value1")
If Not MapExists($mData, "value1") Then ConsoleWrite("Value 1 is missing"&@crlf)

Dabei solltest du darauf achten, dass du immer beim ersten zuweisen eines Wertes den Key in [ ] angeben musst. Bei verschachtelten Maps fuer alle Keys, auch wenn der davor schon existiert (siehe $mData["value2"]["something"]).
Ansonsten kannst du mit der Punkt schreibweise Werte auslesen und ueberschreiben. Also mit z.B. $mData.value = 1. Das hat den Vorteil, dass SciTe dir das beim Tippen als Vorschlag gibt und du dir nicht alle Keys auswendig merken musst (Was z.B. bei Mars Variablen der Fall ist.)

MapAppend hab ich mal rausgelassen, weil ichs noch nie gebraucht habe... Bei ner Map geht es ja genau darum, dass ich Key-Value-Paare haben will... warum also mit Integers arbeiten, da nutz ich persoenlich lieber Arrays (auch wenn man es natuerlich als "dynamisches Array" nutzen kann, wie Mars bereits erwaehnte, dann macht s ggf. Sinn).

Ich finde es tatsaechlich etwas unintuitiv, dass bei einem "For $val in $mData" die Values durchlaufen werden und nicht die Keys. In allen anderen Sprachen die ich kenne werden die Keys (oder KeyValue-Paar-Objekte) iteriert und man kann dann damit die Values abfragen. Hier muss man leider erst alle Keys als Array holen (MapKeys) und die dann iterieren, was das ganze etwas umstaendlich macht

Ich hoffe, das hilft dir weiter,

LG Kanashius

Hallo

Jetzt lese ich mir den Beitrag schon zwei mal durch, sehe mir die Beispiele an und stehe immer noch auf dem Schlauch. Da ich aber immer durch die Beiträge hier viel lernen kann hatte ich mich gefragt ob das so was ich selbst vor einiger Zeit zusammen geschieben habe:

#include <Array.au3>
dim $kunden[3]
for $i = 0 to 2
    $kunden[$i] = ObjCreate ( "Scripting.Dictionary" )
Next

$nachname = "Nachname"
$vorname = "Vorname"
$alter = "Alter"
$Ort = "Ort"
$kunden[0]($nachname) = "Meier"
$kunden[1]($nachname) = "Huber"
$kunden[2]($nachname) = "Schmidt"

$kunden[0]($vorname) = "Karl"
$kunden[1]($vorname) = "Max"
$kunden[2]($vorname) = "Susi"
$kunden[0]($alter) = "21"
$kunden[1]($alter) = "33"
$kunden[2]($alter) = "51"
$kunden[0]($Ort) = "Linz"
$kunden[1]($Ort) = "Graz"
$kunden[2]($Ort) = "Wien"

$SearchItem = $alter
ConsoleWrite ("-------------" & @CRLF)
ConsoleWrite ("suche nach " & $alter & @CRLF)
ConsoleWrite ("-------------" & @CRLF)
For $i = 0 To 2
  ConsoleWrite ($kunden[$i].item($SearchItem) & @CRLF)
Next
ConsoleWrite (@CRLF)
$SearchItem = $nachname
ConsoleWrite ("-------------" & @CRLF)
ConsoleWrite ("suche nach " & $nachname & @CRLF)
ConsoleWrite ("-------------" & @CRLF)
For $i = 0 To 2
  ConsoleWrite ($kunden[$i].item($SearchItem) & @CRLF)
Next

oder bin ich da völlig falsch unterwegs?

lg

Racer

PS: Sorry das ich da so in den Betrag reinplatze

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

Zitat von Mars

Irgendwo habe ich neulich auch eine Table-UDF (für Tabellen) gesehen. Habe aber vergessen wo.

Na gut, da es jetzt doch erwähnt wird, will ich trotz der Gefahr der Schleichwerbung und zusätzlicher Verwirrung noch meinen Ansatz hierfür, welcher in der >>TableData-UDF<< implementiert wurde vorstellen.
Diese UDF arbeitet mit Objekten (Maps um genau zu sein), welche die Daten von den Headern trennen.
Das macht am Ende das Arbeiten mit diesen Daten einfacher, da statt Indizes Attributnamen verwendet werden können.

Am besten am Beispiel: Hier konvertieren wir ein 2D-Array in ein solches Objekt und lassen es uns anzeigen (es kann aber auch von Strings, CSV-Dateien usw. eingelesen werden):

#include "TableData.au3"

; Ausgangsdaten: 2D-Array mit Header-Elementen in der 1. Zeile (man kann auch einen eigenen Header definieren)
Global $aArray[5][4] = [["Name", "Alter", "Gehalt", "verheiratet"], ["Max", 25, 5000.50, True], ["Anna", 30, 6000.75, False], ["Peter", 35, 7000.25, True], ["Lena", 28, 5500.50, False]]

; Konvertierung in ein Tabellenobjekt:
$mData = _td_fromArray($aArray, True)

; Daten anzeigen
_td_display($mData, "Beispiel", True)

Nun kann man diese Daten mit den mitgelieferten Funktionen so verwenden, dass man einfacher mit ihnen arbeiten kann.

Z.B. kann man auf die Attributdaten der Datensätze einfach mit deren Namen zugreifen:

; Alle Datensätze durchgehen und Zugriff auf deren Attribute per Attributname
For $mP in _td_toObjects($mData)
	ConsoleWrite( $mP.Name &  " (" & $mP.Alter & "): " & $mP.Gehalt & "€" & @CRLF)
Next


; oder Einzelzugriff auf die Datensätze per Array-Index:
$aDaten = _td_toObjects($mData)
MsgBox(0,"Einzelzugriff", $aDaten[2].Name & " (" & $aDaten[2].Alter & ")")

Oder wenn in einer Spalte Werte stehen, welche als Primärschlüssel geeignet sind, dann kann man diese auch nehmen um auf die einzelnen Elemente zuzugreifen:

; konvertiere in Map, deren Key ein Primärschlüsselattribut ist:
$mTable = _td_toPrimaryKeys($mData)

; Greife auf die Datensätze über ihren Primärschlüssel zu:
MsgBox(0, "Annas Gehalt", $mTable.Anna.Gehalt)

Oder man filtert die Daten anhand ihrer Eigenschaften:

; Daten filtern
$mData = _td_filter($mData, "$x.Gehalt > 5999")

; gefilterte Daten anzeigen
_td_display($mData, "Großverdiener", True)

Oder man extrahiert sich einzelne Spalten anhand ihres Namens:

; Summe über das Gehalt bilden (hierzu Spalte "Gehalt" als 1D-Array extrahieren):
MsgBox(0, "Gehaltssumme", __Sum(_td_getColumn($mData, "Gehalt")))


; Funktion um Summe eines 1D-Arrays zu berechnen
Func __Sum($aArray)
	Local $nResult = 0
	For $i = 0 To UBound($aArray) - 1
		$nResult += $aArray[$i]
	Next
	Return $nResult
EndFunc

; extrahiere mehrere Spalten als 2D-Array
$aGehaltName = _td_getColumn($mData, "Gehalt;Name")
_ArrayDisplay($aGehaltName)

Oder man verknüpft seine Tabellendaten mit Daten aus anderen Tabellen:

#include "TableData.au3"

Global $aPersonen[5][4] = [["Name", "Alter", "Gehalt", "verheiratet"], ["Max", 25, 5000.50, True], ["Anna", 30, 6000.75, False], ["Peter", 35, 7000.25, True], ["Lena", 28, 5500.50, False]]
Global $aPositionen[5][2] = [["Name", "Position"], ["Max", "Referent"], ["Lena", "Direktor"], ["Peter", "Sachbearbeiter"], ["Anna", "Mitarbeiter"]]

; Konvertierung in Tabellenobjekte:
$mPersonen = _td_fromArray($aPersonen, True)
$mPositionen = _td_fromArray($aPositionen, True)

; verknüpfe beide Tabellen zu einer gemeinsamen anhand des Attributes "Name"
$mJoined = _td_join($mPersonen, $mPositionen, "Name")

; verknüpfte Daten anzeigen
_td_display($mJoined, "Verknüpfung", True)

Das ganze lässt sich dann auch fix in eine CSV-Datei schreiben oder als normales 2D-Array wieder weiterverwenden - ganz wie man möchte.
So ich denke das war jetzt genug Werbung.

Zitat von AspirinJunkie

Na gut, da es jetzt doch erwähnt wird, will ich trotz der Gefahr der Schleichwerbung und zusätzlicher Verwirrung noch meinen Ansatz hierfür, welcher in der >>TableData-UDF<< implementiert wurde vorstellen.

Das ist doch keine Schleichwerbung AspirinJunkie . Wenn du tolle UDFs zu Verfügung stellst, sprich auch gern darüber (zumindest meiner Meinung nach). Davon können sooooo viele Leute profitieren und dafür ist doch das Forum, GitHub (Open Source) u.a. da 😀 .

Also Danke dafür 🤝 .

Mars Danke auch dir für die Auflistung in Post #11: Ist krass wie viele Lösungsansätze existieren. Wird einem (mir) erst bewusst wenn es nochmal aufgezeigt wird 😅 .

Viele Grüße
Sven