Ntui : Windowid erhalten

[Blackbird]

Hallo,

Folgendes Szenario:

In meinem Source lade ich per BuildFromXMLFile eine Windowbeschreibung.xml nach/oder lese sie ein...

Wie bekomme ich nun die NameID des geladenen Windows zum Anzeigen raus ?
Ich habe schon [ab3]ntui_GetAttr{*engine,#TUIA_ID,&windowname.s}[/ab3] probiert, aber das funktioniert nicht,
sondern erfüllt nur den Zweck das es crasht :o

[Der Wanderer]

Das crashed weil der Stringbufer überschrieben wird mit dem Pointer auf den String.
Hätte AB3 richtiges Typechecking würde dir das sofort auffallen.

So wäre das richtig:

[ab3]If ntui_GetAttr{*engine,#TUIA_ID,&*stringP.b}
If *stringP Then engineID.s = Peek.s(*stringP)
EndIf[/ab3]

Das gibt dir aber die ID der engine.

Was du willst ist

[ab3]*mywin.tuiWindow = (.tuiWindow)ntui_GetObjectByID{*engine,"myFunkyWidnow"}

; oder, falls du wirklich nur nach einem Fenster suchst
; oder die instanceID brauchst (hier 1234, falls du mehrere Fenster mit der gleichen ID erzeugst):

*mywin.tuiWindow = ntui_GetWindowByID{*engine,"myFunkyWindow",1234}[/ab3]

... und im XML

Code:

<window id="myFunkyWinodw">...</window>

Anmerkung:

Die Core Funktionen von NTUI benutzen nie BlitzBasic Strings, sondern ausschliesslich Pointer auf Null-terminierte Character Arrays.
Das ist zwar etwas umstaendlicher, aber kompatibel mit anderen Programmiersprachen wie C.
Fuer die BlitzBasic Anbindung gibt es einige Convenient Stubbs, wie z.B. ntui_GetStringByID. Das ist eigentlich keine NTUI Funktion sondern ein Stubb fuer ntui_GetAttrByID{...,#TUIA_STRING,...}.

[Blackbird]

Ah ja prima, danke !

Wenn das klappt, dann gibts evtl. bald was zum rumprobieren

Eines noch, wenn in der Windowbeschreibung die ich dazu lade zuerst ein Eintrag mit der <engine> steht, dann funktioniert das bestimmt nicht oder ?
Weil dann ja eine neue engine erzeugt wird und das anschließende Window dort erzeugt wird anstatt in der bestehenden Engine oder täusche ich mich da ?

Wenn nicht, wie bekomme ich dann den Engineeintrag weg ?

[Blackbird]

Nachdem ich nochmal darüber nachgedacht habe, sind deine Lösungsvorschläge nicht für mein Vorhaben geeignet....

dein [ab3]*mywin.tuiWindow = (.tuiWindow)ntui_GetObjectByID{*engine,"myFunkyWidnow"}[/ab3]
funktioniert natürlich, keine frage....aber da ist der Windowname schon festgelegt/bekannt...
Ich will das aber variabel haben !

Ich denke mal ich brauche da einen Platzhalter für den Windownamen und muß da irgendwie beim erzeugen/laden das xmlfile
auslesen...

Toll wäre da eine funktion ala xxx_GetXMLWindowname{} oder so ähnlich :?
oder gibts sowas gar schon in der xml.include ???? gleich mal schauen

[Der Wanderer]

Nein, so funktioniert das nicht.

IDs sind normalerweise alle zur Compilezeit bekannt.
Warum willst du die ID variabel haben? Du kannst natürlich eins nach dem anderen erzeugen und die ID setzen, aber dafür ist eigentlich die instanceID gedacht.
Was hast du denn genau vor, dann kann ich dir die richtige Vorgehensweise erklären. NTUI ist eigentlich relativ ähnlich zu Android GUI, nur dass ich die IDs nicht in den Source direkt einkompilieren kann, das geht nur wenn das IDE NTUI fest mit der Sprache verbindet, aber dann würde das nicht mit anderen Sprachen und IDEs funktionieren.

[Blackbird]

Warum willst du die ID variabel haben?

Ganz einfach, damit ich verschiedene xmlfiles einladen kann. Damit die Windows nicht alle "Mainwindow"
heisen müßen und damit ich verschiedene Fenster per Show anzeigen und auch wieder schließen kann.

Da stellt sich mir auch gerade noch die Frage: Wenn ich dann in der Textbox was editiere und mir dann das
auch gleich anzeigen lassen will, was ist da besser. Das Fenster schließen per Free und neu einlesen.
Oder das Fenster per Hide verstecken und neu einlesen ?

Was hast du denn genau vor, dann kann ich dir die richtige Vorgehensweise erklären.

Eigentlich wollte ich das noch nicht preisgeben bis es richtig funktioniert, aber was solls...

Mich hat bei der erstellung einer Gui bis dato immer etwas angestunken das ich beim schreiben einer
neuen Gui nicht auch gleich mal nur so zum überprüfen sehen kann was ich da zusammenschuster.

Deswegen kam mir da die glorreiche Idee mir einen kleinen NtuiCreator zu schreiben (ich weis das hast
du alles selbst vor, aber du kannst dich auch nicht zerteilen)

Im Moment sieht das so aus:
[ATTACHMENT NOT FOUND]

Wenn ich dann eine Datei einlade, oder per windrop ins Fenster schmeise so:
[ATTACHMENT NOT FOUND]

Da sieht man schon das es nicht so passt wie ich das mache, denn es fehlen die Scroller....

Wenn ich dann einen zweiten text wieder lade/oder windrop mache:
[ATTACHMENT NOT FOUND]

Der Text der im Reiter fehlt, hatte ich zwar gestern noch drin, aber das passt nicht !
Ich hatte per ntui_SetAtttrByID den Titeltext für die Gruppe gesetzt, was auch funktioniert hat,
aber da gibts ein Problem mit der Gruppe, denn nach einmaligen hin und herschalten sieht das dann so aus:

Sorry liefere das Bildchen nach, weil das Forum leider nicht mehr als 3 Anhänge erlaubt :roll:

Auf jeden Fall funktioniert bis jetzt das einladen per Requester
Das einladen per Windowdrop...
Das abspeichern...
Das abspeichern mit neuem Pfad und Namen...
Das Anzeigen und schließen...

[Blackbird]

Hier noch das letzte Bildchen:
[ATTACHMENT NOT FOUND]

Wenn man genau hinschaut, kann man schon im zweiten Bildchen im obigen Post erkennen das der Test.xml Text schon vorhanden ist hinter
der Textbox, da schaut das Bildchen vom AISS schon ein stückchen hervor...

[Blackbird]

Nein, so funktioniert das nicht.

so nicht, aber geht nicht, gibts nicht... :twisted:

Hab mir einen Routine geschrieben die das einzuladende xmlfile durchparst und die entsprechenden Attribute
dann ausspuckt...

Den Source zeige ich jetzt aber lieber mal nicht, denn sonst springst du wieder im Dreieck wegen deinen als
privat gekennzeichneten Befehlen :o

[Blackbird]

Ne Idee warum der Text nicht nur im Reiter erscheint sondern auch in der Group ?

Und warum sind keine Scroller in der ersten Textbox die ich im xmlfile definiert habe ?
[ab3]<TextBox id='SourceBox0' onKey='TextChange'/>[/ab3]

das sind bis jetzt die einzigen zwei Dinge die nicht so funktionieren wie gedacht....

[Der Wanderer]

1. Weil das nicht ganz saube rimplementiert ist. Der Group Title ist auch gleichzeitig der Reiter Text. Du darfst der aussersten Gruppe keine Border geben, also bordertype="none". Eigentlich bräuchte man dafür verschiedene Strings, hast ja recht...

2. Die Scroller erscheinen nicht weil das Auto-Scroller Dingens noch nicht implementiert ist. scrollermode="always" sollte das fixen

Das was du da implementierst ist aber unnötig. AIDE hat ja schon alles was du da implemnetierst, bis auf den Preview.
Fuer den GUI Builder ist es in der tat etwas schwerer, weil die GUI ja nicht zur Compilezeit bekannt ist.

Ein paar Regel:
1. Du solltest eine neue Engine anlegen (passiert automatisch, siehe 2.)für die user GUI. NICHT die des Builders nutzen, da das XML die Engine beeinflussen kann und das willst du nicht.
2. als Parent Object im BuildXML gibst du NULL an. Dann wird entweder die Engine genutzt die im XML zu finden ist, oder eine Default Engine angelegt.
Wenn du bereits ein Parent Object angibst, dann wird keine neue Engine angelegt sondern die vorhandene manipuliert, falls neue Attriute gesetzt werden.

Die GUI Elemente darfst du ganz legal durchstöbern mit
[ab3]; get the child object
Function.tuiEngine ntui_GetEngine{*obj.tuiObject}

; get the child object
Function.tuiObject ntui_GetChildObject{*obj.tuiObject}

; get the next object in the tab-cycle chain
Function.tuiObject ntui_GetParentObject{*obj.tuiObject}

; get the previous object
Function.tuiObject ntui_GetPrevObject{*obj.tuiObject}

; get the next object
Function.tuiObject ntui_GetNextObject{*obj.tuiObject}[/ab3]

Die Class bekommst du per #TUIA_CLASSID. Die benachbarten Objects kannst du natuerlich auch per Attibuts erfragen, die o.g. Funktionen sind nur Helferchen.

#TUIA_NEXTOBJECT = 90 ; r (*obj) pointer to next object in hirarchie
#TUIA_PREVOBJECT = 91 ; r (*obj) pointer to previous object in hirarchie
#TUIA_PARENTOBJECT = 92 ; r (*obj) pointer to parent object in hirarchie
#TUIA_CHILDOBJECT = 93 ; r (*obj) pointer to child object in hierarchie
#TUICLASS_ENGINE = 2 ; /* an engine with ports, windows etc, usually one per app */