Type erweitern mit anderem Type

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

Gehe zu Seite Zurück 1, 2

	Markus2	Do, Dez 14, 2006 19:52 Antworten mit Zitat
@Dreamora Append macht in meinem Fall schon Sinn ! Ich brauche nicht in Marks Modul was ändern . Wenn ich mein Programm compiliere erweitert es TGadget so wie ich will mit den Feldern die es noch nicht hatte . Andere brauchen also auch nix am GUI Modul anpassen wenn ich meinen Quelltext weiter gebe . Die alten Programm benutzen nach wie vor die TGadget Struktur wie gehabt . Überall wo TGadget übergeben wird werden halt auch meine Felder mit übergeben . Wird ein Gadget mit z.B. CreateLabel erstellt sind die Felder erstmal leer und danach kann ich meine Daten eintragen die ich später brauche . Und warum ist CreateLabel nicht als Funktion im TGadget drin ???

Markus2

Do, Dez 14, 2006 19:52
Antworten mit Zitat

@Dreamora

Append macht in meinem Fall schon Sinn !

Ich brauche nicht in Marks Modul was ändern .
Wenn ich mein Programm compiliere erweitert es TGadget so wie ich
will mit den Feldern die es noch nicht hatte .
Andere brauchen also auch nix am GUI Modul anpassen
wenn ich meinen Quelltext weiter gebe .
Die alten Programm benutzen nach wie vor die TGadget Struktur
wie gehabt .
Überall wo TGadget übergeben wird werden halt auch meine Felder
mit übergeben .
Wird ein Gadget mit z.B. CreateLabel erstellt sind die Felder erstmal leer
und danach kann ich meine Daten eintragen die ich später brauche .

Und warum ist CreateLabel nicht als Funktion im TGadget drin ???

	Dreamora	Do, Dez 14, 2006 20:05 Antworten mit Zitat
Weil CreateLabel wie die meisten MaxGUI Funktionen direkt C Funktionen aufrufen. Kannst dir ja die Sources ansehen. Wenn du es in deiner erweiterten Klasse implementierst hat das übrigens nur Vorteile: Dadurch hast du keine Probleme mit dem Funktionsheader der sonst identisch mit dem von TGadget.XXX sein müsste Was Append betrifft: Das braucht es nicht. Es ist nur so, dass du im Falle von MaxGUI nicht einfach die original Construktoren kopieren und den Type ändern kannst weil die MaxGUI Elemente ihre Funktionalität auf C Level haben. Dann wäre es nämlich kein Problem auch deine erweiterte Klasse zu machen. Bei eigenen Klassen ist es normalerweise kein Problem, wenn du dafür sorgst, dass default Dinge in Method new() stehen, weil die von allen Originalklassen aufgerufen werden, also nicht jeweils reinkopiert werden müssen. Das ist nur bei "Erzeugungsfunktionen" der Fall.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Do, Dez 14, 2006 20:05
Antworten mit Zitat

Weil CreateLabel wie die meisten MaxGUI Funktionen direkt C Funktionen aufrufen. Kannst dir ja die Sources ansehen.

Wenn du es in deiner erweiterten Klasse implementierst hat das übrigens nur Vorteile: Dadurch hast du keine Probleme mit dem Funktionsheader der sonst identisch mit dem von TGadget.XXX sein müsste Smile

Was Append betrifft: Das braucht es nicht. Es ist nur so, dass du im Falle von MaxGUI nicht einfach die original Construktoren kopieren und den Type ändern kannst weil die MaxGUI Elemente ihre Funktionalität auf C Level haben. Dann wäre es nämlich kein Problem auch deine erweiterte Klasse zu machen.

Bei eigenen Klassen ist es normalerweise kein Problem, wenn du dafür sorgst, dass default Dinge in Method new() stehen, weil die von allen Originalklassen aufgerufen werden, also nicht jeweils reinkopiert werden müssen. Das ist nur bei "Erzeugungsfunktionen" der Fall.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Markus2	Do, Dez 14, 2006 20:23 Antworten mit Zitat
Das steht so im maxgui.bmx !? Oder habe ich was übersehen ? Wieso kann das nicht in TGadget ? Code: [AUSKLAPPEN] [EINKLAPPEN] Function CreateButton:TGadget(label$,x,y,w,h,group:TGadget,style=BUTTON_PUSH) Return maxgui_driver.CreateGadget(GADGET_BUTTON,label,x,y,w,h,group,style) End Function Klar könnte ich den ganzen kram über meine eigenen Funk. aufrufen was ich aber nicht als eine Tolle Lösung halte .

