[C#]System.window.forms.control decoreren

[Verwijderd]

Hallo, ik heb het volgende probleem. Ik heb een hele berg met objecten die subklasse zijn van Control. Hieronder zijn bijvoorbeeld instanties van Button, TextBox en dergelijke. Nu wil ik langs elk van deze controls lopen en ze een extra propertie geven. Hiervoor lijkt decoreren me de beste oplossing alleen loop ik dan tegen het probleem op dat ik voor elke methode(en dat zijn er best veel) een eigen doorgeef implementatie moet maken. Volgens mij kan dit simpeler. Iemand een idee?

[whoami]

Wat bedoel je precies met 'een eigen doorgeef-implementatie' ?

[pjvandesande]

Ik snap je vraag niet helemaal eigelijk, maar als je eigen control een propertie hebben die je wil setten kun je door je controls lopen en kijken welke van het type zijn van je eigen control.
Voorbeeld:

C#:

foreach(Control control in Controls)
{
     if( control is MyControl )
     {
          MyControl myControl = (MyControl)control;
          myControl.MyExtraPropertie = "value"; // Dit hoeft geen string te zijn natuurlijk
     }
}

[Verwijderd]

Ik wil dus eigenlijk een extra propertie instellen en deze moet bij zowel buttons als textboxes kunnen worden toegevoegd. Dus bijv:

Control control = haalEenControlOp()//Button, TextBox, etc
ControlDecorator cd = new ControlDecorator( control );
cd.ExtraProp = "Blaaaaaaa";
this.Controls.Add( cd );

[ Voor 7% gewijzigd door Verwijderd op 03-11-2005 15:08 ]

[pjvandesande]

Dan is het gewoon:

C#:

foreach(Control control in Controls)
{
     ControlDecorator cd = new ControlDecorator( control );
     cd.ExtraProp = "Blaaaaaaa";
}

[Verwijderd]

Ja dat snap ik, maar als ik zoiets maak

code:

public class ControlDecorator:Control
    {
        private Control control;

        public ControlDecorator(Control control)
        {
            this.control = control;
        }

        public Type getType()
        {
            return control.GetType();
        } 
    }

Moet ik dat voor elke methode en propertie doen en dat lijkt me erg foutgevoelig.

[pjvandesande]

Verwijderd schreef op donderdag 03 november 2005 @ 15:12:
Moet ik dat voor elke methode en propertie doen en dat lijkt me erg foutgevoelig.

Wat moet doen voor elke Method en Propertie?

Ik heb echt geen idee wat je precies wilt, misschien is er een beteren oplossing voor je probleem of voor het doel dat je wilt bereiken.

Wat moet er precies gebeuren, want ik vind het allemaal maar wat vaag?

[Verwijderd]

Ja kijk ik bouw aan de hand van xml een arraylist met buttons textfields en andere controls op.
Dus in mn xml staat bijvoorbeeld:
<Button>
<Text type="string">Nu</Text>
<Tag type="string">www.nu.nl</Tag>
</Button>

Met behulp van:
PropertyInfo propinfo = controltype.GetProperty( propertie.Name );
propinfo.SetValue( control, setValue, null );
Set ik al deze waardes.

Alleen is mijn probleem dat ik nog een paar extra dingen wil hangen aan mijn controls die er niet standaard inzitten, zoals bijvoorbeeld welke actie er bij klikken aan moet hangen en misschien wil ik later nog meer opslaan.
Ik zou wel voor elke verschillende control een subklasse kunnen maken en dan de extra propertie erbij zetten. Maar het lijkt me mooier om deze toe te kunnen voegen zonder te weten welk type control het is.

[ Voor 6% gewijzigd door Verwijderd op 03-11-2005 15:23 ]

[pjvandesande]

Verwijderd schreef op donderdag 03 november 2005 @ 15:23:
Maar het lijkt me mooier om deze toe te kunnen voegen zonder te weten welk type control het is.

Dat kan toch niet. Je moet weten wat voor type het is anders weet je ook niet of je object de desbetreffende property wel heeft.

Met Reflection kun je gewoon alles opvragen, zoals je nu ook als doe voor de properties. Er zit dus niets anders op.

Als je allemaal voortuigen hebt kun je ook niet de spiegels op 33 graden afstellen, want een fiets heeft geen spiegels.

[Verwijderd]

Maar het mooie aan polimorfisme is toch dat dat niet uitmaakt van welk type de klasse is. Ik wil de textboxes, buttons en dergelijke aanmaken en dan aan elk object extra properties hangen doormiddel van decoration. En de dingen de controls gebruiken zoals mijn Form kunnen de controls gewoon als gewone controls gebruiken. De methode die controls aan het Form toevoegd hoeft ook niet te weten van welke klasse de controls zijn.

[whoami]

Omdat die form gewoon een 'control' moet toevoegen, en het idd niet uitmaakt welke control het is.

Echter, wat jij wil zal je toch mbhv reflection moeten oplossen; dat heeft nl. niets met polymorphisme te maken. Bij polymorphisme weet je gewoon dat een object een bepaalde method/property heeft, maar weet jij (als gebruiker) hoeft niet te weten van welk type dat object nu exact is. Als je weet dat het van een bepaald basis type is, is dat al genoeg.

[pjvandesande]

Verwijderd schreef op donderdag 03 november 2005 @ 15:33:
Maar het mooie aan polimorfisme is toch dat dat niet uitmaakt van welk type de klasse is. Ik wil de textboxes, buttons en dergelijke aanmaken en dan aan elk object extra properties hangen doormiddel van decoration. En de dingen de controls gebruiken zoals mijn Form kunnen de controls gewoon als gewone controls gebruiken. De methode die controls aan het Form toevoegd hoeft ook niet te weten van welke klasse de controls zijn.

Dit heeft niets met polimorfisme te maken.

Als je de Text propertie wilt aanpassen van je controls kan dit, want je Base class waar als je objecten van overgerft zijn heeft de propertie.

Je weet niet wat een laag hoger voor method's/properties heeft. Stel je hebt devolgende twee classes:

C#:

public class Foo
{
     private string _name;

     public string Name
     {
          get{ return _name }
          set{ _name = value }
     }
}

public class Bar : Foo
{
     private int _age;

     public int Age
     {
          get{ return _age}
          set{ _age= value }
     }
}

Nu wil je de properties gaan zetten:

C#:

Foo foo = new Bar();
foo.Name = "Name";
foo.Age = 20; // Kan niet!

Je kunt nooit een laag hoger, wel lager. Jij weet namelijk niet wat voor Properties een laag hoger heeft. Wat ook heel logies is. Wil je age wel gebruiken dat moet je eerst weten dat het een Bar type is. Dat zou je hem wel kunnen setten.

[ Voor 22% gewijzigd door pjvandesande op 03-11-2005 15:45 ]

[Verwijderd]

Maar dus wil ik een decorator hebben die van Control extend en de extra propertie kan toevoegen. Dus bijvoorbeeld:

code:

Button button = new Button();
//alles setten
TextBox text = new TextBox();
//alles setten

ControlDecorator cd = new ControlDecorator( button );
ControlDecorator cd2 = new ControlDecorator( text );
cd.Extra = "sss";
cd2.Extra = "eeee";

this.Controls.Add(  cd );
this.Controls.Add(  cd2 );

[ Voor 5% gewijzigd door whoami op 03-11-2005 15:52 ]

[pjvandesande]

Waarom maar je dan geen IExtraable interface?

Al jou control implementeren die interface en je kunt de Extra propertie setten/getten.

offtopic:
Gebruik de code tag eens alstublieft.

[H!GHGuY]

misschien is het handig om weten dat controls ook een Tag property hebben waar je zelf 1 iets in kan stoppen afaik.

voor simpele dingetjes kan dat wel eens handig zijn.

en idd zoals questa schrijft:

C#:

public interface IExtraControl
{
    string myProperty { get; set; }
}
public class MyTextBox : TextBox, IExtraControl
{
 ...
}

[EfBe]

Class definieren voor jouw extra properties, daarvan instances stoppen in iedere control's Tag property. Uitlezen: de Tag property casten naar jouw property class, dan de properties uitlezen en gebruiken.

Zelf gaan lopen prutsen met interfaces kan mislopen want dat is niet 100% compatible met _ALLE_ controls.

[ Voor 23% gewijzigd door EfBe op 04-11-2005 12:35 ]

[Verwijderd]

Volgens mij wil ie zo min mogelijk sleutelen aan alle controls. Volgens mij kan je gewoon met Reflection fields, methods, properties toevoegen aan een bestaande control. Zou daar eens naar kijken of dat hetgeen is wat je wilt doen.

[pjvandesande]

EfBe schreef op vrijdag 04 november 2005 @ 12:34:
Zelf gaan lopen prutsen met interfaces kan mislopen want dat is niet 100% compatible met _ALLE_ controls.

Hoezo niet, je kun toch gewoon een control class extenten inclusief de interface?

Verwijderd schreef op vrijdag 04 november 2005 @ 13:14:
Volgens mij wil ie zo min mogelijk sleutelen aan alle controls. Volgens mij kan je gewoon met Reflection fields, methods, properties toevoegen aan een bestaande control. Zou daar eens naar kijken of dat hetgeen is wat je wilt doen.

Met reflection voeg je geen fields, methods etc toe, dat is onmogelijk. Hij kan ze wel opvragen en uitlezen dmv reflection.

Maar een simpele bag in de Tag propertie donderen volstaat ook wel denk ik.

[Verwijderd]

questa schreef op vrijdag 04 november 2005 @ 13:19:
Met reflection voeg je geen fields, methods etc toe, dat is onmogelijk. Hij kan ze wel opvragen en uitlezen dmv reflection.

Maar een simpele bag in de Tag propertie donderen volstaat ook wel denk ik.

Tag property is beetje lelijk in mijn opinie. Trouwens je kan wel degelijk dynamisch dingen toevoegen:
http://msdn.microsoft.com...thodbuilderclasstopic.asp

Trouwens las net een stukje op codeproject (ergens in het midden staat iets over het toevoegen van een "Sum" method aan een type):
http://www.codeproject.com/csharp/IntroReflection.asp

Weet niet of je er wat aan hebt of niet .

[pjvandesande]

Verwijderd schreef op vrijdag 04 november 2005 @ 14:18:Tag property is beetje lelijk in mijn opinie.

Want?

Verwijderd schreef op vrijdag 04 november 2005 @ 14:18:Trouwens je kan wel degelijk dynamisch dingen toevoegen:

Oke, dit wist ik niet. Als je dit nodig hebt dan zuigt je design echt verschrikkelijk aars!

[Verwijderd]

questa schreef op vrijdag 04 november 2005 @ 14:25:
[...]
Want?

Omdat ik het VB style programmeren vind. Moet een variabele / object whatever bijhouden maar douw het maar in mijn Tag property i.p.v. een mooi systeem er voor bedenken. Ik denk dat je de Tag property nodig hebt als je niet lang genoeg nadenkt over je systeem en je iets toch ergens maar moet opslaan.

Oke, dit wist ik niet. Als je dit nodig hebt dan zuigt je design echt verschrikkelijk aars!

Dat weet ik zo net nog niet. Ik denk dat het wel handig kan zijn in sommige situaties (kan er alleen zo snel niet 1 bedenken. Zal voor de grap eens kijken of ik wat voordelen kan vinden van dit soort implementaties. Weet zeker dat er wel voordelen aan zitten maar je moet het niet klakkeloos gaan gebruiken, echter geldt dit volgens mij overal voor. Moet iets alleen implementeren als het echt nut heeft .

[EfBe]

Verwijderd schreef op vrijdag 04 november 2005 @ 14:18:
[...]
Tag property is beetje lelijk in mijn opinie. Trouwens je kan wel degelijk dynamisch dingen toevoegen:
http://msdn.microsoft.com...thodbuilderclasstopic.asp

Als iets niet wilt is het wel deze gore troep inbouwen Over niet onderhoudbaar gesproken
De Tag property is precies bedoeld voor de doeleinden van de TS. En je moet geen controls extenden want je bent dan dom bezig: in de class designer werk je met type T en jij moet werken met type T', dat derived is van T en jouw interface implementeert. Hoe ga je dat doen? Allerlei classes bouwen, van ieder control 1? Komt er een nieuw control, moet je weer een nieuwe class bouwen. Verder krijg je problemen als een control al een property/method van jouw interface implementeert. Nee, inheritance is in dit geval niet nuttig.

Aggregation echter wel, en sorry dat ik het zeg voor de OO puriteinen, maar aggregation is lang niet altijd slecht.

Verwijderd schreef op vrijdag 04 november 2005 @ 14:32:
[...]
Omdat ik het VB style programmeren vind. Moet een variabele / object whatever bijhouden maar douw het maar in mijn Tag property i.p.v. een mooi systeem er voor bedenken. Ik denk dat je de Tag property nodig hebt als je niet lang genoeg nadenkt over je systeem en je iets toch ergens maar moet opslaan.

Dom theoretisch geneuzel. In deze situatie is het de meest domme methode die je kunt kiezen door alle controls te subclassen door zelf nieuwe typen te declareren. De Tag property is bedoeld voor het toevoegen van additionele zut at runtime. Je zit nu eenmaal aan een framework vast wat werkt met vaste types en je kunt dan wel een interface willen implementeren op een subclass van ieder control, maar dat is echt heel veel werk doen om totaal NIETS te winnen, behalve een schouderklopje van een OO puritein.

Al overnagedacht dat de info die in de subclass extra wordt opgeslagen wellicht totaal niets met het control an sig te maken heeft maar met zn context waarin de instance geplaatst is? Wellicht is het dan NOG beter om een simpele hashtable te bouwen met type - extra data erin opgeslagen.

[...]
Dat weet ik zo net nog niet. Ik denk dat het wel handig kan zijn in sommige situaties (kan er alleen zo snel niet 1 bedenken. Zal voor de grap eens kijken of ik wat voordelen kan vinden van dit soort implementaties. Weet zeker dat er wel voordelen aan zitten maar je moet het niet klakkeloos gaan gebruiken, echter geldt dit volgens mij overal voor. Moet iets alleen implementeren als het echt nut heeft .

Zei hij terwijl hij wel voor ieder winforms control een subclass wil maken om toch maar vooral 'Tag' te omzeilen want oh jee...

[ Voor 46% gewijzigd door EfBe op 04-11-2005 14:41 ]

[whoami]

EfBe schreef op vrijdag 04 november 2005 @ 14:36:
[...]


Aggregation echter wel, en sorry dat ik het zeg voor de OO puriteinen, maar aggregation is lang niet altijd slecht.

Is één van de OO regels niet: prefer composition over inheritance.
(aggregation is toch ook een vorm van composition).

[D4Skunk]

Wat je volgens mij zoekt :
http://www.codeproject.co...ontrolextenderlibrary.asp

[Verwijderd]

EfBe schreef op vrijdag 04 november 2005 @ 14:36:
[...]

Als iets niet wilt is het wel deze gore troep inbouwen Over niet onderhoudbaar gesproken
[...]

Dom theoretisch geneuzel. In deze situatie is het de meest domme methode die je kunt kiezen door alle controls te subclassen door zelf nieuwe typen te declareren.

[...]

Zei hij terwijl hij wel voor ieder winforms control een subclass wil maken om toch maar vooral 'Tag' te omzeilen want oh jee...

Heb nergens gezegd dat ik overal een subclass wil maken. Zowiezo 100 subklassen maken is lekker productief? Helemaal als je meer methods / properties / etc nodig heb. Kan je alles weer nalopen. Ging trouwens meer om dat dynamisch toevoegen dat dat wel mogelijk is omdat iemand hier zou dat dat niet mogelijk zou zijn.

De Tag property is lekker overzichtelijk. De ene programmeur gebruikt hem hier voor, de andere daar. De ene keer zit er een int in de andere keer een object. Je hebt gelijk dat de Tag property bedoeld is om iets op te slaan wat je nodig hebt om toch het geen te kunnen realiseren wat je wilt maar vind het gewoon niet netjes. Ben geen OO purein maar er zullen vast andere mogelijkheden zijn die het wel wat overzichtelijker maakt. Wat ga je doen als je aan die Tag property niet genoeg hebt? Een class bouwen met die functionaliteit om vervolgens die hele class in de Tag property te zetten? Tja het is een optie ja...

Daarbij "probeer" ik oplossingen aan te dragen die de TS verder kunnen helpen. Sorry dat ik jouw superieure brein over het hoofd gezien heb en dat ik niet vermeld heb dat dit niet de beste oplossing is... Beetje jammer dat je dom kritiek krijgt op basis van speculaties...

[EfBe]

Verwijderd schreef op vrijdag 04 november 2005 @ 15:15:
Heb nergens gezegd dat ik overal een subclass wil maken. Zowiezo 100 subklassen maken is lekker productief? Helemaal als je meer methods / properties / etc nodig heb. Kan je alles weer nalopen. Ging trouwens meer om dat dynamisch toevoegen dat dat wel mogelijk is omdat iemand hier zou dat dat niet mogelijk zou zijn.

Het is ook niet mogelijk zonder een nieuw type te bouwen.

De Tag property is lekker overzichtelijk. De ene programmeur gebruikt hem hier voor, de andere daar. De ene keer zit er een int in de andere keer een object. Je hebt gelijk dat de Tag property bedoeld is om iets op te slaan wat je nodig hebt om toch het geen te kunnen realiseren wat je wilt maar vind het gewoon niet netjes.

Het kan grote zooi opleveren, helemaal mee eens. Echter voor deze specifieke situatie is het IMHO een practische oplossing. Naast een aparte datastructure die verbanden aangeeft tussen control type en extra data, maar dat is aan de andere kant ook weer niet zo heel practisch.

Ben geen OO purein maar er zullen vast andere mogelijkheden zijn die het wel wat overzichtelijker maakt. Wat ga je doen als je aan die Tag property niet genoeg hebt? Een class bouwen met die functionaliteit om vervolgens die hele class in de Tag property te zetten? Tja het is een optie ja...

Dat was inderdaad wat ik voorstelde. Het punt is nl. dat je 2 semantische contexten samenbrengt: de control types en de info per control at runtime die eigenlijk gebruikt wordt at runtime ergens anders voor. Het blijft behelpen, en omdat je, practisch gezien, niet echt van de controls af kunt wijken, moet je andere mogelijkheden zoeken.

Daarbij "probeer" ik oplossingen aan te dragen die de TS verder kunnen helpen. Sorry dat ik jouw superieure brein over het hoofd gezien heb en dat ik niet vermeld heb dat dit niet de beste oplossing is... Beetje jammer dat je dom kritiek krijgt op basis van speculaties...

Mijn brein is niet superieur maar ik heb gewoon een hekel aan clean-room gekeuvel dat alleen op gaat in een abstracte non-realistische situatie terwijl hier om een practische oplossing gevraagd wordt.

In theorie is het natuurlijk logisch: je extend de class, of nog beter: bouwt een nieuw base type met die properties en klaar ben je. In de praktijk is het hier een stuk anders. Dezelfde fout als sommigen hier wordt gemaakt door de z.g. UI mappers die je nu al ziet verschijnen (althans sommige): ze gebruiken allemaal hun eigen controls. Onpractisch, want stel de gebruiker wil een ultragrid vX.y gebruiken en hoe nu verder...

[ Voor 9% gewijzigd door EfBe op 04-11-2005 15:33 ]

[H!GHGuY]

even zijspoor:

offtopic:
als ik me niet vergis is het @ runtime maken van klassen handig voor bvb proxy-objecten (denk bvb aan remoting) of zelfs O/R-mapping

[whoami]

HIGHGuY schreef op vrijdag 04 november 2005 @ 20:24:
even zijspoor:

offtopic:
als ik me niet vergis is het @ runtime maken van klassen handig voor bvb proxy-objecten (denk bvb aan remoting) of zelfs O/R-mapping

Is dat niet eerder het runtime instantieren van objecten van reeds gedefinieerde typen

[H!GHGuY]

whoami schreef op vrijdag 04 november 2005 @ 20:56:
[...]

Is dat niet eerder het runtime instantieren van objecten van reeds gedefinieerde typen

In een project waarin ik reeds remoting gebruikt heb, had de client enkel interfaces en de server de objecten. Ik zou echter meer moeten lezen over het onderwerp om het zeker te zijn, maar om proxy-klassen te maken zou ik reflection zeker geen slechte mogelijkheid vinden

[whoami]

Ik werk momenteel aan een project waar dit ook het geval is, en reflection heeft daar niets mee te maken.
De client heeft de interfaces omdat die moet weten welke operaties er kunnen uitgevoerd worden.
De server creeërt een object, en returned een proxy naar de client. Die proxy stuurt dan alle calls door naar het 'echte' object op de server.

[EfBe]

HIGHGuY schreef op vrijdag 04 november 2005 @ 20:24:
even zijspoor:

offtopic:
als ik me niet vergis is het @ runtime maken van klassen handig voor bvb proxy-objecten (denk bvb aan remoting) of zelfs O/R-mapping

Klopt, het wordt in de javawereld veel gebruikt: je pakt de POCO classes en genereert nieuwe classes at runtime die je changetracking code bevatten en geeft die eigenlijk terug middels proxies.

Het nadeel ervan is dat je in multi-tier apps en remoting apps (met deze proxy-enabled entities) WEL de change tracking wilt maar NIET de lazy loading handel. Om dat te tunen ben je dus verder van huis. Reflection heeft nog een ander nadeel: als je de results niet cached zit je tegen een performance dip aan te kijken daar zeg je u tegen. Nadeel van het cachen van reflection data is weer dat je problemen krijgt met bv webapplications.

Je moet ook altijd aan je session/context een nieuwe instance vragen, want
CustomerEntity c = new CustomerEntity();
// c wijzigen
// c doorsturen naar andere tier

werkt dan dus niet, c is dan niet een proxy.

[ Voor 11% gewijzigd door EfBe op 05-11-2005 13:11 ]