[c++/cli]Argumenty przekazywane przez zdarzenia....

[Slynx]

Zastanawiałem się nad czymś takim

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

System::Void button_OK_Click(System::Object^  sender, System::EventArgs^  e);
 

przykładowa funkcja do obsługi zdarzenia, w tym wypadku kliknięcia w przycisk. Moje pytanie brzmi, czy te 2 argumenty, sender i e są tak na prawdę do czegoś potrzebne ? Jeśli z nich w ogóle nie korzystam w funkcji. A nigdy nie korzystam.
Całkowicie usunąć nie można, by zdarzenie wymaga jakichś argumentów, więc można dać

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

System::Void button_OK_Click(System::Object^, System::EventArgs^ );
 

Zmienne nie zostaną utworzone, a typy zostaną przekazane. Jednak może ktoś się orientuje, czy nie poniesie to ze sobą dalszych konsekwencji ?

(Dlaczego o to pytam i się z tym bawię ? Włączyłem sobie 4 lvl "warningów" i od razu zasypał mnie informacją o "unreferenced formal parameter", więc pomyślałem, że można by się tego pozbyć)

[polymorphism]

Zmienne nie zostaną utworzone, a typy zostaną przekazane.

Te zmienne to parametry, więc utworzone będą, tylko nie będziesz mógł się do nich odwołać. I nie typy zostaną przekazane, tylko wartości.

czy nie poniesie to ze sobą dalszych konsekwencji ?

Nie.

Moje pytanie brzmi, czy te 2 argumenty, sender i e są tak na prawdę do czegoś potrzebne ?

sender to obiekt, który wygenerował zdarzenie. Ma on znaczenie, jeśli pod jedną obsługę zdarzenia podłączysz kilka przycisków. e to argumenty zdarzenia, tzn. to, co sender wysyła obsłudze zdarzenia.

[Cyfrowy Baron]

Jednak może ktoś się orientuje, czy nie poniesie to ze sobą dalszych konsekwencji ?

Nie wiem jak to jest w C++/CLI, ale u mnie w C++ zdarzenia muszą mieć dokładnie taką postać jaka jest zdefiniowana w bibliotekach. Jeżeli cokolwiek zmienię w zdarzeniu to otrzymam np taki komunikat:

The Button1Click method referenced by Button1->OnClick has an incompatible parameter list. Remove the reference?

Jeżeli podłączę do jakiegoś obiektu dynamicznie funkcję-zdarzenie i nie będzie miła ta funkcja prawidłowej konstrukcji, to zdarzenie nie będzie działać.
Jeżeli jednak zrobię np. tak:

KOD cpp:   �  UKRYJ  �

KOD cpp:   �  POKAŻ  �

void __fastcall TForm1::Button1Click(TObject * )

To zdarzenie działa. Tylko co mi po tym.

---

sender i e są tak na prawdę do czegoś potrzebne ?

Do tego co napisał polymorphism dodam, że Sender się przydaje przy rzutowaniu polimorficznym. ► patrz serwis: Cyfrowy Baron dział: teoria Rzutowanie typów, przypisanie polimorficzne

[Slynx]

Pousuwałem wszystko co niepotrzebne, a po prostu jeśli gdzieś potrzebowałem sendera i e (2-3 funkcje) to dodawałem te zmienne i tyle. Pytałem po prostu ogólnie o całość, bo gdy przy jednym przykładzie coś nie będzie działać to sobie poprawię, ale potem cały kod przeprawiać...

[Cyfrowy Baron]

Tak z ciekawości zapytam: w czym przeszkadzają Tobie te argumenty funkcji?

[Slynx]

W warningu 4 poziom. Tylko dlatego, bo wcześniej mnie to interesowało, ale chciałem sobie skompilować kod na maksymalnych warningach. Poza tym, na 4 lvl zauważyłem też sporo nieodciągnięć, które wcześniej nie były widoczne, a na 4 poziomie ostrzeżeń je wskazał.

[Cyfrowy Baron]

Ja sobie po prostu wyłączyłem ten typ ostrzeżeń...