Formübergreifend Variablen nutzen visual studio c# winforms?
Hi, ich möchte eine Variable in einer Form nutzen die ich in einer anderen Form Initialisiert habe geht das, und wenn ja wie danke schonmal!
2 Antworten
Da gibt es viele Möglichkeiten.
Im einfachsten Fall gehören alle diese Formen zu demselben Untertyp von "Form", dann kannst du die Variable als "static" definieren - so können alle Instanzen dieses Typs darauf zugreifen.
Im nächst einfachen Fall ist der Typ der Variable ein "Referenztyp" (in aller Regel ein "echtes" Objekt) und kann allen beteiltigten Formen direkt übergeben werden (im Konstruktor oder/und im Setter einer Eigenschaft).
Primitive Typen ("Werttypen") kannst du am einfachsten als "veröffentlichte Eigenschaft" ("public property") einer der Formen definieren und eine Referenz auf diese Form an die anderen Forms übergeben. Kaum weniger schwierig und gleichzeitig wesentlich übersichtlicher ist es, einen eigenen Typ als Träger (Carrier) dieser Variablen (und anderer Variablen, die in demselben Kontext verwendet werden) zu definieren.
In Programmiersprachen wie C und C++ verwendet man einfach einen Zeiger auf die betreffende Variable. Das ist in C# auch möglich, aber im Fall von primitiven Typen nur für Fortgeschrittene zu empfehlen (C# kennt zwar Zeiger, "schämt" sich dessen aber).
Wenn die Variable auch geändert werden kann - und wenn auch nur von ihrer eigenen Form -, muss noch auf "Threadsicherheit" geachtet werden. Aber wenn du davon noch nichts gehört hast, kannst du davon ausgehen, dass es dich nicht betrifft (d. h. die gesamte Anwendung verwendet aus Programmierersicht nur einen einzigen Thread).
-----
Wenn diese Variable zu einer ganz bestimmten Form gehört und du von anderen Objekten (insbesondere Forms) aus darauf zugreifen willst, ist das beste, diese Variable als Eigenschaft der zugehörigen Form zu definieren. (Dabei kannst du dann auch festlegen, ob nur Lesezugriff oder auch Schreibzugriff gewährt werden soll.)
Was Klassenmember (static) betrifft, bin ich nicht ganz der Auffassung, dass die für ein heilloses Durcheinander sorgen. Eine eigene Klasse (oder Struktur), die solche Variablen zusammenfasst, ist natürlich in jedem Fall wesentlich übersichtlicher.
nur für Fortgeschrittene zu empfehlen
Es ist gar nicht zu empfehlen.
Da hast du natürlich vollkommen recht. Ich habe versäumt, mir das noch einmal durchzulesen. Wenn ich das getan hätte, hätte ich etwas geschrieben wie
Aber solche "Kunststückchen" lassen sich allenfalls für sehr fortgeschrittene Anwender für sehr spezielle Anwendungsfälle rechtfertigen.
Danke, dass du dies klargestellt hast.
Was Klassenmember (static) betrifft, bin ich nicht ganz der Auffassung, dass die für ein heilloses Durcheinander sorgen. Eine eigene Klasse (oder Struktur), die solche Variablen zusammenfasst, ist natürlich in jedem Fall wesentlich übersichtlicher.
Meine Aussage bezog sich hauptsächlich auf den Kontext eines unerfahrenen Programmierers.
Ich verwende auch static, lange nicht so oft, wie Instanz-Member, aber oft genug.
Der Knackpunkt ist aber, wofür ich das verwende und jemandem, der wenig bis keine Erfahrung hat, gebe ich gerne die Regel mit, kein static zu verwenden, da man so weniger falsch machen kann.
So zumindest meine Erfahrung.
Z.B. habe ich schon häufiger Projekte gesehen, wo die gesamte Kommunikation innerhalb der Anwendung statisch ablief und das hat dann auch immer zu Chaos geführt.
Das ist der effektivste Weg, um sich ein heilloses Chaos heran zu züchten.
Es ist gar nicht zu empfehlen.
Fast alle Anwendungsfälle für Pointer hingen mit p/invoke zusammen. Außerhalb dieses Anwendungsbereich's habe ich es nur sehr selten in einem vernünftigen Anwendungsfall gesehen.
Auch wenn ich den Begriff "Carrier" in diesem Kontext noch nie gehört habe, ist das der übliche Weg, so arbeiten ja auch alle gängigen Design-Pattern.
Man könnte natürlich auch eine Referenz auf Form A nach Form B hinein geben (das deutest Du glaube ich auch an), allerdings dürfte das auch relativ schnell zu Chaos führen. Die "Zwischen-" oder "Carrier-"Klasse ist da der bessere Weg. Wenn man das ganze noch vernünftig benennt und beide Klassen die Referenz darauf von außen (durch den Konstruktor) hinein gegeben bekommen (Stichwort: Dependency Injection), ist man schon auf dem richtigen Weg.
Aber klar sind das keine Themen für einen Anfänger. Aber so ist das, wenn man als Anfänger mit Frameworks für Fortgeschrittene arbeitet, dann braucht man sich nicht wundern ^^