Wie ist der Stand der Dinge mit „Visual Inheritance“?

Question

Wir haben eine Anwendung, die in der Art und Weise, wie sie dem Benutzer ihr Hauptformular anzeigt, flexibel sein muss – je nach Benutzer sollte das Formular etwas anders sein, vielleicht hier oder da eine zusätzliche Schaltfläche oder eine andere Nuance.Um das Schreiben von Code zum expliziten Entfernen oder Hinzufügen von Steuerelementen usw. zu stoppen, wandte ich mich zur Lösung des Problems der visuellen Vererbung zu – in einem meiner Meinung nach ordentlichen, sauberen und logischen OO-Stil – stellte sich heraus, dass geerbte Formen in der Hälfte der Fälle Schwierigkeiten haben sich selbst in VS ohne triftigen Grund usw. rendern – und ich habe das Gefühl, dass Entwickler und bis zu einem gewissen Grad Microsoft die Praxis der visuellen Vererbung gemieden haben – können Sie das bestätigen, übersehe ich hier etwas?

Grüße.

Answer 1

Ich dachte, sie hätten die Desktop-Designer-Probleme im Jahr 2005 mehr oder weniger gelöst.Haben Sie es mit den üblichen Übeltätern versucht?

• Keine abstrakten Kontrolltypen
• Keine Konstruktorargumente in irgendeiner Form
• Die Initialisierung wurde nach Form_Load und nicht nach Ctor verschoben
• Keine Steuerelemente im selben Projekt wie das Benutzersteuerelement/Formular, in das sie eingefügt werden
• Alle Dokumente schließen -> Bereinigen -> Neu erstellen
• Starten Sie VS neu

Ich schien zu glauben, dass es funktionierte, solange man alle oben genannten Schritte durchführte ...meistens.

Answer 2

Ich arbeite am (zugegebenermaßen bald veralteten) MCAD, und ein Teil des WinForms-Elements war Visual Inheritence.

Ich persönlich hatte jedoch keine größeren Probleme damit sind Überlegungen, die es zu berücksichtigen gilt.

Für mich, Das Hauptproblem ist immer die Initialisierung..Sie müssen bedenken, dass der Designer Formulare nicht auf die gleiche Weise instanziieren kann/will, wie er es zur Laufzeit tut (ähnlicherweise ist dies auch bei der Webentwicklung nicht möglich, weshalb beim Rendern benutzerdefinierter Steuerelemente Vorsicht geboten ist).

Auch, Sobald ein Formular geändert wird, ist ein kompletter Neuaufbau des Projekts erforderlich um die Änderungen am Formular an die untergeordneten Formulare weiterzugeben, die davon erben.

Ich persönlich habe keine Anhaltspunkte dafür gesehen, dass es „verachtet“ wurde. AFAIK, es ist immer noch eine gute Praxis, Code nach Möglichkeit wiederzuverwenden.Dafür sorgt die visuelle Vererbung.

Darf ich vorschlagen, eine neue Frage mit dem zu erstellen? tatsächlich Haben Sie Probleme mit dem Beispielcode?Wir können es uns dann ansehen, um zu sehen, ob wir es zum Laufen bringen können, und erklären, warum :)

Answer 3

Ich habe damit einige Probleme in VS2005 gesehen.Sie waren größtenteils auf Probleme bei der Konstruktion der Formobjekte im Designer zurückzuführen.Es gab Probleme mit Code, der versuchte, über die Formularkonstruktoren usw. auf die Datenbank zuzugreifen.

Sie können solche Probleme beheben, indem Sie eine zweite Instanz von Visual Studio starten und die erste Instanz im Debugger laden.Wenn Sie Haltepunkte in Ihrem Code festlegen, können Sie zunächst debuggen, was in den Designern passiert.

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

public class MyForm<MyObject> : Form

das wird nicht funktionieren

Answer 4

Ich stoße in Visual Studio oft auf solche Probleme.In vielen Fällen kann der MSVS-Formulardesigner das Formular nicht korrekt rendern.Damals, als ich mit WinForms arbeitete, musste ich alle möglichen seltsamen Tricks anwenden, um einige komplexe Szenarien zu ermöglichen.Ich denke jedoch, dass die Verwendung der visuellen Vererbung sehr nützlich ist und trotz der Fehler des MSVS-Designers nicht weggeworfen werden sollte.

Answer 5

Ich glaube, ich habe einen Weg gefunden, dieses Problem zu vermeiden.

Binden Sie das Form_Load-Ereignis nicht in Ihr übergeordnetes Formular ein, da dies den Designer beschädigen würde.

Entfernen Sie auch nicht den leeren Standardkonstruktor aus Visual Studio im übergeordneten Formular.Wenn Sie eine Abhängigkeitsinjektion wünschen, erstellen Sie einen anderen Konstruktor.

So was:

public ProductDetail()
{
    InitializeComponent();
}

public ProductDetail(ISupplierController supplierController) : base()
{
    InitializeComponent();
    this.supplierController = supplierController;
}

Sie können dies dann weiterhin von Ihrem geerbten Formular aus tun:

public NewProduct(ISupplierController supplierController)
    : base(supplierController)
{
    InitializeComponent();
}

Bisher hat das bei mir funktioniert, und ich hatte auch einige seltsame Designerprobleme.

Prost, Daniel

Answer 6

Lesen Sie dies: http://cs.rthand.com/blogs/blog_with_righthand/archive/2005/11/10/186.aspx

AFAIK, es gibt immer noch Probleme mit der visuellen Vererbung und Objekten, die auf Sammlungen für die Designelemente basieren, typischerweise Rastersteuerelemente usw.Ich glaube, MS hat immer noch die Möglichkeit entfernt, z. B. zu ändern.eine GridView in einem geerbten Formular/Benutzersteuerelement usw.Aber auch andere Steuerelemente wie TextBox, Form, UserControl, Panel usw.sollte wie erwartet funktionieren.

Bisher hatte ich selbst keine Probleme damit, dass VI Rastersteuerelemente von Drittanbietern verwendet, aber Sie müssen vorsichtig sein, insbesondere das Entfernen von Elementen aus Sammlungen MUSS vermieden werden.