PureBoard

Ich hab ein Problem mit ClearStructure() bzw es kommt eine Fehlermeldung nach Benutzung. Hier mal die Struktur um die es geht: Und hier der Code wo es benutzt wird. Wenn ich die empty-Variable vom selben Strukturtyp nehme um AllStat zu leeren gibt es kein Problem.
Aber immer wenn ich das ClearStructure verwende bekomme ich in der ersten Zeile nach ForEach die Fehlermeldung: "[COMPILER] Zeile 214: Die folgende Variable hat eine 'Structure': AllStat.

Dass sie eine Struktur hat ist ja klar aber was stört denn den Compiler jetzt?

Dann hab ich getestet ob man der Variable AllStat die eine Struktur ist nicht eine andere Struktur vom selben Typ einfach aufaddieren kann. Aber offenbar geht das so nicht. Stimmt die Syntax nicht? Im Moment addiere ich ansonsten nur die Einzelwerte.

Dein Codebeispiel ist entweder unvollständig oder ich verstehe das Problem nicht, oder beides: Geht problemlos, wie es bei Dir aussieht werde ich aber nicht erraten wollen, Code ist schon erforderlich.

Es schein eine Liste zu geben, sagt meine Glaskugel

Sorry... war ein Unachtsamkeitsfehler... Ich hatte nicht beachtet dass in gleichzeitig AllStat die Struktur zugewiesen wurde. Als ich das mit ClearStructure ersetzt habe fehlt dann die Zuordnung. Die Fehlermeldung sagte auch nicht das aus was mich drauf gebracht hätte.
Ich habe jetzt einfach die Definition for das Clear gesetzt und es kommt kein Fehler mehr... Weißt du ob man Strukturen gleicher Art einfach summieren kann irgendwie? funktioniert nicht. Das zweite Element ist eine Liste vom gleichen Strukturtyp.

SebastianJu2 hat geschrieben:Sorry... war ein Unachtsamkeitsfehler... Ich hatte nicht beachtet dass in

Der Fehler ist, Du nutzt immer noch nicht EnableExplicit. Ohne dies sollte man hier gar nicht erst posten!,
weil mit sind 50% aller Fehler weg

Dann werd ich das mal einbauen...

SebastianJu2 hat geschrieben:Dann werd ich das mal einbauen... bei der Menge an Handles wird das aber einiger Code mehr...

Das ist mir hier auch schon aufgefallen.
Gibt es einen bestimmten Grund, warum du dich mit sovielen Handles quälst
und nicht einfach Konstanten dafür nimmst?

#PB_Any ist ja vor allem für dynamisch zu erstellende Gadgets/Menüs/Wasimmer gedacht,
aber es jedesmal zu nehmen und Unmengen an Variablen mitzuschleifen ist doch etwas mühsam.

[Edit]
Oh, du hast editiert... egal, ich lass das mal.

@ts-soft

Gut dass define auch Mehrfachdeklarationen abfängt. Ich hatte aus Versehen beim Kopieren eine Handlevariable mehrfach benutzt und so kam es raus.

@Hexor

Ich dachte es wäre das beste wenn das System die Handles selbst wählt. Außerdem sind sprechende Namen meiner Meinung nach leichter zu handlen als nur Nummern. Und wenn man Konstanten nimmt dann hat man zwar auch sprechende Namen aber dann gibt es auch keinen großen Unterschied mehr zur Nutzung von Variablen oder? Performance dürfte bei diesen Handlen ja keine Rolle spielen. Oder doch zB bei Dateihandles und Schreiboperationen? Sind Konstanten da performanter?

Edit: Naja... so viele Variablen waren es dann doch nicht... nur ein paar Zeilen...

Konstanten werden beim Kompilieren durch die entsprechenden Zahlenwerte ersetzt,
performanter geht also eigentlich gar nicht.

Der eigentliche große Vorteil ist aber, dass sie automatisch global gültig sind.
Du brauchst also keinen Tross an globalen Variablen mit dir rumschleifen,
kannst sie aber dennoch in jeder Prozedur benutzen.

Und wenn du ihnen noch vernünftige Namen gibst, bleibt es auch übersichtlich.

Ordnest du sie geschickt in Enumerationen, kannst du auch z.B. sehr einfach verschiedene
Gadgets in einer Schleife abfrühstücken, z.B. wenn du ein paar Gadgets auf Knopfdruck disablen willst.

usw...

HeX0R hat geschrieben:Konstanten werden beim Kompilieren durch die entsprechenden Zahlenwerte ersetzt,
performanter geht also eigentlich gar nicht.