Markus2

Do, Dez 14, 2006 20:23
Antworten mit Zitat

Das steht so im maxgui.bmx !?
Oder habe ich was übersehen ?
Wieso kann das nicht in TGadget ?
Code: [AUSKLAPPEN]

Function CreateButton:TGadget(label$,x,y,w,h,group:TGadget,style=BUTTON_PUSH)
Return maxgui_driver.CreateGadget(GADGET_BUTTON,label,x,y,w,h,group,style)
End Function

Klar könnte ich den ganzen kram über meine eigenen Funk. aufrufen
was ich aber nicht als eine Tolle Lösung halte .

	Markus2	Do, Dez 14, 2006 20:53 Antworten mit Zitat
@BladeRunner was macht denn das Speichermanagment wenn ich wie in deinem Beispiel das hier erstelle ? local X:a=new a habe ich dann zwei Speicherbereiche für basis und a oder ist das einer bzw. ein Block ?

Markus2

Do, Dez 14, 2006 20:53
Antworten mit Zitat

@BladeRunner

was macht denn das Speichermanagment wenn ich wie in deinem Beispiel

das hier erstelle ?

local X:a=new a

habe ich dann zwei Speicherbereiche für basis und a oder ist das einer bzw. ein Block ?

	BladeRunner Moderator	Do, Dez 14, 2006 22:26 Antworten mit Zitat
Ich vermute mal dass es en bloc angelegt wird - wissen tu ich es allerdings nicht genau. Allerdings ist ein Objekt ja mehr als nur der Speicher der für die Variablen belegt wird. Ich denke es wird eine Referenz auf den enthaltenen Basistyp geben. Wie genau das in Bmax gelöst ist kann ich Dir nicht sagen. Die Geschichte mit der allozierung war auch mehr zum verdeutlichen warum ein Append schwierig wäre. Denn du hättest wieder das selbe Problem. Alle Instanzen die auf dem 'unerweiterten' Type basieren hätten in ihrem Speicherabbild nicht die Methoden und fields auf die Du eventuell zugreifen willst. Daher würde es in einem Crash resultieren. Wie dreamora es schon sagte wäre es sinnig dir selbst die passenden Funktionen zu schreiben wenn du unbedingt erweitern willst. Du musst dir also die Gadgets quasi wrappen. Nicht das schönste, aber machbar.
Zu Diensten, Bürger. Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92

BladeRunner

Moderator

Do, Dez 14, 2006 22:26
Antworten mit Zitat

Ich vermute mal dass es en bloc angelegt wird - wissen tu ich es allerdings nicht genau. Allerdings ist ein Objekt ja mehr als nur der Speicher der für die Variablen belegt wird. Ich denke es wird eine Referenz auf den enthaltenen Basistyp geben. Wie genau das in Bmax gelöst ist kann ich Dir nicht sagen. Die Geschichte mit der allozierung war auch mehr zum verdeutlichen warum ein Append schwierig wäre. Denn du hättest wieder das selbe Problem. Alle Instanzen die auf dem 'unerweiterten' Type basieren hätten in ihrem Speicherabbild nicht die Methoden und fields auf die Du eventuell zugreifen willst. Daher würde es in einem Crash resultieren. Wie dreamora es schon sagte wäre es sinnig dir selbst die passenden Funktionen zu schreiben wenn du unbedingt erweitern willst. Du musst dir also die Gadgets quasi wrappen. Nicht das schönste, aber machbar.

Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3
Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64
B3D BMax MaxGUI
Stolzer Gewinner des BAC#48, #52 & #92

	Dreamora	Do, Dez 14, 2006 22:39 Antworten mit Zitat
