[C++] Sender van Event gebruiken?

[Verwijderd]

Ik heb ooit een keer in Borland Delphi gebruik gemaakt van de Sender parameter die in een event wordt meegegeven. Erg handig, want zo kun je één event maken voor meerdere componenten. Bijvoorbeeld één OnClick voor 10 buttons. Aan de Sender parameter wordt dan meegegeven op welke button er is geklikt als het event wordt aangeroepen. In Delphi ging dit vrij simpel (zoiets dacht ik):

Delphi:

if (Sender = Button1) then
  doe dit;
else
  doe dat;

In C++ lijkt dit dus helemaal niet te werken. Iemand die toevallig wel weet hoe het moet? BVD

[.oisyn]

Gebruik je wel de == om te vergelijken, ipv de = die is bedoeld om toe te kennen?

[Verwijderd]

Ja, dit was het delphi voorbeeld.

[.oisyn]

Tja als je zo weinig info geeft wordt het giswerk natuurlijk . Wat lukt er niet? Welke libraries gebruik je? Wat is je code? Welke foutmeldingen krijg je eventueel?

[whoami]

Moet je niet eerst checken of sender wel een button is, en zoja, deze casten naar het type TButton, en dan pas vergelijken ?

[Verwijderd]

De code, zoals ik in de startpost gaf, werkt wel in Borland Builder 4 (op school getest) maar dus niet in Borland Builder 6 thuis. Waarschijnlijk geen probleem wat de code betreft dus. Misschien dat nieuw installeren helpt of een andere compiler. Wazig...

[ Voor 4% gewijzigd door Verwijderd op 17-02-2006 15:54 ]

[MBV]

En ik neem aan dat je C++ Builder bedoelt? Qt bijv werkt heel anders . Bij mijn weten moet dat kunnen, aangezien dat is afgeleid van Delphi. Kijk anders eens in de man-pages, zal vast wel vermelden hoe je een sender kan opvragen

En pas op voor onwijs lange if/else of switch/case constructies. Vaak is het dan handiger om tig functies te hebben, die allemaal naar 1 functie voor het centrale stuk verwijzen. Is beter onderhoudbaar, omdat je geen vage constructies toepast die tegen het principe van de toolkit ingaan

[ Voor 39% gewijzigd door MBV op 17-02-2006 19:06 ]

[MSalters]

't Is een OO anti-pattern, dus ik kan me goed voorstellen dat het eruit gehaald is.

Hoe wil je de unit test schrijven? Als Sender nooit Button1 is?

[whoami]

MSalters schreef op vrijdag 17 februari 2006 @ 21:46:
't Is een OO anti-pattern, dus ik kan me goed voorstellen dat het eruit gehaald is.

Op wat heb je het ?

[.oisyn]

Ik neem aan dat ie doelt op het doorrouten van alle button-click events naar dezelfde functie, en in die functie controleren welke knop nou eigenlijk ingedrukt is.

@MBV hieronder: ik denk dat je het een beetje verkeerd interpreteert, whoami reageert op MSalters, en die bedoel ik dus met "ie". En MSalters zegt precies hetzelfde als jij . Ik ben het er ook mee eens overigens.

[ Voor 41% gewijzigd door .oisyn op 18-02-2006 22:21 ]

[MBV]

@oisyn: dat vind ik nou eigenlijk het meest zinloze wat je kan doen: het wordt al netjes voor je gefilterd, je gooit het in een bak, en gooit het vervolgens op de meest onoverzichtelijke manier door. Behalve met een rekenmachine ofzo kan ik me daar absoluut niks bij voorstellen...

[Verwijderd]

Woow, zo leer ik ook nog wat. Morgen maar eens een flink potje googlen op al die thermen die hier voorbij komen gevliegen. Maar syntactisch ben ik er in ieder geval uit hoor.

[MBV]

wat bedoel je met syntactisch? Hoe krijg je je sender dan terug? en gebruik je idd de borland builder toolkit?

[MSalters]

whoami schreef op vrijdag 17 februari 2006 @ 23:38:
[...]
Op wat heb je het ?

Meegeven van de Sender. In een goed OO ontwerp weet een event handler niet wie de Sender is, dus waarom zou een OO framework dan moeite moeten doen om een Sender parameter te initialiseren?

Bovendien zit je dan met het probleem dat de Sender dan ook nog eens identificeerbaar moet zijn. Dat is dus niet altijd makkelijk, als sommige events van het OS (buiten het framework) komen, sommige asynchroon, etcetera. De Sender kan soms al niet meer bestaan, en dan is een pointer niet meer geschikt als identifier. Kortom, erg veel werk voro iets wat overbodig zou moeten zijn.

[ATS]

Toch zijn er situaties te verzinnen waarin het weldegelijk nuttig is. Het is misschien niet strikt OO, maar dat wil niet zeggen dat het onzinnig is. Als een manier van programmeren je meer tegen gaat houden dan dat het je helpt, dan is misschien tijd om tegen de regels te zondigen. Daarom is het bijvoorbeeld in Qt (een C++ framework) wel mogelijk. Het wordt spaarzaam gebruikt, maar het kan onnodige omwegen voorkomen. Dat is vervolgens voor de meest voorkomende situaties weer netjes in een class geencapsuleerd (QSignalMapper) zodat je in de praktijk zelf niet zo vaak gebruik zal hoeven maken van de sender, maar QSignalMapper gebruikt hem op de achtergrond wel.

[Verwijderd]

MBV schreef op zaterdag 18 februari 2006 @ 23:26:
wat bedoel je met syntactisch? Hoe krijg je je sender dan terug? en gebruik je idd de borland builder toolkit?

C++:

void __fastcall TForm1::ImageClick(TObject *Sender)
{
  if (Sender == Image1)
      Image1->Picture->Bitmap->LoadFromFile("Pic1.jpg");
  if (Sender == Image2)
      Image2->Picture->Bitmap->LoadFromFile("Pic1.jpg");
}

Op deze manier werkt het in Borland Builder 4. Alleen in Borland Builder 6, die ik thuis gebruik wil dit niet. Hij kan iets van het type TObject niet vergelijken met (weet ik zo snel niet meer).

[Kayshin]

Daarom moet je hem dus typecasten naar een type dat gelijk is aan het type dat je controleert. Je kan bijvoorbeeld ook officieel (Misschien dat sommige compilers dit wel toestaan mits op de juiste manier gebruikt) geen TButton vergelijken met een TMemo.

Heb hier nog op school veel over gehad. (Dit is in Delphi, voor het idee. Weet zo gauw niet hoe het in c moet)

Delphi:

If (Sender is TButton) then
  showmessage((Sender AS TButton).name);

[ Voor 6% gewijzigd door Kayshin op 20-02-2006 01:22 ]

[schoene]

je moet je sender casten naar TImage:

C++:

void __fastcall TForm1::ImageClick(TObject *Sender)
{
  TImage *Image = dynamic_cast<TImage *> (Sender);

  if (Image)
      Image->Picture->Bitmap->LoadFromFile("Pic1.jpg");

}

[.oisyn]

Waarom, een TImage is toch impliciet te casten naar een TObject (TImage is een subclass van TObject)? Dus die cast is niet nodig.