PureBoard

@Franky

Wer sich mal mit dem Aufbau eines GUI im Betriebsystem befasst hat, der ist Danilos Meinung

Da Funktionieren alle Betriebsystem ungefähr gleich.

Der Screen bildet die Wurzel, dann folgen Fenster in den Fenstern wieder Fenster oder Gadged in Gadgeds.

Das ganze ist eine Verschachtelung (Wie ein Verzeichnisbaum).

Jedes Objekt hat, damit es eindeutig ansprechbar ist, eine eindeutige Nummer.

PB setzt bloß die eigenen Nummern, in die Nummern des Betriebsystem um, denn nur über die Betriebsystem-Nummern sind die Objekte ansprechbar.

Die PB Nummer sind überflüssig, verwirrend und erhöhen den Programmtechnischen Verwaltungsaufwand.

So irre Konstrukte wie diese sind hoffentlich bald vergangenheit.

Die PB Nummer sind überflüssig, verwirrend und erhöhen den Programmtechnischen Verwaltungsaufwand.

Da gebe ich dir vollkommen recht.
Ich frage mich nur warum es so gemacht wurde ?
Das macht doch das ganze nur komlizierter.

Nur Windows:
Das oberste Fenster ist der Desktop (hWnd #NULL). Anwendungen haben ein
Fenster, das sogenannte Anwendungsfenster, darauf plaziert sind wieder
Fenster (z.B. Fenster der Klasse "Button"), sogenannte Childfenster, aber
Fenster!
Beim erstellen geben diese Fenster die Identifikationsnummer zurück, das
Händel. Aber gleichzeitig übergeben wir dem Fenster auch eine
Identifikationsnummer, das DialogItem (welches von PB verwendet wird).
Mit anderen Worten, bei Fenstern, alle Gadgets sind ein oder mehrere
Fenster, ist diese Vorgehensweise nicht Nachteilig.

Anders sieht es bei Dateien und Images aus. Da verwenden die anderen
BASIC-Dialekte jedoch auch meist keine Händel des Betriebssystems.

Für die API-Programmierung ist das Arbeiten mit den IDs
desBetriebssystemes jedoch manchmal einfacher. Aber nur aus dem
Grunde, das es keine Unterschiede zwischen "Gadget" und "GadgetID"
mehr gibt

Aber im Endeffekt ist es mir egal, ob ich alle Codes abändere, wegen diesem minimalem
Vorteil. Wollte nur betonen, so grosse Vorteile bringts nicht, wie man euch weismachen will

Die neue revolutinäre Variante ist dann folgende:

Global btn1.l, btn2.l ....
btn1 = buttongadget(---

Und lauter globale Variablen, müssen dann auch noch deklariert werden.
Das System mit Konstanten für Gadgets ist wesentlich einfacher und sicherer. Einzige alternative wäre OOP

Mein Senf dazu

OOP Jepp!! Jo!!

Ohne OOP geht es nun mal nicht in einer OOP Welt

Selbst LINUX benutzt zwar grundsätzlich C (also C++ ohne OOP) als grundsprache, aber das eine Datei oder ein Knopf ein Objekt ist (mit einer eindeutigen Identifikation) daran kommt auch C oder PB nicht vorbei.

Also muss man zumindest die Schnittstellen OOP fähig machen!!
Ohne OOP wird es in Zukunft immer schwerer...
(Meine Meinung ... senf .... ketschup ... majo, pommes döner gedöns.....)

Entweder wird das bisherige System für Gadgets beibehalten oder auf OOP
umgestellt. Nur mit hWnd statt Konstanten zu Arbeiten erfordert ja auch
lauter globale Variablen (oder eben Arrays oder Linklisten), bringt mehr
Nachteile als Vorteile. Mal abwarten ob mir PB 4.0 wirklich gefällt

Hm, die Gerüchte mehren sich....

Mal sehen, ob fr34k etwas näheres dazu sagen will...

Eine PB V4 Beta wäre sehr hilfreich für die Dokumentation im Wiki....

Oder wenigstens eine undichte stelle im Kreise der eingeweinten , die mal die wichtigsten änderungen verät.....

da fällt mit ein Liedtext ein:

All we can do, is just sit and wait....