In BM ist es relativ einfach gehandhabt: Ein BM Objekt ist intern ein C++ Objekt (weswegen Append direkt entfällt), einzige Ausnahme ist, dass die ersten 2 Einträge in der C++ Klasse in BM nicht sichtbar sind (einer ist die Klassenbezeichnung glaub ich, der andere ist mit gewissheit der GC Referenzenwert - letzteren haben schon so einige für interessante "Auto Destruct Hacks in Module genutzt ^^) Die Ausnahme mit den beiden Einträgen ist auch der Grund warum man externe Klassen in BM auch net voll OO nutzen kann. (man kann sie extern deklarieren, nur diese klassen können net extended werden) Die Tatsache das es C++ Objekte sind erlauben einige Spielereien, welche ich hier aber nicht erläutern werd, weil ich aktive GC Umgehung nicht unterstütze. Wenn du jedoch ein wenig Erfahrung in C / C++ hast, wirst du schnell einige sehr simple und SEHR mächtige Wege finden, wie du zb auch TGadget erweitern kannst und dir im Konstruktor sehr viel Arbeit sparen kannst (MemCopy, Byte Ptr, Size Of - damit kommste fein raus, speziell das MaxGUI gadgets NICHT GC managed sind womit du auch keine GC Probleme haben solltest)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Do, Dez 14, 2006 22:39
Antworten mit Zitat

In BM ist es relativ einfach gehandhabt:

Ein BM Objekt ist intern ein C++ Objekt (weswegen Append direkt entfällt), einzige Ausnahme ist, dass die ersten 2 Einträge in der C++ Klasse in BM nicht sichtbar sind (einer ist die Klassenbezeichnung glaub ich, der andere ist mit gewissheit der GC Referenzenwert - letzteren haben schon so einige für interessante "Auto Destruct Hacks in Module genutzt ^^)

Die Ausnahme mit den beiden Einträgen ist auch der Grund warum man externe Klassen in BM auch net voll OO nutzen kann. (man kann sie extern deklarieren, nur diese klassen können net extended werden)

Die Tatsache das es C++ Objekte sind erlauben einige Spielereien, welche ich hier aber nicht erläutern werd, weil ich aktive GC Umgehung nicht unterstütze. Wenn du jedoch ein wenig Erfahrung in C / C++ hast, wirst du schnell einige sehr simple und SEHR mächtige Wege finden, wie du zb auch TGadget erweitern kannst und dir im Konstruktor sehr viel Arbeit sparen kannst (MemCopy, Byte Ptr, Size Of - damit kommste fein raus, speziell das MaxGUI gadgets NICHT GC managed sind womit du auch keine GC Probleme haben solltest)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Markus2	Do, Dez 14, 2006 22:54 Antworten mit Zitat
@BladeRunner&Dreamora ihr wollt mir jetzt erzählen das die Gui.bmx module gar nicht mit compiliert werden wenn ich mein eigenes Programm compiliere , oder ? So wie ich den Compiler verstanden habe wandelt der die BlitzMax Syntax in C Syntax um und dann wird compiliert . Das Teste ich jetzt selber ... Moment ... EDIT: wieder da . Ok , klaro , die Module sind ja vorkompiliert . Also ich habe jetzt im Gadget.bmx die TGadget Struktur erweitert und compiliert (build Modul) und ich kann dieses Feld ohne weiteres in mein Programm benutzen . Also wenn ich dieses Append Type hätte müßten nur alle Module die dieses Type benutzen auch mit compiliert werden . Vorkompiliert wären die Module immer nur im original . Hmmm...

Markus2

Do, Dez 14, 2006 22:54
Antworten mit Zitat

@BladeRunner&Dreamora
ihr wollt mir jetzt erzählen das die Gui.bmx module gar nicht
mit compiliert werden wenn ich mein eigenes Programm compiliere , oder ?
So wie ich den Compiler verstanden habe wandelt der die BlitzMax Syntax
in C Syntax um und dann wird compiliert .

Das Teste ich jetzt selber ... Moment ...

EDIT:
wieder da .

Ok , klaro , die Module sind ja vorkompiliert .

Also ich habe jetzt im Gadget.bmx die TGadget Struktur erweitert
und compiliert (build Modul) und ich kann dieses Feld ohne weiteres in mein Programm
benutzen .

Also wenn ich dieses Append Type hätte müßten nur alle Module
die dieses Type benutzen auch mit compiliert werden .
Vorkompiliert wären die Module immer nur im original .

Hmmm...

	Dreamora	Fr, Dez 15, 2006 1:08 Antworten mit Zitat
Nur das es keine Append gibt und nie geben wird. Es gibt, zumindest meines Wissens, keine Sprache die OO ist, Append besitzt und in Binary kompiliert. Und Module "mitkompilieren" garnichts, wenn du sie importierst, denn das sind nur Referenzen auf das entsprechende Modul, kein Link oder sonstwas. Deswegen sind sie auch nicht veränderbar. Und der BM Compiler wandelt das ganze in ASM um, nicht in C. Für C sources wird GCC 3.1 installiert benötigt (auf Windows), welcher dann den C Code kompiliert. Was deine Änderung anbelangt: Theoretisch kannst du MaxGUI auch kopieren, das Modul umbenennen und dann dort das ganze für dich erweitern Allerdings stellt sich mir die Frage was dir deine Erweiterung / Hackerei genau bringen soll, denn ich wüsste nicht was man noch an die Gadgetklasse ranhängen müsste. Jedes gadget besitzt einen Text den man zb nutzen kann und auch noch einige andere Felder (wobei eigentlich Text ausreichend ist, da der einen String nimmt womit eigentlich jedes Objekt gespeichert werden könnte ...)
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Dez 15, 2006 1:08
Antworten mit Zitat

Nur das es keine Append gibt und nie geben wird.
Es gibt, zumindest meines Wissens, keine Sprache die OO ist, Append besitzt und in Binary kompiliert.

Und Module "mitkompilieren" garnichts, wenn du sie importierst, denn das sind nur Referenzen auf das entsprechende Modul, kein Link oder sonstwas.
Deswegen sind sie auch nicht veränderbar.

Und der BM Compiler wandelt das ganze in ASM um, nicht in C.
Für C sources wird GCC 3.1 installiert benötigt (auf Windows), welcher dann den C Code kompiliert.

Was deine Änderung anbelangt: Theoretisch kannst du MaxGUI auch kopieren, das Modul umbenennen und dann dort das ganze für dich erweitern Smile

Allerdings stellt sich mir die Frage was dir deine Erweiterung / Hackerei genau bringen soll, denn ich wüsste nicht was man noch an die Gadgetklasse ranhängen müsste. Jedes gadget besitzt einen Text den man zb nutzen kann und auch noch einige andere Felder (wobei eigentlich Text ausreichend ist, da der einen String nimmt womit eigentlich jedes Objekt gespeichert werden könnte ...)

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Markus2	Fr, Dez 15, 2006 1:42 Antworten mit Zitat
@Dreamora Eigentlich würde es mir reichen wenn im TGadget ein Objekt abgelegt werden kann . Das kann dann irgendeine Struktur sein und ich könnte das Objekt wieder in diese Struktur wandeln . Ich bin dafür das TGadget erweitert wird um Field propertyex:Object was hälst du davon ? Welches Feld bei TGadget meinst du was frei wäre ? Also wenn diese GUI Module jedes mal neu compiliert werden müssen ist in der Tat doof weil da zu viel Zeit bei drauf geht . Man könnte sie statt importieren aber includen wie auch immer . Ok , dann wird das ganze direkt in ASM umgewandelt , wäre aber das gleiche wenn eine bmx Datei Grundlage ist . Aber vergessen wir das jetzt . Kopieren und ändern will ich das GUI Modul nicht wegen weitergabe von Quelltexten etc. und wenn es mal updates gibt muß ich den scheiß selber anpassen bzw. übernehmen oder neu machen .

Markus2

Fr, Dez 15, 2006 1:42
Antworten mit Zitat

@Dreamora

Eigentlich würde es mir reichen wenn im TGadget ein Objekt abgelegt werden kann . Das kann dann irgendeine Struktur sein und ich könnte
das Objekt wieder in diese Struktur wandeln .
Ich bin dafür das TGadget erweitert wird um
Field propertyex:Object
was hälst du davon ?

Welches Feld bei TGadget meinst du was frei wäre ?

Also wenn diese GUI Module jedes mal neu compiliert werden müssen
ist in der Tat doof weil da zu viel Zeit bei drauf geht .
Man könnte sie statt importieren aber includen wie auch immer .
Ok , dann wird das ganze direkt in ASM umgewandelt ,
wäre aber das gleiche wenn eine bmx Datei Grundlage ist .
Aber vergessen wir das jetzt .
Kopieren und ändern will ich das GUI Modul nicht wegen weitergabe
von Quelltexten etc. und wenn es mal updates gibt muß ich den scheiß
selber anpassen bzw. übernehmen oder neu machen .

	Dreamora	Fr, Dez 15, 2006 1:58 Antworten mit Zitat
Aktuell liesse sich zb .context:Object missbrauchen Meines Wissens wird das aktuell für keine internen genutzt, das scheint mehr dafür da zu sein, dass man bei Event Hooks mit eigenen Events nen Early Drop hat (bzw. auch einfach wenn man viele Event Hooks hat). Versuche die Objekte der Basismodule erweitert zu bekommen wurden eigentlich schon länger aufgegeben, da noch nicht mal notwendige Erweiterungen rein kommen (gewisse Events nicht gefeuert, bugs in den gesamten Farb / Alpha Befehlen behoben, das SetPanelPixmap Problem behoben, List Element Anzahl Bug behoben etc etc) Was aktuell am sinnvollsten ist, sofern man ein Spiel macht: Ingame Editor mit HighGUI oder selbst was schreiben.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Dez 15, 2006 1:58
Antworten mit Zitat

Aktuell liesse sich zb .context:Object missbrauchen Smile

Meines Wissens wird das aktuell für keine internen genutzt, das scheint mehr dafür da zu sein, dass man bei Event Hooks mit eigenen Events nen Early Drop hat (bzw. auch einfach wenn man viele Event Hooks hat).

Versuche die Objekte der Basismodule erweitert zu bekommen wurden eigentlich schon länger aufgegeben, da noch nicht mal notwendige Erweiterungen rein kommen (gewisse Events nicht gefeuert, bugs in den gesamten Farb / Alpha Befehlen behoben, das SetPanelPixmap Problem behoben, List Element Anzahl Bug behoben etc etc)

Was aktuell am sinnvollsten ist, sofern man ein Spiel macht: Ingame Editor mit HighGUI oder selbst was schreiben.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

	Markus2	Fr, Dez 15, 2006 13:49 Antworten mit Zitat
@Dreamora das GUI von Windows war schon immer schlecht und da kann man Simon oder Mark keine Vorwürfe machen . Kleine Mängel am GUI habe ich auch schon direkt bei den ersten geh versuchen festgestellt , kann ich aber mit leben .

Markus2

Fr, Dez 15, 2006 13:49
Antworten mit Zitat

@Dreamora
das GUI von Windows war schon immer schlecht und
da kann man Simon oder Mark keine Vorwürfe machen .
Kleine Mängel am GUI habe ich auch schon direkt
bei den ersten geh versuchen festgestellt , kann ich aber mit leben .

	Dreamora	Fr, Dez 15, 2006 16:32 Antworten mit Zitat
War schon immer schlecht: Kann man drüber streiten. Eigentlich wäre es nicht so schlecht, gibt nur 2 Probleme: 1. MaxGUI basiert auf den BB+ sources, welche nie für OO ausgelegt waren, noch für Functionpointer etc 2. MaxGUI basiert auf BB+ sources, welche für Win98 ausgelegt sind. Das ist nicht sonderlich zeitgemäss. Um zu zeigen was ich meine: Auf OSX war BRL bereit, OSX 10.3 als mindestvoraussetzung einzuführen, damit sie schöne brauchbare UI elemente haben, unter Windows werden jedoch noch nicht Mal die XP API Elemente richtig ausgenutzt (worst case example ist das TextArea welches auf einer veralteten Richtext basiert), geschweige denn .NET oder sonst etwas was eigentlich aktuelle UIs unter Windows unterstützen sollten. (wem das net passt oder meint das hat eh niemand: Supreme Commander benötigt zb .NET 2 und installiert das direkt bei der eigenen Installation!). Das dürfte wohl auch mitverantwortlich für die Nicht-Nutzbarkeit für einige der UI Befehle unter Windows sein.
Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Dreamora

Fr, Dez 15, 2006 16:32
Antworten mit Zitat

War schon immer schlecht: Kann man drüber streiten. Eigentlich wäre es nicht so schlecht, gibt nur 2 Probleme:

1. MaxGUI basiert auf den BB+ sources, welche nie für OO ausgelegt waren, noch für Functionpointer etc

2. MaxGUI basiert auf BB+ sources, welche für Win98 ausgelegt sind. Das ist nicht sonderlich zeitgemäss. Um zu zeigen was ich meine: Auf OSX war BRL bereit, OSX 10.3 als mindestvoraussetzung einzuführen, damit sie schöne brauchbare UI elemente haben, unter Windows werden jedoch noch nicht Mal die XP API Elemente richtig ausgenutzt (worst case example ist das TextArea welches auf einer veralteten Richtext basiert), geschweige denn .NET oder sonst etwas was eigentlich aktuelle UIs unter Windows unterstützen sollten. (wem das net passt oder meint das hat eh niemand: Supreme Commander benötigt zb .NET 2 und installiert das direkt bei der eigenen Installation!). Das dürfte wohl auch mitverantwortlich für die Nicht-Nutzbarkeit für einige der UI Befehle unter Windows sein.

Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen.

Gehe zu Seite Zurück 1, 2

Übersicht

BlitzMax, BlitzMax NG

Beginners-Corner

Nach Oben

BlitzBasic Portal

Type erweitern mit anderem Type