Haupt-Anwendungsfenster wählbar machen

  1. 8 months ago

    Stefan M

    14 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    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 :-(
    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.

  2. Markus W

    14 Jul 2018 Pre-Release Testers, Xojo Pro #JeSuisHuman Germany, Heidelb...

    Variable AusgabeFenster als AusgabefensterStandard …

  3. Stefan M

    14 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    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.

  4. Markus W

    14 Jul 2018 Pre-Release Testers, Xojo Pro #JeSuisHuman Germany, Heidelb...

    Casting: AusgabefensterStandard( Ausgabefenster ).Datensatzrefresch

    PagePanel wäre einfacher.

  5. Stefan M

    14 Jul 2018 Germany, NRW, Kirchlengern (Kr...

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

    Hat noch jemand eine Idee?

    Gruß, Stefan Mettenbrink.

  6. Beatrix W

    14 Jul 2018 Pre-Release Testers Europe (Germany)

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

  7. Stefan M

    14 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    Das mache ich doch.

    Ich versuche es nochmal zu erkären.

    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 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

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

    Geht soetwas nicht?

    Gruß, Stefan Mettenbrink.

  8. Beatrix W

    15 Jul 2018 Pre-Release Testers Europe (Germany)

    .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.

  9. Stefan M

    15 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    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)?

  10. Beatrix W

    15 Jul 2018 Pre-Release Testers Europe (Germany)

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

  11. Stefan M

    15 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    Na ja, wenn es nur die 40 Stellen wären.
    Ich habe mal alle Methoden auf private geändert. 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 müsste.
    ... und dieverse Zugriffe auf GUI-Elemente

  12. @StefanMettenbrink 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

    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.

  13. Stefan M

    16 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    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. :-(

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

    Gruß, Stefan Mettenbrink.

  14. Edited 8 months ago

    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.

  15. Stefan M

    17 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    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 :-(

  16. Beatrix W

    17 Jul 2018 Pre-Release Testers Europe (Germany)

    Dann freu Dich schon mal auf Dein nächstes Refactoring-Projekt. So wie es sich anhört, könntest Du Dich mit folgenden Sachen beschäftigen:

    • alle Controls privat machen
    • mal mit Model/View/Controller beschäftigen

    Model/View/Controller hört sich kompliziert an. Controller halte ich für 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, kümmert das das Model nicht so wirklich.

    Und ja, das macht immer Spaß wie eine Wurzelbehandlung. Ich habe ein schönes Fenster für Optionen. Historisch gewachsen, wie man so schön sagt, mit 3 Ebenen von Container-Controls. Das muß auch komplett neu gemacht werden.

  17. Oliver O

    18 Jul 2018 Pre-Release Testers, Xojo Pro https://udemy.seminar.pro

    +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

  18. Stefan M

    18 Jul 2018 Germany, NRW, Kirchlengern (Kr...

    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.

or Sign Up to reply!