Designer zeigt die geerbten Objekte nicht an

Hallo zusammen,

nachdem nich mich den ganzen Morgen hier durch die Vererbung durchgelesen habe;

auch das Problem mit Der Konstruktor für den Typ ... gefunden gefunden, korrigiert, aber nicht wirklich verstanden habe (vielleicht kann mir jemand dazu auch noch ein verständliches Beispiel nennen ...),

habe ich das nächste Verständnisproblem:

Ausgangslage:

1. eine Basis-Form ("Stammmaske"), die einen Binding-Navigator, ein Tab-Control und eine Statusleiste u. diverse Methoden enthält.

2. eine Form (Kundenstamm), die von der Basis-Form erbt

...
public partial class Kundenstamm : Stammmaske
/
...

Wenn ich die Form "Kundenstamm" ausführe, dann sehe ich, wie erwartet, den Binding-Navigator, das Tab-Control u. die Statusleiste; u. es werden die enthaltenen Methoden ausgeführt.

Öffne ich aber den "Kundenstamm" mit dem Designer, so sehe ich "nur" eine nackte Form 🤔

Eigentlich hätte ich auch jetzt hier erwartet die o.g. Controls zu sehen u. bearbeiten / erweitern zu können ...

Die Basisform soll mir eigentlich als Vorlage für dauernd (in jeder Form) wiederkehrende Methoden und Eigenschaften dienen, so das ich dann nur noch die jeweils individuellen Controls, Eigenschaften u. Methoden hinzufügen muß ...

Irgendwie tue ich mich da wohl mit c# etwas schwer, auch finde ich, das die ganze Vererbung doch wesentlich komplexer als in FoxPro ist (in VFP z.B. wurden die geerbten Methoden im Designer niemals aufgerufen nur in der Ausführung ...)

Wer kann mir da helfen, bzw. wo kann ich mich verständlich einlesen ???

MfG ChrisProg

Vermutlich fehlt Dir das Designer Attribut
How to: Create a Windows Forms Control That Takes Advantage of Design-Time Features

Hi,

naja - wenn deine Form "nackt" angezeigt wir - würde ich fast vermuten, dass deine Stammmaske zwei Konstruktoren hat und du beim erben den aufrufst, der nicht "InitializeComponent" aufruft. (Eine vom Forms-Designer generierte Methode)

Unabhängig davon wird das alleine dir auch nichts helfen, da die vom Designer erstellten Controls mit "private" markiert sind im Standard. (Wirst du dann für jedes Control anpassen müssen, damit du in der erbenden Form irgendwas daran schrauben kannst)

Zu Windows Forms:
Wird derzeit immer stärker von WPF ersetzt. Wenn du eh gerade erst anfängst solltest du da vll mal drüber schauen. Ist zwar erstmal schwieriger, spart am Ende aber Arbeit und man findet am Ende im eigenen Code auch noch was.

Zum Thema Vererbung:
Ich kenne FoxPro/VFP jetzt nicht - aber mal bei reiner Vererbung ist Windows Forms da eigentlich sehr transparent, was ich auch gut finde. Designer-spezifischer Code ist durchaus auch in Windows Forms möglich.

LG

Edit:
Dein Verständnisproblem kann ich nicht nachvollziehen in puncto Konstruktoren. Was verstehst du nicht? Die Kernaussage des Threads ist nämlich im Prinzip:

"Eine Form muss eine parameterlosen Konstruktor haben, damit der Designer funktioniert."

Ergo für den Designer nicht nutzbar:

public class MyForm : Form
{
public MyForm(string value) { this.InitializeComponents();}
}

Besser für den Designer:

public class MyForm : Form
{
public MyForm() { this.InitializeComponents();}
public MyForm(string value) : this() {}
}

Hallo Taipi88,

naja - wenn deine Form "nackt" angezeigt wir - würde ich fast vermuten, dass deine Stammmaske zwei Konstruktoren hat und du beim erben den aufrufst, der nicht "InitializeComponent" aufruft. (Eine vom Forms-Designer generierte Methode) Strike! manchmal sieht man den Wald ...

