Fehler beim Aufrufen des 2. Fensters mit .show

Hallo zusammen,
ich möchte eine App schreiben, die über die serielle Schnittstelle Werte erhält. Die Einstellungen für den angeschlossenen Arduino und der “Startschuss” werden im Hauptfenster (WIndow1) vorgenommen. Zum Anzeigen und Plotten der Werte möchte ich ein neues Fenster öffnen (win). Dafür habe ich ein DisplayWindow mit einer Listbox und einem figure. Nun habe ich als globale Variable in einem Modul ein Fenster g_win vom Typ DisplayWindow angelegt. Wenn der Arduino zurückmeldet, dass er in den CTR-Modus geht, habe ich im DataAvailable-Event des Serial1-Moduls von Window1 g_win.show aufgerufen. Irgendetwas muss ich bei meinem 2. Fenster aber falsch gemacht haben, ich erhalte eine NilObjectException.

Kann jemand helfen?

Hast Du denn Dein Fenster mit new erzeugt?

Hallo Beatrix, danke für deinen Hinweis.
Nein, ich habe es nicht im Code, sondern über Modul -> Insert Property -> Name g_win erzeugt. Ich habe angenommen dass es dann automatisch “as new” ist? Wo muss das Fenster denn korrekter Weise anlegen? Im Open-Event der App?

Damit hast Du ja nur eine Property erzeugt, deren Wert ein Fenster ist, aber das Fenster selbst musst Du zur Laufzeit erzeugen (mit new) und der Property zuweisen – bis dahin ist ihr Wert nil. Wann Du das tust, ist Deine Entscheidung; Du kannst das Fenster auch erst dann erzeugen, wenn Du es brauchst.

Hallo,
wenn ich das richtig verstehe: g_win ist eine globale Variable vom Typ DisplayWindow in einem Modul.
Wenn das Fenster vom Typ DisplayWindow erscheinen soll, kann man es dann mit diesem Code erzeugen:

g_win = new DisplayWindow g_win.show

Macht doch bitte mal ein Feature Request das man bei einem Property wo eine Klasse angegeben ist und wenn man
bei Standard Wert den Klassen Namen oder New Klasse oder New angibt das Object erstellt wird.

[quote=470251:@Markus Rauch]Macht doch bitte mal ein Feature Request das man bei einem Property wo eine Klasse angegeben ist und wenn man
bei Standard Wert den Klassen Namen oder New Klasse oder New angibt das Object erstellt wird.[/quote]

Du meinst so, wie es bei einer Variablendeklaration möglich ist? Ich halte das für keine gute Idee. Bei einer Variablendeklaration in einer Methode weiß man genau, wann sie ausgeführt und damit das neue Objekt erzeugt wird, nämlich dann, wenn die Programmausführung an diese Stelle kommt. Eine Property-Deklaration ist aber keine Codezeile, die irgendwann zur Laufzeit ausgeführt würde, sondern bloß eine Anweisung an den Compiler. Man könnte zwar in solchen Fällen eine entsprechende Codezeile automatisch erzeugen, aber wo sollte die hin? Wann sollte sie ausgeführt werden? Man hätte keine Kontrolle darüber. Da ist es doch besser, man schreibt sie selbst – und weiß dann genau, was zu welchem Zeitpunkt passiert.

[quote=470253:@Michael Hussmann][/quote]
Da wo der Compiler den Standardwert für Strings oder Integer setzt da kann der auch ein Object erzeugen für die die es möchten.
Da passiert überhaupt nix schlimmes und ist das gleiche als wenn man es immer selbst irgendwo im Open Event einfügen muss.
Man ist ja quasi genötigt es zu erzeugen bevor man es überhaupt nutzen kann.
Wenn ich eine Eigenschaft z.B. in einem Fenster hinzu füge dann wohl weil ich die auch nutzen möchte
und sehr unwahrscheinlich im Open Event.
Zugreifen auf diese Eigenschaft geht ja auch erst wenn das Fenster Object erzeugt wurde.
z.B. Property Standardwert Nil oder New und alle sind glücklich.

Nee, das ist schon etwas völlig anderes. Wenn Du eine Zahl, einen booleschen Wert etc. als Default deklarierst, braucht der Compiler nur ein entsprechendes Bitmuster einzusetzen. Die Erzeugung eines Objekts ist eine völlig andere Nummer, denn dabei wird ja auch Code aufgerufen. Du kannst mir schon glauben, dass es ein Riesenunterschied ist und dass die Art und Weise, wie das in Xojo behandelt wird, ihren Grund hat.

Aber wenn Du es anders siehst, steht es Dir ja frei, das den Entwicklern mitzuteilen.

[quote=470257:@Michael Hussmann][/quote]
Ich behaupte mal das diese Xojo Basic Sprache eh in C++ übersetzt wird für einen der wenigen Compiler welcher mit Sicherheit nicht von Xojo stammt.

Das ist ein Implementationsdetail, das in diesem Zusammenhang keine Rolle spielt. Wir programmieren in Xojo, nicht in C++ oder in der Maschinensprache, die am Ende ausgeführt wird.

Relevant für die Xojo Erfinder wenn die so ein Feature einbauen würden …
Wie es umgesetzt wird ist mir ja eigentlich egal.