Haupt-Anwendungsfenster whlbar machen

Hallo in die Runde.
Bislang hatte ich bei meinen Anwendungen immer ein Hauptfenster, in dem sich fast alles abspielte. Jetzt möchte ich eine andere/erweiterte Variante anbieten.
Nichts leichte als das (dachte ich). Ich habe eine Variable “Ausgabefenster” als Window angelegt und im Open-Event dieser Variable das bisherige Fenster zugewiesen:
Ausgabefenster=new AusgabefensterStandard

Leider ist das doch nicht ganz so einfach :frowning:
Bislang (da hieß “AusgabefensterStandard” noch “Ausgabefenster” und es gab die Variable mit diesem Namen noch nicht) konnte ich auf die Methoden und GUI-Elemente zugreifen.

Jetzt funktionieren solche Aufrufe nicht mehr:
Ausgabefenster.Datensatzrefresch
Ausgabefenster.text(0).text=s
Ausgabefenster.Edit(22).SetFocus

Gibt es eine einfache Lösung?

Ich könnte im Ausgabefenster ein PagePanel anlegen und darüber umschalten. Das ist aber sicher nicht der Weisheit letzter Schluss.
Über Tipps würde ich mich freuen.

Gruß, Stefan Mettenbrink.

Variable AusgabeFenster als AusgabefensterStandard …

Ja, dann kann ich aber nicht auf ein anderes Fenster mit anderer Gestaltung wechseln:
Ausgabefenster=New AusgabefensterPro

Das soll ja schlussendlich der Sinn sein. Ich abe halt im gesamten Projekt haufenweise Zugriffe auf das Ausgabefenster. Die möchte ich jetzt nicht alle irgendwir umleiten. Darum wollte ich halt eine Variable, die ich einfach mit dem gewünschten Fenster belegen wollte.
Das habe ich wohl nicht gant offensichtch erklärt. Ich hoffe, man hat jetzt eher eine Vorstellung, was ich vorhabe.

Gruß, Stefan Mettenbrink.

Casting: AusgabefensterStandard( Ausgabefenster ).Datensatzrefresch

PagePanel wre einfacher.

Wenn ich die ganzen Stellen im Projekt in der Art ndern muss, ist das sicher nicht das, was ich mchte. Das hatte ich mir einfacher vorgestellt.

Hat noch jemand eine Idee?

Gru, Stefan Mettenbrink.

hem. Du solltest nicht so mit Deinen Fenstern reden. Das solltest Du ber Events oder Methoden machen.

Das mache ich doch.

Ich versuche es nochmal zu erkren.

Derzeit habe ich ein Hauptfenster mit dem Namen “Ausgabefenster”. Das hat diverse GUI-Elemente und Mehtoden. Aus vielen anderen Fenstern werden diese Methoden aufgerufen und auf Inhalte der GUI-Elemente zugegriffen:
Ausgabefenster.Datensatzrefresh
Ausgabefenster.text(0).text=s

Gibt es daran etwas auszusetzen?

Jetzt mchte ich bei Programmstart aus zwei verschiedeen Hauptfenstern whlen und stelle mir das so vor:

If Typ=“pro” then
Ausgabefenster = AusgabefensterPro
else
Ausgabefenster = AusgabefensterStandard
end

Die Methoden sind in beiden Fenstern vorhanden, verhalten sich aber ggf unterschiedlich (z. B. beim Datensatzrefresh)

Geht soetwas nicht?

Gru, Stefan Mettenbrink.

.DatensatzRefresh ist schon in Ordnung. Mach einfach alle Controls in den Fenstern private und schau, was passiert.

Für Deine Fenster wäre es wahrscheinlich am einfachsten, Du machst ein Interface für beide Fenster. Du kannst keinen Cast machen, weil Window kein .DatensatzRefresh hat.

Ich denke, dann passiert dasselbe, wie bei Umbenennung des Hauptfensters. Ich muss gut 1400 Stellen Code anpassen. Oder sollte ich etwas anderes erwarten (ich habe gerade keine Lust, 40 Methoden zu ndern)?

Nun ja, einen Tod wirst Du sterben müssen. Dann hört sich 40 doch besser an als 1400.

Na ja, wenn es nur die 40 Stellen wren.
Ich habe mal alle Methoden auf private gendert. Dann erhalte ich 1073 Fehler. Also etwa das, was ich schon zuvor erkannt habe. Sicher fehlen bei den 1073 Fehlern noch die Zugriffe auf GUI-Elemente und Timer im Hauptfenster.