Unabhängig davon wird das alleine dir auch nichts helfen, da die vom Designer erstellten Controls mit "private" markiert sind im Standard. (Wirst du dann für jedes Control anpassen müssen, damit du in der erbenden Form irgendwas daran schrauben kannst)

Und wie stelle ich das an ?

Beispiel Navigationsleiste:
Im Designer.cs habe ich die entsprechenden Objekte "public" gemacht ...

        public System.Windows.Forms.BindingNavigator Navigationsleiste;
        public System.Windows.Forms.ToolStripButton bindingNavigatorAddNewItem;
        public System.Windows.Forms.ToolStripLabel bindingNavigatorCountItem;
        public System.Windows.Forms.ToolStripButton bindingNavigatorMoveFirstItem;
        public System.Windows.Forms.ToolStripButton bindingNavigatorMovePreviousItem;
        public System.Windows.Forms.ToolStripSeparator bindingNavigatorSeparator;
        public System.Windows.Forms.ToolStripLabel positionsanzeige;
        public System.Windows.Forms.ToolStripSeparator bindingNavigatorSeparator1;
        public System.Windows.Forms.ToolStripButton bindingNavigatorMoveNextItem;
        public System.Windows.Forms.ToolStripButton bindingNavigatorMoveLastItem;
        public System.Windows.Forms.ToolStripSeparator bindingNavigatorSeparator2;
        public System.Windows.Forms.ToolStripButton loeschen_button;
        public System.Windows.Forms.ToolStripButton speichern;
        public System.Windows.Forms.ToolStripButton rueckgaengig;

trotzdem kann ich nicht darauf zugreifen ... (beim TabControl übrigens hervorragend ...)

Ist das diese "Einschränkung im Designer" und ich kann auf Ereignisse nur über z.B. Zuweisung

Navigationsleiste.AddNewItem.Click += new EventHandler(bindingNavigatorAddNewItem_Click);

darauf zugreifen, oder gibt es doch noch andere Möglichkeiten ???

Dein Verständnisproblem kann ich nicht nachvollziehen in puncto Konstruktoren. Was verstehst du nicht? Die Kernaussage des Threads ist nämlich im Prinzip:

"Eine Form muss eine parameterlosen Konstruktor haben, damit der Designer funktioniert."

Ich habe die Worte verstanden u. es auch umgesetzt, nur verstehe ich den Sinn dahinter nicht ... =)

@Abt: wenn ich ehrlich bin, habe ich mir deinen Link angeschaut u. nicht verstanden was da passiert ... X(

MfG ChrisProg

Hi,

zum Thema Sinn des parameterlosen Konstruktors:
Der Designer braucht ihn und wird ihn verwenden. Andernfalls hast du eben keine Design-Ansicht.

Was die Einschränkungen und deine Probleme angeht:
Im Prinzip ist das genau dein Problem. Das public wie du's gemacht hast ist schon richtig - dummerweise hilft es aber nicht immer. (Und selbst wenn - musst du halt immer erst neu kompilieren, bevor er's rafft)

Mal als alternative Vorgehensweise:
Ich würde eine eigene Formableitung erstellen (ohne Hilfe des Designers - also einfach in einer normalen .cs-Datei in einer Klasse von System.Windows.Form erben und dort wichtige Methoden rein machen.

Wenn du Controls mit Vorkonfiguration benötigst - kannst du spezielle UserControls verwenden und entsprechend einstellen, so dass du weniger Arbeit hast.

Was die Behandlung von Ereignissen angeht:
Grundsätzlich ist der von dir gezeigte Weg eine Standardvariante zum Behandeln von Ereignissen. Mögliche alternative "Schreibweisen" gibt es in der Tat - aber das ist jetzt nichts spezielles.
Alternativ - wenn die Basismethode überschreibbar ist (virtual/abstract) kannst du mit "override" auch Methoden überschreiben wie üblich. Aber auch komplett c#-konform.
(und somit teils auch Methoden, die eben jene Ereignisse auslösen)

LG

Was Du suchst, nennt sich 'visual inheritance' - hier findest Du mehr zum Thema:
MSDN: Windows Forms Visual Inheritance