dotnet:Komponente in einem anderen Formular ansprechen

[Rainer Wolff]

Hallo,

obwohl eingefleischter Delphianer, bin ich trotzdem dabei, mal zu schauen, wie der Mitbewerber dotnet so funktioniert. Und da sicherlich einige hier im Forum auch zusätzlich mit dotNet arbeiten, frage ich mal neugierig:

In Delphi kann ich bequem im Objektinspektor auf Komponenten in anderen Formularen zugreifen, sobald ich das Formular in die uses-Klausel aufgenommen habe (z.B. vom DBGrid im Formular auf die Datasource im Datenmodul).

Wie geht so was in dotNet? Die Datenanbindung funzt ja dort über das Dataset, auf das ich auch aus allen Formularen zugreifen kann.

Aber ich will versuchsweise meine eigenen Komponenten nach dotNet übertragen, und da habe ich auch eine "Masterkomponente", die von mehreren Clientformularen angesprochen wird.
Klar kann ich das ganze in dotNet im Quelltext verknüpfen, aber ich möchte das ganze genauso bequem per Mausklick konfigurieren wie in Delphi. Und da taucht halt meine Masterkomponente aus Formular 1 nicht in der Clientkomponente in Formular 2 auf, wenn ich im Objektinspektor klicke.

Da mir Google nicht helfen konnte (wahrscheinlich fehlen mir nur die richtigen Suchstichworte), hoffe ich, hier kann mir jemand helfen.

Gruß Rainer

[Khabarakh]

Zitat:

Zitat von Rainer Wolff

Und da taucht halt meine Masterkomponente aus Formular 1 nicht in der Clientkomponente in Formular 2 auf, wenn ich im Objektinspektor klicke.

Wie soll das denn funktionieren, wenn Formular 1 mehrfach instantiiert wird? Das geht in Delphi doch nur durch diese merkwürdigen globalen Form-Singletons.
Selbst im Code kannst du mit den Standardeinstellungen nicht auf Komponenten anderer Forms zugreifen, .NET meint es ernst mit der Kapselung ;) . Subforms sollten komplett unabhängig von ihrem Parent sein.

[Rainer Wolff]

Zitat:

Zitat von Khabarakh

Wie soll das denn funktionieren, wenn Formular 1 mehrfach instantiiert wird? Das geht in Delphi doch nur durch diese merkwürdigen globalen Form-Singletons.
Selbst im Code kannst du mit den Standardeinstellungen nicht auf Komponenten anderer Forms zugreifen, .NET meint es ernst mit der Kapselung ;) . Subforms sollten komplett unabhängig von ihrem Parent sein.

An der Stelle sind diese merkwürdigen Form-Singletons aber recht angenehm zu benutzen, finde ich, Kapselung hin oder her. Formular 1 ist eben ein Singleton, das muss mir schon klar sein, wenn ich das einsetze.
Aber dann mal schnell alle Komponenten auf Formular 2 markieren, Komponenten.Masterkomponente im Objektinspektor auf Formular1.Masterkomponente setzen, damit komm ich sehr gut zurecht, ohne mir über CleanCode zuviel Gedanken zu machen.

Und ganz klar ist mir an der Stelle jetzt auch nicht, wo der wesentliche Unterschied zu den Datasets von .Net liegt, die auch in mehreren Formularen verwendet werden können, das sind doch auch Singletons. Ich würde ja auch meine Masterkomponente(n) so in der Richtung Dataset einbauen, wenn ich wüßte, wie man das in .Net macht.

Aber momentan kenn ich mich ja mit .Net soviel aus, dass ich für das simpelste StrToInt erst mal ein Buch zur Hand nehmen muss.

[Khabarakh]

Zitat:

Zitat von Rainer Wolff

Kapselung hin oder her.

Wenn es darum geht, ob ich lediglich einen weiteren Konstruktor-Parameter hinzufügen muss, nehme ich lieber "hin" :) . Ich weiß nicht genau, was für ein Beispiel du gerade im Kopf hast, aber spätestens mit WPF/Silverlight würde es wahrscheinlich sowieso wieder komplett anders gelöst werden :stupid: .

Zitat:

Und ganz klar ist mir an der Stelle jetzt auch nicht, wo der wesentliche Unterschied zu den Datasets von .Net liegt, die auch in mehreren Formularen verwendet werden können, das sind doch auch Singletons.

So würde ich nur etwas mit einer global registrierten Instanz bezeichnen, aber keine Instanz, die von lose gekuppeltem Code von Komponente zu Komponente gereicht wird. Aber DataSets sind (.NET-unabhängig) doch sowieso nur eine Überbrückung, bis man mit O/RMs richtig loslegen kann ;) .

Zitat:

Aber momentan kenn ich mich ja mit .Net soviel aus, dass ich für das simpelste StrToInt erst mal ein Buch zur Hand nehmen muss.

In dem steht hoffentlich nicht Convert.ToInt32 :D .

[Phoenix]

1.) DataSets in .NET sind langsam. Insbesondere die typisierten. So langsam und so speicherfressend, dass man sie besser nicht (also gar nicht) einsetzt.

Datenzugriff in .NET läuft inzwischen besser via LINQ 2 SQL oder via Entity Framework. Oder, wenn man viel Doku lesen mag, über nHibernate. Oder, wenn man Geld ausgeben mag, über andere O/R Mapper.


2.)

Code:

var myInt = Int32.Parse("123"); // wirft ne exception wenn der String kein Int ist

oder

Code:

int myInt;
if (Int32.TryParse("12 Hallo", out myInt)
{
  // dosomething with int
} else {
  // hier hat MyInt den Default-Wert (0), es wird keine Exception geschmissen
}

;-)