Was ist der Stand der Dinge mit "Visual Inheritance"?

8

Wir haben eine Anwendung, die flexibel sein muss, wie sie ihre Hauptform für den Benutzer anzeigt - abhängig vom Benutzer sollte das Formular etwas anders sein, vielleicht eine zusätzliche Schaltfläche hier oder dort oder eine andere Nuance. Um den Code nicht mehr zu schreiben, um Steuerelemente explizit zu entfernen oder hinzuzufügen, wandte ich mich der visuellen Vererbung zu, um das Problem zu lösen - was ich für einen sauberen, sauberen und logischen OO-Stil hielt - dass die Hälfte der Zeit vererbte Formulare schwer haben sich selbst in VS zu replizieren ohne guten Grund usw. - und ich habe das Gefühl, dass Entwickler und teilweise Microsoft die Praxis der visuellen Vererbung gemieden haben - können Sie das bestätigen, fehlt mir hier etwas?

Grüße.

    
Vidar 08.09.2008, 10:58
quelle

6 Antworten

6

Ich dachte, sie hätten 2005 mehr oder weniger Probleme mit dem Desktop-Designer gelöst. Hast du die üblichen Täter ausprobiert?

  • Keine abstrakten Steuerelementtypen
  • Keine Konstruktorargumente in irgendeiner Form
  • Die Initialisierung wurde im Gegensatz zum Ctor
  • nach Form_Load verschoben
  • Keine Steuerelemente im selben Projekt wie das Benutzersteuerelement / Formular, in das sie eingefügt werden
  • Alle Dokumente schließen - & gt; Reinigen - & gt; Erstellen Sie
  • neu
  • VS neu starten

Ich schien zu denken, dass, solange Sie das alles oben getan haben, es meistens funktionierte.

    
Quibblesome 08.09.2008, 11:43
quelle
3

Ich studiere auf das (zugegebenermaßen bald überholte) MCAD, und ein Teil des WinForms-Elements war Visual Inheritcence.

Ich persönlich hatte keine größeren Probleme damit, sind jedoch zu berücksichtigen.

Für mich ist das Hauptproblem immer die Initialisierung . Sie müssen sich daran erinnern, dass der Designer Formulare nicht zur Laufzeit auf die gleiche Weise instanziieren kann (ähnlich kann es das nicht tun) mit Web-Dev, weshalb Pflege mit benutzerdefinierten Steuerelement Rendering benötigt wird.

Auch wenn einmal ein Formular geändert wird, ist ein vollständiger Neuaufbau des Projekts erforderlich, um die Änderungen an das Formular an die untergeordneten Formulare weiterzuleiten, die von ihm erben.

Ich persönlich habe keinen Beweis dafür gesehen, dass es "gemieden" wurde. AFAIK, es ist immer noch eine gute Praxis, Code-Wiederverwendung wo möglich auszuüben. Visuelle Vererbung bietet das.

Darf ich vorschlagen, eine neue Frage mit den tatsächlichen Problemen, die Sie haben, mit Beispielcode zu erstellen? Wir können es dann anschauen, um zu sehen, ob wir es zum Laufen bringen können und warum:)

    
Rob Cooper 08.09.2008 11:34
quelle
2

Ich habe einige Probleme in VS2005 damit gesehen. Sie waren hauptsächlich auf Probleme mit der Konstruktion der Formularobjekte im Designer zurückzuführen. Es gab Probleme mit Code, der versuchte, von den Formularkonstruktoren usw. auf die Datenbank zuzugreifen.

Sie können Probleme wie diese beheben, indem Sie eine zweite Instanz von Visual Studio starten und die erste Instanz im Debugger laden. Wenn Sie in Ihrem Code Haltepunkte setzen, können Sie debuggen, was in den Designern in erster Instanz passiert.

Ein anderes Problem, an das ich mich erinnern kann, waren Generika in Formularklassen

%Vor%

das wird nicht funktionieren

    
Mendelt 08.09.2008 12:16
quelle
1

Ich stolpere oft über solche Probleme in Visual Studio. In vielen Fällen kann der MSVS-Formular-Designer das Formular nicht korrekt darstellen. In den Tagen, in denen ich mit WinForms gearbeitet habe, musste ich alle möglichen seltsamen Tricks machen, um einige komplexe Szenarien zu ermöglichen. Ich denke jedoch, dass die Verwendung visueller Vererbung sehr vorteilhaft ist und nicht von MSVS Designer-Bugs weggeworfen werden sollte.

    
aku 08.09.2008 11:05
quelle
1

Ich denke, ich habe einen Weg gefunden, wie ich dieses Problem vermeiden kann.

Hängen Sie das Form_Load-Ereignis nicht in Ihr übergeordnetes Formular ein, dies unterbricht den Designer.

Nehmen Sie den leeren Standardkonstruktor auch nicht von Visual Studio im übergeordneten Formular weg. Wenn Sie Dependency Injection haben möchten, erstellen Sie einen anderen Konstruktor.

So:

%Vor%

Sie können dies immer noch von Ihrem geerbten Formular aus tun:

%Vor%

Das hat bei mir bisher funktioniert, und ich hatte auch einige seltsame Designerprobleme.

Prost, Daniel

    
Tigraine 03.11.2008 14:50
quelle
0

Lesen Sie dies: Ссылка

AFAIK, es gibt immer noch Probleme mit visueller Vererbung und Objekten, die auf Sammlungen für die Design-Elemente angewiesen sind, typischerweise Grid-Kontrollen usw. Ich glaube, MS hat immer noch die Möglichkeit entfernt, z. eine GridView in einer geerbten Form / Benutzersteuerung usw. Aber andere Steuerelemente wie TextBox, Form, UserControl, Panel usw. sollte wie erwartet funktionieren.

Ich hatte bisher kein Problem damit, dass ich selbst Grid-Controls von Drittanbietern verwende, aber Sie müssen besonders vorsichtig sein, wenn Sie Elemente aus Sammlungen entfernen MÜSSEN vermieden werden.

    
Trygve Lorentzen 29.01.2010 12:22
quelle