Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
NtuiCreator
#50
Ein paar sog. "Nit-Picks":

A) IT Sprache ist Englisch (ich weis, ich weis...)

B) Typos: "Menu" ("Menue" = Speisekarte), "Cancel", "Prepare"

C) Keine globalen Variablen. Zumindest nicht mit SHARED innerhalb einer Funktion, da man dann die weis, was man kriegt. Eine Ausnahme kann man mit dem App-Context machen, aber der sollte auch wirklich nur dort verwendet werden, wo man keine Wiederverwertbarkeit braucht (also Library API). Um den Effekt einer Funktion zu beeinflussen, hat man Parameter!

D) Am Ende eines "Select" sollte immer ein "Default" stehen, um sicher zu gehen nichts zu "verpassen". Im Falle des Notify Selects solltest du eine Fehlermeldung machen, z.B.
[ab3]...
Case "NCActive" ; <- ist mir gleich aufgefallen dass du das nicht testest!
Default:
error{"Unhandled notification: " + ntui_GetNotifyID{*Notify}}
End Select[/ab3]

E) Der-App Context besteht normalerweise aus drei Teilen:
1. Preferences (werden i.A. nur gelesen, schreiben darf nur eine Preferences-Funktion wenn man auf "Apply" drückt oder vom Icon/Configfile lädt.
2. State (da darf rücksichtslos geschrieben und gelesen werden, ist aber nicht Teil der Preferences (die gespeichert werden), sondern ausschliesslich Laufzeitinformationen. Der State sollte möglichst klein gehalten werden. (State-Automaten Hölle!)
3. Datenbank (dort werden die zu manipulierenden Daten verwaltet, idealerweise völlig unabhängig von der GUI, abgekapselt über eine API, damit man nicht an ein bestimmtes GUI System gebunden ist, und es lässt sich leicht ein Commandline Interface oder AREXX Schnittstelle bauen.

F) XML tags und parameter sind Case-Insensitiv. Z.B. schlagen deine Tests nach der Fenster ID fehl:
[ab3]tagname.s = _ntui_NextXMLTag{*tf}
If tagname = "Window"
...[/ab3]

besser:
[ab3]tagname.s = _ntui_NextXMLTag{*tf}
If lcase$(tagname) = "window"
...[/ab3]

G) Daten selbser parsen sollte man nicht. Da kann wahnsinnig viel schief gehen. Vielleicht entscheiden wir uns ja morgen für JSON als GUI definition, dann geht der Code nicht mehr.
Du kommst auf die Fenster einfacher indem du einfach die Engine durchsuchst.
[ab3]Statement creator_ShowAllWindows{*engine.tuiEngine}

*obj.tuiObject = ntui_GetChildObject{*engine}
While *obj
ntui_GetAttr{*obj, #TUIA_CLASSID, &classId.l}
If (classId = #TUICLASS_WINDOW)
ntui_ShowWindow{(.tuiWindow)*obj}
End If
*obj = ntui_GetNextObject{*obj}
Wend

End Statement[/ab3]

H) Die *engine für das Testen sollte eine andere sein als die Engine des NTuiCreators.
Dafür machst du einfach in creator_ShowWindow:
[ab3]If (creator\state\testEngine) Then ntui_Free{creator\state\testEngine}
creator\state\testEngine = ntui_BuildFromXMLMem{Null,*TextBox\doc\text}[/ab3]
Sonst kann dir die GUI den NTuiCreator zerschiessen, ausserdem willst du sie auch einfach wieder löschen können.

I) *TextBox\doc\text ist kein "legaler" Weg um an den Text zu kommen. Generell darfst du nicht auf die Newtypes zugreifen.
Du müsstest dir den Text holen mit
[ab3]ntui_GetAttr{*TextBox, #TUITBA_TEXT, &*textP.b}[/ab3]
Leider bekommst du derzeit nur die erste Zeile, ich werde das gleich ändern.

J) "ntui_Rethink" wird nur benötigt, wenn du eine *sichtbare" GUI manipulierst, also Objekte löschst oder hinzufügst. Wenn du nur ein Attribute änderst, musst du normalerweise nichts tun.

Habe dir den Code zurückgeschickt, am besten mal mit WinMerge o.ä. Tool diffen damit du siehst was ich geändert habe.
Zitieren


Nachrichten in diesem Thema

Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 5 Gast/Gäste