[BCB] Jeden OnClick do wielu TLabel

0

Witam!
Chciałbym się dowiedzieć, w jaki sposób można wykorzystać jedną metodę do wielu obiektów tego samego typu. Przykład: Mamy 20 TLabel'i, piszemy jedną metodę Click, i przypisujemy ją wszytkim labelom. W ciele metody wypisujemy do jakiegoś Memo, Caption kilkniętej etykiety. Kombinowałem coś z obiektem Sender w ciele metody, ale nic nie udało mi się zdziałać. Proszę o pomoc, ew. fragment kodu.

Z góry dziękuję i pozdrawiam!

0

Action list?

Pzdr.

0

Hmm, action list... no dobrze, ale jak pobrać atrybuty obiektu (Label'a), który wywołuje dane zdarzenię w ActionList? Rzeczywiście, ActionList jest dobrym rozwiązaniem, ale nie wiem jak pobrać etykiętę klikniętego obiektu.

0

Zaznacz z ctrl'em wszystkie lable i w inspektorze obiektów na zakładce Events wybierz wspólny OnClick. Możesz również zrobić to pojedynczo.

0
adf88 napisał(a)

Zaznacz z ctrl'em wszystkie lable i w inspektorze obiektów na zakładce Events wybierz wspólny OnClick. Możesz również zrobić to pojedynczo.

Jak wyżej... Tylko jak pobrać informacje, który element został kliknięty :]?

Dzięki

0

Zrzutuj sender na TLabel i bedziesz mial obiekt, ktory wywolal zdarzenie.

0
johny_bravo napisał(a)

Zrzutuj sender na TLabel i bedziesz mial obiekt, ktory wywolal zdarzenie.

Lamersko to zabrzmi, ale nie jestem znawcą C(++), więc prosiłbym o jakiś fragment kodu. Dziękuję!

0

ShowMessage(AnsiString("Kliknieto label o nazwie ") + ((TLabel*)Sender)->Name);

0
adf88 napisał(a)

ShowMessage(AnsiString("Kliknieto label o nazwie ") + ((TLabel*)Sender)->Name);

Nie działa... ale dzieki za pomoc.

0

OK!!! Jednak działa, sorry :] za wprowadzenie w błąd! Wielkie dzięki i pozdrawiam!!!

0

Znalazłem jeszcze taki sposób:

TLabel pl = dynamic_cast<TLabel>(Sender); ...
... i w pl, mamy wszystko od Sendera.

Pozdrawiam!

0

Ten jest nieco lepszy, bo w przypadku gdy Sender nie jest obiektem typu TLabel to w pl bedzie NULL (o ile pamietam). Ten pierwszy zrzutuje 'na chama'.

0

AV 0x0000000 czy AV 0x0085A8D68 wszystko jedno :p No chyba, że damy if'a, ale jaki to ma sens jeśli procedura obsługuje tylko TLabel'e
dynamic_cast przydałby się tylko gdy obsługujemy obiekty różnych typów.

0

No nie wszystko jedno, bo wiesz, ze cos poszlo nie tak :) A jak obluguje tylko labele to obydwa sposoby sa ok, bo i tak uda sie rzutowanie.

0
adf88 napisał(a)

ShowMessage(AnsiString("Kliknieto label o nazwie ") + ((TLabel*)Sender)->Name);
to działa, ale jest niezalecane (spadek po C).

Raczej powinno być tak:

ShowMessage(AnsiString("Kliknieto label o nazwie ") + dynamic_cast<TLabel*>(Sender)->Name);

a dla purystów:

TLabel * label = dynamic_cast<TLabel*>(Sender);
if(label) // czy konwersja była poprawna?
    ShowMessage(AnsiString("Kliknieto label o tytule: ") + label->Caption);
0
Marek Bis napisał(a)
adf88 napisał(a)

ShowMessage(AnsiString("Kliknieto label o nazwie ") + ((TLabel*)Sender)->Name);
to działa, ale jest niezalecane (spadek po C).
Zależy od kontekstu. Jeśli jesteśmy pewni, że pod wskaźnikiem jest to co trzeba to szkoda dodatkowego narzutu jakim jest dynamic_cast.
Poza tym z tego co pamietam w c++ nie zawsze było rtti i dynamic_cast.

0

adf88, wszystko racja, dynamic_cast powoduje narzut, dokładnie!

dlatego bez sensu go używać tam, gdzie mamy pewność wszystkiego. VCL rzutowanie wymusza bez przerwy, bo taką ma zrąbaną strukturę. Poza tym, właśnie tu na forum się dowiedziałem, że np do Name Labela można się bezpiecznie dostać rzutując go np na TEdit - ale rzutując na chama, a nie dynamic, który na to nie pozwoli.

dla purystów to można zamiast ((TLabel*)Sender) dać

reinterpret_cast<TLabel*>(Sender) ->

a dla super purystów, to nie żaden if przy dynamic_cast, bo ifa można przeoczyć przecież :] "Koniecznie":

TLabel& label = dynamic_cast<TLabel&>(*Sender);
label.Caption = ...

co oprócz niemożliwości przeoczenia wyjątku daje niepowtarzalne uczucie dostępu do właściwości VCL poprzez . a nie -> :P

//q: niemożność przeoczenia wyjatku.. piękny tekścior Ranides :)

0

Wszystko racja, narzut jest, ale jeśli ktoś pisze w Builderze to raczej nie przejmuje się narzutami.
Gdyby narzut był duży - zgoda, ale tu ważniejsze jest utrzymanie kodu, więc dynamic_cast w obu wersjach (wskaźnikowej albo lepiej referencyjnej) jest wskazany.
Jest jeszcze oczywiście boost, który oferuje odmianę polymorphic_cast dla wskaźników z rzucaniem wyjątku std::bad_cast().

0

W sumie macie rację, jednak praktycznie od mojej strony szkoda mi męczyć palce na wpisywanie czy wstawianie tych cast'ów :p Nigdy jeszcze nie miałem problemów ze złym rzutowaniem.

0

Ciesze się, że podjeliście dyskusję na ten temat. Jeszcze raz dziękuję i pozdrawiam :]

1 użytkowników online, w tym zalogowanych: 0, gości: 1