[.NET/VS.NET] inheriten van abstract forms

[whoami]

Weird stuff.

Ik ben hier wat aan het prutsen met C# (Winforms).

Ik heb een interface met daarin 1 method signature in gedefinieerd.
Ik wil nu een abstracte form maken, die die interface implementeert bv:

code:

public class MyForm : System.Windows.Forms.Form, IMyInterface
{
   ....
   public abstract MyInterfaceMethod();
}

Geen probleem.

Echter, nu wil ik dus een form maken die inherited van die abstracte form. Als ik kies voor 'Add new item', en vervolgens voor inherited form, kan ik mijn abstracte form ten eerste al niet uit de 'inheritance picker' kiezen.
Als ik manueel de code verander om die form te laten overerven van m'n abstracte form, dan kan ik mijn form niet in de designer openen. Ik krijg dan een foutmelding ala:

The designer must create an instance of type MyForm but it cannot because it is abstract

Hoezo? WTF? Dit is toch onzin? Die designer moet helemaal geen instantie maken van m'n abstracte form, hij moet een form inheriten van die form.
Het vreemde is dat ik m'n abstracte form zelf wel in de designer kan bekijken, terwijl die eigenlijk echt wel abstract is.

[curry684]

Mjah ik kan het me wel voorstellen... hij leidt een form af van jouw baseclass, maar die is op dat moment nog abstract, waardoor ie 'm niet in de designer kan tonen, waardoor je er niet bij kunt om die method te implementeren. Beetje kip-ei probleem

[whoami]

curry684 schreef op 26 juni 2004 @ 15:08:
Mjah ik kan het me wel voorstellen... hij leidt een form af van jouw baseclass, maar die is op dat moment nog abstract, waardoor ie 'm niet in de designer kan tonen, waardoor je er niet bij kunt om die method te implementeren. Beetje kip-ei probleem

Toch wel vreemd dat hij de abstracte form zelf wel in de designer kan laden dan.

[whoami]

Ik blijf het eigenlijk vaag vinden; vooral dat m'n abstracte form zelf wel in de designer kan bekeken worden, en dat ik die abstracte form niet in m'n inheritance picker lijstje zie.
Bah, nu moet ik dit eigenlijk via een ranzige work-around oplossen. (Geen abstracte form, geen abstracte method, maar een virtual method met een lege body).

[curry684]

Je kunt iig voor de stijl nog wel een NotImplemented exception mikken in die lege virtual method

[whoami]

Jah, maar het blijft ugly.

Op die manier kan ik at compile time niet verhinderen dat er een instance van m'n 'niet zo heel abstracte form' gemaakt wordt.
Tenzij ik misschien de constructor private maak.

[ Voor 19% gewijzigd door whoami op 28-06-2004 11:19 ]

[CaptBiele]

offtopic:
lol... een discussie tussen (oud) moddereters...
dat krijg je he. Als je zelf de guru bent, aan wie kan je dan om hulp vragen?
Ik zou graag willen helpen, maar ik heb daar ook nog geen kaas van gegeten helaas.

[curry684]

whoami schreef op 28 juni 2004 @ 11:19:
Jah, maar het blijft ugly.

Op die manier kan ik at compile time niet verhinderen dat er een instance van m'n 'niet zo heel abstracte form' gemaakt wordt.
Tenzij ik misschien de constructor private maak.

Protected mag ik hopen, anders is het moeilijk deriven

In C++ werkt het zo wel overigens, kun je een non-public constructor inderdaad niet gebruiken om te instantieren. Daar gebruik je het overigens voornamelijk in combinatie met 'friend' om 1 op 1 relaties vast te leggen tussen 2 classes.

[whoami]

curry684 schreef op 28 juni 2004 @ 16:57:
[...]

Protected mag ik hopen, anders is het moeilijk deriven

Niet noodzakelijk denk ik zo.
Als je een protected constructor hebt, ben je er evenveel mee als dat je enkel een private constructor hebt: in beide gevallen kan je geen object instantieren (van buitenaf).
Als ik in m'n 'niet zo abstracte base form' enkel een private (of protected) constructor heb, dan is er niets dat mij tegenhoud om in m'n inherited class een gewone public constructor te maken.

Net ff getest, en dat werkt dan wel mooi op "t eerste zicht.

CaptBiele schreef op 28 juni 2004 @ 16:55:

offtopic:
dat krijg je he. Als je zelf de guru bent

offtopic:
guru
verre van.

[ Voor 17% gewijzigd door whoami op 28-06-2004 18:51 ]