dziedziczenie i pola chronione w VCL

Głupia sprawa, na przykład:
TEdit, TLabel i TMemo dziedziczą po TControl
każdemu z osobna można zmienić Color:

Edit1->Color = clRed;
Label1->Color = clRed;
Memo1->Color = clRed;

jeśli dostanę wskaźnik do czegoś co jest editem, labelem albo memo, to mogę rzutować:

dynamic_cast<TEdit*>(Object) -> Color = clRed;
dynamic_cast<Label1*>(Object) -> Color = clRed;
dynamic_cast<Memo1*>(Object) -> Color = clRed;

ale nie mogę zrobić tak:

dynamic_cast<TControl*>(Object) -> Color = clRed;

mimo, że TControl ma pole Color już, tyle że nie upublicznione. To ja się pytam: gdzie są zalety dziedziczenia po TControl w ogóle? Jak wykorzystać dziedziczenie ze wspólnego przodka w VCL, bo nie chcę w funkcji ZmienKolorKontrolki(TControl* kontrolka) wsadzać 40-tu rzutowań po kolei i liczyć, że któreś wejdzie :|

Już nie mówiąc o tym, że taka funkcja by nie mogła pracować na komponencie jakimś nowym, który dziedziczy np po TCustomEdit a nie Edit (bo rzutowanie na TCustomEdit też mi g**no daje - on też ma Color ukryty, muszę na TEdit próbować). Co za debil projektował kontrolę dostępu w VCL?!

ale spokojnie możesz rzutować TEdit na TLabel i mieć dostęp do własciwości Color. Ogólnie klasy bazowe, dziedziczenie itp w VCLu idą w trochę inną stronę. BTW jeśli przyjrzysz się idei VCL to sam stwierdzisz, że TWinControl nie może mieć wszystkich właściwości publicznych (bo tylko do min. takich masz dostęp poza klasą).

OMFG, faktycznie. Rzutuję sobie na TStringList wskaźnik realnie ustawionyna TComboBox i mogę zmieniać kolor [rotfl]
Nic to, zobaczymy, czy mi się to kiedyś wypieprzy, na razie uratowałeś mnie metodą bezczelną, bo łamiącą zasady zdrowego rozsądku, ale działającą pięknie ;)

Dopisane:
nie chciałem smęcić, ale posmęcę - Misiekd, wyjaśnij dlaczego TWinControl nie powinien udostępniać publicznie pól. Nie mówię w published (bałagan w inspektorze obiektów, za dużo pól by było), ale w public przynajmniej. Dla mnie to dziwny design, kiedy rodzic ma pola, ale protected, a potomek je po prostu upublicznia. To sprawia, że potomkowie udają wpólny interfejs, a jak przychodzi co do czego, to wspólnego interfejsu nie ma - znaczy kiła.

taki design moze miec uzasadneinie w kilku przypadkach:

• rodzina klas zaklada ze wiele klas bedzie mialo to cos, ale defacto rodzic sam w sobie nie wie jak obsluzyc to cos, i obsluge (i wybor czy w ogole to obslugiwac!) zrzuca na dziecko
• rodzic uzywa tego pola, ale jego obsluga jest szczatkowa, "niskopoziomowa" i nie powinna byc widoczna. dzieci ja przykrywaja swoja obsluga, sensowniejsza dla klienta - np. czesto przy virtualach
  ..itp
  ..tylko to dotyczy METOD.. a po co ukrywac w ten sposob pola - tez nie moge sobie w tej chwili wyobrazic.. chyba ze to sa properties z handlerami onset/onget -- wtedy patrz na to jak na metody

quetzalcoatl napisał(a)

a po co ukrywac w ten sposob pola - tez nie moge sobie w tej chwili wyobrazic.. chyba ze to sa properties z handlerami onset/onget -- wtedy patrz na to jak na metody

zauważ, że pola (a własciwie właściwości) to jest to co widzisz w OI. Idea jest taka, aby to "najmłodsze" dziecko decydowało co się ma w OI pokazać. Zobacz sobie np. klasę TCustomEdit i TEdit - TCustomEdit to na dobrą sprawę pełnoprawny Edit ale z własciwościami protected a TEdit to nic innego jak jedynie przeniesienie wybranych właściwości do sekcji published. Własnie dla tego są one protected a nie public

sorry, nie mialem szans tego zauwazyc bo nie mam BCB..
a tak swoja droga - OMG.. co za 'odkrywcze' uzycie widzialnosci.. az dziw ze to nie wymysl M$ftu

Ok, dobra, queztalcoatl i Misied - dzięki wam mam wizję, co oni chcieli stworzyć ;] Że zrobili to trochę dziwnie, to inna sprawa - właśnie TCustomEdit i TEdit to kwintesencja tego, co mnie boli.

Ale co tam, skoro rzutując na chama metodą miśka mogę wszystko, to jest nieźle. Niby reinterpret_cast to też zuo, ale o rzędy wielkości mniejsze niż 30 dynamic_castów.