OK, bleiben 14 Routinen, die ich global auslagern msste.
… und dieverse Zugriffe auf GUI-Elemente

[quote=396384:@Stefan Mettenbrink]Jetzt möchte ich bei Programmstart aus zwei verschiedeen Hauptfenstern wählen und stelle mir das so vor:

If Typ="pro" then Ausgabefenster = AusgabefensterPro else Ausgabefenster = AusgabefensterStandard end[/quote]
So weit, so gut.

Diese Zeilen sollten in einer app.Methode stehen, die von den bisherigen Stellen jeweils aufgerufen wird.
Dann schaut nur noch diese eine Methode nach, welches Fenster aktiv ist.

Ja, das funktioniert schon. Das Problem sind die vielen Programmstllen, die auf Elemente und Methoden von “Ausgabefenster” zugreifen. Die möchte ich halt nicht alle ändern müssen.

Nach Ändern der Methoden auf private bleiben dennoch 1302 Zugriffe auf das Hauptfenster. :frowning:

Beibt wohl nur die Variante mit dem PagePanel.
Oder hat noch jemand eine Idee?

Gruß, Stefan Mettenbrink.

Keine andere Idee, dann wird möglicherweise Pagepanel die beste lösung sein.

select case AusgabefensterStr case "Ausgabefenster","AusgabefensterStandard" AusgabefensterWndw.Pagepanel.value=0 case "AusgabefensterPro" //oder else AusgabefensterWndw.Pagepanel.value=1 end select
Den Code habe ich hier hinzugefügt, um auch Neu-Einsteigern wieder etwas zum Lesen zu geben.

Ja, so habe ich das in etwa gelöst.
Allerdings war das Hauptfenster bislang schon recht voll. Das wird jetzt noch mal deutlich mehr.
Übersichtlich ist anders :frowning:

Dann freu Dich schon mal auf Dein nchstes Refactoring-Projekt. So wie es sich anhrt, knntest Du Dich mit folgenden Sachen beschftigen:

  • alle Controls privat machen
  • mal mit Model/View/Controller beschftigen

Model/View/Controller hrt sich kompliziert an. Controller halte ich fr Xojo nicht so wichtig. Was wichtig ist, ist eine definierte Kommunikation zwischen dem View (Dein Fenster) und dem, was Deine App macht (das Model). Wenn Du dann ein Detail in Deinem Fenster nderst, kmmert das das Model nicht so wirklich.

Und ja, das macht immer Spa wie eine Wurzelbehandlung. Ich habe ein schnes Fenster fr Optionen. Historisch gewachsen, wie man so schn sagt, mit 3 Ebenen von Container-Controls. Das mu auch komplett neu gemacht werden.

+1 für MVC design pattern.

Leider habe ich das auch schon so gemacht wie Du oben beschreibst, d.h dass die Datenausgabe im User Interface eng mit der Programm-Logik verwoben wurde.

Wenn man das Programm dann ausbauen will, oder z.B auf eine mobile Lösung übertragen will, dann kann man sich entweder immer tiefer und tiefer verstricken, oder eben ein re-factoring in Angriff nehmen.

Z.B für die Datenausgabe ein Interface definieren und dann pro UI (Standard, Pro oder z.B. mobil) Klassen mi Methoden implementieren, welche Daten in ihre jeweiligen Controls übertragen, etc.

Im eigentlichen Programmcode verwendet man Methodenaufrufe des Interfaces und kümmert sich nicht mehr darum, ob das nun Mobil oder Desktop ist, Pro oder Standard.

Wie sagte mein alter Studienfreund „Snoopy“: Aus einem traurigen Arsch kommt nie ein fröhlicher Furz. Und aus Quick-und-Dirty wird nie ein solides Software Design.

Also: MVC und Interfaces

Ich kann eure Argumentation nachvollziehen. Auch wenn ich jetzt bereits bei Quick&Dirty bin, werde ich mir wohl oder übel mal grundlegende Gedanken machen müssen.
Da ich ohnehin reichlich zusätzliche Änderungen am Gesamtprojekt vorhabe, wäre das ein guter Grund mal neu anzufangen.

Wäre im Prinzip ein völlig neues Programm …

Ich hoffe, ich kann mich dazu aufraffen.