|
| |
VB.NET - Ein- und Umsteiger| Re: Auf Form von Komponente zugreifen | |  | | Autor: keco | | Datum: 09.06.09 23:30 |
| Ich habe eben nachgeschaut, was genau ich mache um es so gut wie möglich zu beschreiben, dabei ist mir aufgefallen, dass ich das gar nicht brauche.
Aber was ich vor habe: Ich habe eine Friend-Class
Private Shared pItems As New Generic.Dictionary(Of MyObject, _
MyObjectCollection)
Public Shared ReadOnly Property Items(ByVal compControl As Settings) As _
MyObjectCollection
Get
If Not pItems.ContainsKey(compControl) Then
pItems.Add(compControl, New MyObjectCollection)
End If
Return pItems(compControl)
End Get
End PropertyUnd jede Komponente hat nun eine Eigenschaft, die eine Auflistung hat, nämlich MyObjectCollection. Allerdings werden eben alle MyObjectCollection der Komponente in dieser Friend-Class im Dictionary verwaltet. Damit erreiche ich, dass ich in jeder Form nur die entsprechende Collection erhalte und nicht die, von allen. Aber ich habe gemerkt, dass ich nicht die Form brauche, sondern die Komponente selbst. Ich bin durcheinander geraten, weil es ich anfangs anders versucht hatte.
Danke für deine indirekte Hilfe ;) | |
| Auf Form von Komponente zugreifen | | | | Autor: keco | | Datum: 09.06.09 21:55 |
| Hallo,
ich habe mir eine Komponente geschrieben, die im Designer einer Form in der unteren Leiste vorhanden ist. Wie kann ich aus dieser Komponente auf die Instanz der Form zugreifen, die diese Komponente beinhaltet? | |
| Re: Auf Form von Komponente zugreifen | | | Autor:  FZelle (Moderator) | | Datum: 09.06.09 23:11 |
| Garnicht, solltest du auch niemals tun.
Was willst Du denn erreichen? | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 10.06.09 09:35 |
| Es muss schon einen Trifftigen Grund geben, soetwas absolut OOP Unkonformes, und aus den
tiefen von VB6 kommendes zu fabrizieren. | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: keco | | Datum: 10.06.09 14:55 |
| | Ich verstehe nicht so ganz. Ich habe eine Komponente, die eine Collection von Objekten speichert. Diese Objekte sollen das Verhalten einer Form bestimmen. Ich ziehe also diese Komponente auf meine Form, füge dort im Designer ein paar Objekte der Liste hinzu um somit ein bestimmtes Verhalten festzulegen. Diese Collection wird dann in einer Friend-Class abgespeichert in einem Dictionary(Of TKey, TValue), damit ich den Inhalt der Collection in einer Datei abspeichern kann. Und das ganze eben für jede Form einzeln. Irgendwie muss ich ja die ganzen Objekte in der Gesamtheit verwalten, daher mache ich das. Und die Instanz der Komponente dazu, damit ich die Werte des Dictionary eindeutig zuordnen kann. Wieso sollte das OOP unkonform sein? | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 10.06.09 16:27 |
| Deine Friendklasse, die dieses Dictionary als Shared Property hat, ist vollkommen OOP Unconform.
Du erzeugst abhängigkeiten, die vollkommen unnötig sind.
Zumal es mit IExtenderProvider etwas gibt, das genau das macht, was Du eigentlich machen willst.
Du kannst dadurch Form/UserControlweit alle z.b. Einstellungen verwalten.
Wenn du dann noch den einzelnen Views ein Interface mitgibst das diese nach aussen führt,
ist der rest schnell OOP Konform erledigt. | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: keco | | Datum: 10.06.09 16:32 |
| | Ich hatte es mit dem IExtenderProvider versucht, aber bin zu keinem Ergebnis gekommen, zumindest nicht zu dem, was ich wollte. Ich weiß nicht, wie ich dann all diese Objekte von allen Components abrufen soll um diese in eine Datei zu schreiben, bzw. wieder zu laden. Hast du dafür ein kurzes Beispiel? | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 10.06.09 18:01 |
| Manchmal ist das was man will, nicht das was man machen will.
Auch deine Ausführung um 14:55 ist nicht so ganz schlüssig.
Willst Du jetzt nur Einstellungen speichern, oder Verhalten?
Tu mal so, als wenn wir nicht wüssten, was du machen willst, und erklär was Du machen willst,
nicht wie Du meinst das lösen zu wollen. | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: keco | | Datum: 10.06.09 18:35 |
| Okay, also ich möchte eine DLL schreiben, womit ich Anwendungseinstellungen verwalten kann. Ich habe eine Component, die speichert eine Auflistung von Objekten. Diese sehen so aus:
Public Class Setting
Implements INotifyPropertyChanged
Public Event PropertyChanged(ByVal sender As Object, ByVal e As _
System.ComponentModel.PropertyChangedEventArgs) Implements _
System.ComponentModel.INotifyPropertyChanged.PropertyChanged
Private pAttributes As AttributeCollection
Private pBindingControl As Control
Private pBindingProperty As String
Private pCategory As String
Private pName As String
Private pValue As String
' ... Hier natürlich die Properties
End ClassDiese Objekte speichern also eine einzelne Eigenschaft eines einzelnen Controls. In jeder Component kann ich also die Eigenschaften eines Control einer Form in die Liste aufnehmen. Diese Liste kann also gespeichert werden und auch wieder geladen werden, wodurch die Eigenschaften der Controls automatisch gesetzt werden, mit denen aus der Datei. Mit nur einer einzigen Component würde ich das prima hinbekommen, dann könnte ich die Collection direkt in der Component verwalten, aber daher, weil mehrere Forms diese Component haben können, um die Eigenschaften von Controls dieser Form zu speichern, wirds schon komplizierter. Ich möchte also Eigenschaften von Controls speichern und wieder laden können. Allerdings für die gesamte Anwendung und nicht nur einer Form. Ich hoffe das reicht so an Informationen.
Jetzt also die Frage: Wie verwalte ich die gesamten Einstellungen, um sie effektiv speichern und wieder laden zu können? | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 11.06.09 09:40 |
| Jedenfalls nicht indem du Controls mit der Fähigkeit ausstattest dies selbst zu tun.
UserControls sind einzig und alleine dazu da irgendwelche Daten Anzuzeigen oder deren
Bearbeitung zuzulassen.
Oder greift ein DataGridView selbständig auf eine DB zu?
Für das laden/speichern dieser Daten, und sei es deren Zustände ist der Container zuständig
der das Control letzlich hostet.
Wenn Du es vernünftig machst, dann hast Du etwas wie MVC/MVP/MVVM implementiert,
oder zumindest ja eine Form.
Diese ist dafür zuständig den einzelnen UC ihre Daten zuzuführen, oder deren Daten
zu speichern.
Um dies zu vereinfachen erstelle ein Interface z.b. ISettingsReceiver das die Funktionen
GetSetting, SetSettings hat, und evtl eine eindeutigen ID zurückgibt ( kann zwar auch der name sein,aber...)
Dann kannst Du einfach in einer rekursiven schleife durch den ControlContainer deiner Forms gehen
und Settings Lesen oder schreiben.
Dies kannst Du auch in einer "GrundForm" erledigen, die du ja sowieso haben wirst, um dein
"Corporatedesign" nicht immer neu machen zu müssen.
Wenn Du dann per IOC/DI einen systemweiten Service hast, der das lesen/schreiben dieser Einstellungen
vornimmt, ist alles OOP Conform erledigt.
Wenn Du etwas grösseres schrieben willst ( und danach hört es sich an ) solltest Du dir
dringend solche Sachen wie MVP/MVC und DI/IOC anschauen, sie erleichtern die Arbeit ungemein. | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: keco | | Datum: 11.06.09 16:55 |
| Danke für deine Ausführungen, das mit dem DataGridView ist ein gutes Argument. Ich wollte das ganze eben so machen, um den Anwender, der das ganze dann verwendet, keine Codezeile mehr schreiben muss, also um die Verwendung zu vereinfachen.
Ansonsten sind mir die ganzen Abkürzungen noch unklar, somit wahrscheinlich auch dein Gedanke, wie ich das richtig machen könnte, oder ich habe es einfach so noch nicht ganz verstanden.
Also die Sache mit dem Interface ist soweit klar, aber was danach kam habe ich nicht verstanden. Vielleicht könntest du das noch etwas erläutern. Ich werde mir auch erstmal anschauen, was denn diese ganzen Abkürzungen sind und wie das funktioniert, was dahinter steckt, wenn du meinst, dass es dadurch einfacher wird und auch der OOP entspricht. Ich danke dir erstmal. | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 12.06.09 11:40 |
| Unity als Leichtgewichtig zu bezeichnen ist schon gewagt.
Leichtgewichtig wäre z.b. Hiro | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: keco | | Datum: 13.06.09 12:34 |
| Danke noch für die Hinweise. Bisher habe ich mir verschiedene Quellen bezüglich MVC/MVP Patterns durchgelesen, unter anderem auch diese. Interessant, schon wegen den anschaulichen Diagrammen. Aber so wirklich habe ich das noch nicht verstanden, inwiefern diese Methode(n) sehr viel einfacher und vorallem auch so häufig gelobt wird.
Bei dem IoC/DI habe ich mich noch nicht so intensiv eingelesen, aber scheint mir sehr viel mehr Aufwand zu sein, bei dem groben Überblick, den ich hatte, durch diese weitere Anwendung (ist es das überhaupt?), die ich brauche. Bei der Suche nach IoC/DI bin ich auch des öfteren auf Unity gestoßen, scheint also auch beliebt zu sein.
Kennt denn noch jemand eine Seite mit ausreichend Informationen, die einen guten Einstieg geben, vorzugsweise deutsch? | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 13.06.09 14:46 |
| Es hat niemand davon geredet das es einfacher wird, es wird einfacher Wartbar, das ist ein grosser Unterschied.
Und DI/IOC Container ist keine Anwendung, es ist einfach eine Lib die dir DI, also das injekten
von konkreten Objekten in Konstruktoren oder öffentlichen Properties erleichtert.
Unity ist deswegen "beliebt" weil es zur EnterpriseLib von MS gehört.
http://www.dotnetspark.com/kb/267-di-using-unity-application-blocks.aspx | |
| Re: Auf Form von Komponente zugreifen | | | | Autor: FZelle (Moderator) | | Datum: 14.06.09 13:50 |
| Sehe ich genauso, nicht alles muss portable sein.
Nur wenn man mal angefangen hat den Sinn und Zweck von Interfaces und damit die Entkoppelung
der einzelnen Programmteile zu seinem Vorteil auszunutzen, dann wird es in der Tat einfacher.
Gerade wenn es dann um Unittest und Co geht, ist Implementierung gegen Interfaces ein muss.
Und wenn ich im nachhinein entscheide, das ein Repository z.b. ein Singleton werden soll, statt
einer UnitOfWork, dann muss ich nicht alles durchgehen, sondern kann das Zentral steuern. | |
 | Sie sind nicht angemeldet!
Um auf diesen Beitrag zu antworten oder neue Beiträge schreiben zu können, müssen Sie sich zunächst anmelden.
 Einloggen | Neu registrieren |
 |
|
sevZIP40 Pro DLL 
Zippen und Unzippen wie die Profis!
Mit nur wenigen Zeilen Code statten Sie Ihre Anwendungen ab sofort mit schnellen Zip- und Unzip-Funktionen aus. Hierbei lassen sich entweder einzelnen Dateien oder auch gesamte Ordner zippen bzw. entpacken. Weitere InfosTipp des Monats Access-Tools Vol.1 
Über 400 MByte Inhalt
Mehr als 250 Access-Beispiele, 25 Add-Ins und ActiveX-Komponenten, 16 VB-Projekt inkl. Source, mehr als 320 Tipps & Tricks für Access und VB
Nur 24,95 EURWeitere Infos
|
Mai 2024
Sie sind aktuell nicht angemeldet.