Programmdesign, Variablen Zugriff von Formularen



  • Hallo,

    ich habe eine Frage zum Programmdesign. Folgende Aufgabe:
    In meinem Hauptformular habe ich verschiedene Variablen worauf das Hauptprogramm auch zugreift (z.B.fMain). Jetzt möchte ich diese Variablen in einem weiteren Formular (Optionen) ändern. Dabei sollten die Variablen auch erst geändert werden wenn ich einen OK Button betätige(ganz normal halt).
    Meine Lösung ist nun folgende:
    In meinem TForm des Hauptformulars deklariere ich im public Bereich die Variablen, in meinem Options Formular binde ich die Headerdatei mittels #include ein und fertig.
    Meine Überlegung ist jetzt ob ich das Ganze auch ohne einbinden der Headerdatei realisieren kann und auch ohne globale Variablen.

    Thomas



  • Original erstellt von <Thomas Fuchs>:
    In meinem TForm des Hauptformulars deklariere ich im public Bereich die Variablen

    Schau mal in der FAQ. Da hats einen Beitrag zum Thema "public-Variablen".

    Ohne inlcuden geht das ned. Ausser du sendest die Werte über eine Windows-Message....

    -junix



  • Hi,

    Meine Überlegung ist jetzt ob ich das Ganze auch ohne einbinden der Headerdatei realisieren kann und auch ohne globale Variablen.

    Nunja, das Einbinden von Headerdateien sollte wohl kaum ein problem darstellen.
    Die globalen Variablen müsste man überdenken.

    Sicherlich hat junix recht, was globale Variablen betrifft (Siehe FAQ). So ganz möchte ich das aber nicht alles über ein Kamm ziehen. Auch globale Variablen haben irgendwo eine Berechtigung. Application, um mal ein Beispiel zu nennen.

    Genauso macht man das ja eigentlich auch bei Spiele- Programmierungen. Die Umgebung ist innerhalb des Spiels für jeden gleich. Deshalb meist auch global.

    Ein Beipiel innerhalb von Klassen in der VCL wäre die Tag- Eigenschaft bei TComponent:

    __property int Tag = {read=FTag, write=FTag, default=0};
    

    Wenn man eine private Variable über properties ( ohne Verwendung von Set- und/oder Getfunktionen) veröffentlicht, sind diese ja auch nur nachhaltig globalisiert worden. Somit verwendet Borland hier und da auch globale Variablen.

    Das ist, meiner Meinung nach (ja junix, du bist anderer Meinung 😉 ) auch nicht falsch. Solange der Zugriff von Ausserhalb des Objectes kein Einfluss auf das Verhalten des Objectes hat. Das ist in der Regel aber eher seltener, weshalb ja auch eigentlich die globalen Variablen in Klassen vermieden werden sollen.

    Wie dem auch sei, generell sollte man ein Projekt so anfassen, das diese Probleme gar nicht erst auftreten.

    Einen Ansatz findet ihr zum Beipiel hier.

    [ Dieser Beitrag wurde am 20.02.2003 um 08:48 Uhr von AndreasW editiert. ]



  • Mein lieber Andreas. Ich habe über Globale Variablen noch gar nichts gesagt. Sie sollten zwar einfach vermieden werden aber das ist ein anderes Kapitel. Ich hab mich nur über Public-Variablen geäussert (-;

    __property int Tag = {read=FTag, write=FTag, default=0};
    

    Hier hast du recht. Ohne Set-Funktionen bringt die Ganze geschichte herzlich wenig. Allerdings muss man hier sagen, dass ein property nicht mit Public-Variablen vergleich bar ist, da es eine Public-Variable nur simuliert entscheide ich mich im späteren Verlauf des Projekts irgendwas an meiner private-Variable zu ändern (ein array daraus zu machen z.B.) dann kann ich read= und write= einfach auf zugriffsfunktionen zeigen lassen ohne dass der Anwender der Klasse etwas davon mitbekommt. Bei Public-Variablen ist dies _nicht_ der Fall!

    -junix


Anmelden zum Antworten