Ich hab das jetzt mal mit den Dateihandles versucht weil das der Ort ist an dem vermutlich am öftesten der Variableninhalt abgerufen würde aber dort habe ich noch keinen Performanceunterschied festgestellt. Es klingt aber generell wie wenn es performanter sein müsste und ich denke wo möglich werde ich zukünftig Konstanten nehmen.

HeX0R hat geschrieben:Der eigentliche große Vorteil ist aber, dass sie automatisch global gültig sind.
Du brauchst also keinen Tross an globalen Variablen mit dir rumschleifen,
kannst sie aber dennoch in jeder Prozedur benutzen.

So groß finde ich den Vorteil gar nicht. Ob man nun eine Variable als Global definiert oder eine Konstante ist die gleiche Menge Code. Oder meinst du dass globale Variablen irgendwie speicherlastiger sind?

HeX0R hat geschrieben:Und wenn du ihnen noch vernünftige Namen gibst, bleibt es auch übersichtlich.

Ordnest du sie geschickt in Enumerationen, kannst du auch z.B. sehr einfach verschiedene
Gadgets in einer Schleife abfrühstücken, z.B. wenn du ein paar Gadgets auf Knopfdruck disablen willst.

usw...

Klingt interessant.

Einziger Nachteil der Konstanten der mir bisher auffällt ist, dass sie offenbar jede einzelne eine eigene Codezeile brauchen. Aber das kann man wohl immerhin umgehen indem man den Doppelpunkt nimmt. Also nicht so schlimm.

Also ich denke ich werde Konstanten nutzen wo möglich...

Konstanten sind nicht schneller als die Handles, die man mit '#PB_ANY' bekommt. Ich mach's an einem Beispiel klar.

Es ist ja bekannt, dass Konstanten den Wert 5000 nicht überschreiten sollten. Dann meckert der Compiler nämlich mit einem Error.
Das heißt wir können als Konstanten auch nur Werte unter 5000 nehmen. Es wird vermutlich auch selten vorkommen, dass man mehr als 5000 Konstanten für solche Objekte anlegt. Von daher völlig ok.
Aber was passiert nun, wenn wir beispielsweise ein Fenster mit der Konstante 0 als ID erstellen. Intern wird natürlich eine entsprechende API aufgerufen und das OS erstellt das Fenster und gibt ein Handle dazu zurück. PB muss jetzt unsere ID 0 mit dem echten Handle verknüpfen. Wie macht es das? Ganz einfach mit einem Array. Sobald das Fenster erstellt wurde, erstellt PB also ein Array für Window-Handles der Größe 1 und speichert an Stelle 0 des Arrays das echte Handle für Fenster, das es vom OS bekommen hat.
Erstellen wir noch andere Fenster mir höheren konstanten IDs, wird dieses interne Array vergrößert um die zusätzlichen anfallenden Handles auch noch speichern zu können.
Wichtig wird das alles genau dann, wenn wir weitere Sachen mit dem Fenster machen wollen. Zum Beispiel, wenn wir es wieder schließen wollen. Dann schreiben wir einfach: PB schaut jetzt zunächst, ob der Wert in den Klammern unter 5000 liegt. Wenn das der Fall ist, ist es wohl eine Konstante, also muss diese im Array nachgeschlagen werden um an das echte Handle zu kommen. Erst mit diesem können wir dem OS sagen, dass es das Fenster schließen soll. Mit der Zahl 0 alleine kann es nämlich nicht viel anfangen.

Anders ist es bei '#PB_ANY'. Der Wert, der von 'OpenWindow' zurückgegeben wird, wenn man es benutzt, ist meines Wissens¹ schon direkt das OS-Handle. Es wird also nicht erst extra ein Array angelegt oder erweitert, wenn man es nutzt. Da diese Handles unter Windows, Linux und Mac typischerweise immer größer als 5000 sind, kommt es da auch nicht zu Kollisionen und deswegen ist es auch wichtig sie in Variablen vom Typ Integer zu speichern oder gleich als Pointer. Wie man eben möchte.

Ansonsten kann man sich auch darüber streiten, wie viele Variablen man so mit schleppen will. Ich bin eher für '#PB_ANY', strukturiere aber alles etwas anders, weil ich objektorientierter denke. Meine Handles werden in Strukturen gespeichert und nur dem entsprechenden Interface zur Verfügung gestellt, dass mit den GUI-Objekten was zu tun hat. So brauche ich auch keine globalen Variablen dafür, nur passende Strukturen.

Grob gesagt, wirst du keinen Performance-Unterschied feststellen zwischen '#PB_ANY' und Konstanten. Der ist so marginal, wenn überhaupt vorhanden, dass du davon absehen kannst. Und was den Vorteil von Enumerations angeht und dass man sie so schön durchlaufen kann: Das geht auch mit Arrays und '#PB_ANY'.