Programowanie sterowane zdarzeniami, notyfikacje

Grzegorz Kraszewski

---

Ten artykuł w innych językach: angielski

Programowanie sterowane zdarzeniami

Naturalną konsekwencją wynalezienia i późniejszego rozwoju graficznych interfejsów użytkownika było powstanie programów sterowanych zdarzeniami. Większość tradycyjnych programów uruchamianych z linii komend działa potokowo: dane są ładowane, przetwarzane i zapisywane. W programach tych nie ma interakcji z użytkownikiem, albo jest ograniczona do prostego wyboru parametrów przetwarzania danych. Interfejs graficzny zasadniczo to zmienia. Program używający interfejsu graficznego po inicjalizacji wyświetla okno z tymże interfejsem i czeka na poczynania użytkownika. Fragmenty programu są wykonywane w odpowiedzi na akcje w rodzaju kliknięcie gadżetu, czy wciśnięcie klawisza. Po wykonaniu odpowiedniej funkcji program wraca do czekania. W ten sposób przebieg wykonywania się programu jest określony nie przez jego kod, ale przez zdarzenia zewnętrzne generowane przez użytkownika, a dostarczane programowi przez system operacyjny. To podstawowa idea programowania sterowanego zdarzeniami.

Rys. 1. Przebieg wykonania programu sterowanego zdarzeniami.

Notyfikacje w MUI

Do odbierania i przetwarzania zdarzeń generowanych przez użytkownika można podejść na dwa sposoby. Jeden z nich można nazwać podejściem scentralizowanym, drugi – zdecentralizowanym. Dekodowanie zdarzeń w wersji scentralizowanej składa się z rozbudowanego wyrażenia warunkowego (najczęściej konstrukcja switch, ale bywa też długa kaskada if-ów) znajdującego się w głównej pętli algorytmu z rys. 1. Po zidentyfikowaniu każdego zdarzenia, wykonywana jest odpowiadająca mu procedura. Zdecentralizowana obsługa zdarzeń, to nowsza idea, która rozpowszechniła się wraz z programowaniem obiektowym. W tym przypadku biblioteka tworząca GUI sama odbiera i przetwarza zdarzenia, a następnie mapuje je na zmiany atrybutów obiektów GUI (na przykład kliknięcie na przycisk myszą, zmienia jego atrybut na "wciśnięty"). Następnie autor programu może przypisać akcje wykonywane przez program do określonych zmian atrybutów wybranych obiektów. Robi się to poprzez ustawianie notyfikacji na obiektach.

MUI odbiera i rozpoznaje zdarzenia w sposób zdecentralizowany. Wszystke zdarzenia są tłumaczone na zmiany atrybutów różnych obiektów interfejsu. Zazwyczaj są to po prostu gadżety w oknie programu, ale niektóre zdarzenia mogą być mapowane na atrybuty obiektu okna lub obiektu aplikacji (ten ostatni nie ma widzialnej reprezentacji na ekranie). Po stworzeniu kompletnego drzewa obiektów, ale przed wejściem do głównej pętli, program ustawia notyfikacje, przypisując akcje do zmian atrybutów. Notyfikacje mogą być również tworzone i usuwane dynamicznie, jeżeli zachodzi taka potrzeba.

Notyfikacja łączy ze sobą dwa obiekty. Obiekt źródłowy wyzwala zdefiniowaną akcję po zmianie jednego z jego atrybutów. Akcja ta (jest to zawsze metoda) wykonywana jest na obiekcie docelowym. Notyfikację ustawia się wykonując metodę MUIM_Notify() na obiekcie źródłowym. Argumenty tej metody można podzielić na dwie grupy: grupę źródła i grupę celu. Ogólna postać wywołania MUIM_Notify() wygląda następująco:

DoMethod(zrodlo, MUIM_Notify, atrybut, wartosc, cel, ilosc_parametrow, akcja, /* parametry */);

Pierwsze cztery argumenty tworzą grupę źródła, pozostałe grupę celu. Całe wywołanie można "przetłumaczyć" na ludzki język następująco:

Kiedy źródło zmieni swój atrybut na określoną wartość,
wykonaj metodę akcja na obiekcie cel z parametrami.

Pozostał nam jeden nieobjaśniony argument nazwany ilość_parametrów. To po prostu ilość parametrów MUIM_Notify(), jakie występują po tym argumencie. Minimalna ilość parametrów to 1 (identyfikator metody do wykonania), górnym limitem jest jedynie zdrowy rozsądek.

Notyfikacja zostaje wyzwolona, gdy atrybut wyzwalający zostaje ustawiony na wskazaną wartość. Często chcemy wyzwolić notyfikację przy każdej zmianie atrybutu, niezależnie od wartości. Jako wartość wyzwalającą należy wtedy podać predefiniowaną stałą MUIV_EveryTime.

Akcja wykonywana na obiekcie docelowym może być dowolną metodą tego obiektu. MUI posiada kilka metod specjalnie zaprojektowanych pod kątem użycia ich w notyfikacjach. Są to metody klasy Notify, po której dziedziczą wszystkie klasy MUI:

MUIM_Set() to inny sposób na ustawienie atrybutu obiektu, używany w sytuacji gdy notyfikacja powinna ustawić atrybut obiektu docelowego. Metoda OM_SET() się tu nie nadaje, ponieważ jako argumentu wymaga taglisty zawierającej atrybuty do ustawienia. Taglista ta nie może być dynamicznie zbudowana z argumentów i w związku z tym musi być zdefiniowana oddzielnie. MUIM_Set() natomiast ustawia jeden atrybut na podaną wartość. Atrybut i jego wartość są podawane bezpośrednio jako dwa oddzielne argumenty tej metody. Notyfikacja poniżej otwiera okno po naciśnięciu przycisku.

DoMethod(przycisk, MUIM_Notify, MUIA_Pressed, FALSE, okno, 3, MUIM_Set, MUIA_Window_Open, TRUE);

Osoby dopiero poznające MUI mogą być zaskoczone, że wartością atrybutu MUIA_Pressed wyzwalającą notyfikację jest FALSE. Jest to związane z domyślnym zachowaniem się przycisków. Przycisk uruchamia akcję, gdy lewy przycisk myszy jest zwalniany, a więc na końcu kliknięcia. Atrybut MUIA_Pressed otrzymuje wartość TRUE gdy przycisk myszy jest wciskany a następnie FALSE, gdy przycisk myszy jest zwalniany, dlatego notyfikacja jest na wartość FALSE.

MUIM_NoNotifySet() działa podobnie jak MUIM_Set(), ale jest jedna istotna różnica. Ustawienie atrybutu przy pomocy tej metody nie wyzwala ewentualnych notyfikacji ustawionych na ten atrybut na obiekcie docelowym. Często ustawia się atrybuty tą metodą w celu uniknięcia zapętlania się notyfikacji, dlatego jest stosowana nie tylko jako akcja notyfikacji, ale również samodzielna metoda.

MUIM_MultiSet() daje możliwość ustawienia jednej wartości tego samego atrybutu dla wielu obiektów jednocześnie. Obiekty podaje się jako kolejne parametry metody, listę tę zakończa się wskaźnikiem zerowym. Poniższy przykład ustawia atrybut MUIA_Disabled na wartość TRUE trzem przyciskom:

DoMethod(checkmark, MUIM_Notify, MUIA_Selected, FALSE, application, 7, MUIM_MultiSet,
 MUIA_Disabled, TRUE, button1, button2, button3, NULL);

Co ciekawe obiekt będący celem notyfikacji jest tu zupełnie nieistotny, musi to być jednak wskaźnik do jakiegoś istniejącego obiektu. Najczęściej do tego celu używa się obiektu aplikacji albo źródłowego obiektu notyfikacji.

MUIM_CallHook() wywołuje funkcję programu, tzw. hooka. Metoda ta jest często nadużywana przez programistów unikających tworzenia własnych klas i implementowania funkcjonalności programu w metodach takich klas. Wywołanie wprost metody własnej klasy jako akcji notyfikacji jest prostsze i szybsze, niż wywołanie hooka poprzez MUIM_CallHook(). Dodatkowo hook wymaga zdefiniowania dodatkowych struktur - struktury Hook oraz tak zwanej "bramki" – struktury EmulLibEntry.

MUIM_Application_ReturnID() zwraca 32-bitową liczbę całkowitą do głównej pętli programu. Korzystając z tej metody można zmienić zdecentralizowaną obsługę zdarzeń w scentralizowaną. Początkujący programiści lubią nadużywać tej metody przekierowując wszystkie notyfikacje do głównej pętli programu, umieszczając tam następnie duże wyrażenie switch. Mimo, że ta technika programowania wydaje się prosta, należy jej unikać i raczej implementować funkcje programu jako metody własnych klas tworzonych jako podklasy standardowych klas MUI. Wykonywanie dużych ilości kodu wewnątrz głównej pętli MUI zwiększa czas reakcji na zdarzenia. Jedynym w pełni uzasadnionym przypadkiem użycia MUIM_Application_ReturnID() są notyfikacje powodujące wyjście z programu, używające specjalnego identyfikatora MUIV_Application_ReturnID_Quit.

Wykorzystanie wartości wyzwalającej

Kiedy akcją notyfikacji jest ustawienie wartości jakiegoś atrybutu w obiekcie docelowym, bardzo często chcemy przekazać wartość, która wyzwoliła notyfikację, do obiektu docelowego. Jest to bardzo proste, jeżeli notyfikacja jest ustawiona na jedną, konkretną wartość atrybutu. Inaczej to wygląda, gdy wyzwolenie notyfikacji następuje przy każdej zmianie wartości atrybutu (przez użycie MUIV_EveryTime). Rozwiązaniem jest użycie specjalnej stałej MUIV_TriggerValue jako pozornej wartości atrubutu przy definiowaniu notyfikacji. Przy każdym wyzwoleniu notyfikacji stała ta jest zastępowana aktualną wartością atrybutu. Druga predefiniowana stała MUIV_NotTriggerValue może być zastosowana do atrybutów logicznych (TRUE/FALSE) i zastępowana jest logiczną negacją aktualnej wartości atrybutu.

Pierwszy przykład używa MUIV_Trigger_Value, do wyświetlania wartości suwaka w gadżecie tekstowym:

DoMethod(slider, MUIM_Notify, MUIA_Numeric_Value, MUIV_EveryTime, string, 3,
 MUIM_Set, MUIA_String_Integer, MUIV_TriggerValue);

Drugi przykład łączy notyfikacją checkmarka z przyciskiem. Gdy checkmark jest wybrany, przycisk jest aktywny. "Odznaczenie" checkmarka blokuje przycisk:

DoMethod(checkmark, MUIM_Notify, MUIA_Selected, MUIV_EveryTime, button, 3,
 MUIM_Set, MUIA_Disabled, MUIV_NotTriggerValue);

MUIV_EveryTime, MUIV_TriggerValue i MUIV_NotTriggerValue są zdefiniowane jako konkretne liczby 32-bitowe. Dlatego nie da się ustawić notyfikacji na wartość atrybutu równą 1 233 727 793 (wartość dla MUIV_EveryTime). Nie można też zdefiniować akcji polegającej na ustawieniu wartości atrubutu na obiekcie docelowym na liczbę 1 233 727 793 (MUIV_TriggerValue) ani liczbę 1 233 727 795 (MUIV_NotTriggerValue).

Zapętlone notyfikacje

Większy program w MUI może mieć zdefiniowane setki notyfikacji. Zmiana wartości jednego atrybutu może spowodować kaskadę notyfikacji. Może się okazać, że taka kaskada zawiera zamknięte pętle. Najprostszym przykładem takiej pętli jest para obiektów notyfikujących się wzajemnie. Przypuśćmy, że mamy dwa suwaki, które powinny być ze sobą sprzężone, to znaczy przesunięcie jednego suwaka powinno również przesuwać drugi. Można to osiągnąć dwiema notyfikacjami.

DoMethod(slider1, MUIM_Notify, MUIA_Numeric_Value, MUIV_EveryTime, slider2, 3,
 MUIM_Set, MUIA_Numeric_Value, MUIV_Trigger_Value); 
DoMethod(slider2, MUIM_Notify, MUIA_Numeric_Value, MUIV_EveryTime, slider1, 3,
 MUIM_Set, MUIA_Numeric_Value, MUIV_Trigger_Value); 

Kiedy użytkownik ustawi suwak slider1 na wartość np. 13, zostanie wyzwolona pierwsza notyfikacja, przesuwając suwak slider2 również do wartości 13. To z kolei wyzwoli drugą notyfikację, która to notyfikacja ustawi pierwszy suwak na 13, a to z kolei po raz drugi uruchomi notyfikację pierwszą... Pętla mogłaby krążyć w nieskończoność. Na szczęście MUI jest przygotowane na taką okoliczność. Rozwiązanie jest bardzo proste: jeżeli atrybut jest ustawiany na wartość równą jego wartości aktualnej, notyfikacje na ten atrybut w danym obiekcie są ignorowane. W naszym przykładzie pętla będzie przerwana po tym jak druga notyfikacja spróbuje ustawić wartość 13 (równą aktualnej) na obiekcie slider1.

Idealna pętla główna

Idealna pętla główna programu w MUI powinna praktycznie nie zawierać kodu. Wszystkie akcje programu powinny być obsługiwane notyfikacjami. Oto kod takiej pętli:

ULONG signals = 0;

while (DoMethod(application, MUIM_Application_NewInput, (ULONG)&signals)
 != (ULONG)MUIV_Application_ReturnID_Quit)
{
  signals = Wait(signals | SIGBREAKF_CTRL_C);
  if (signals & SIGBREAKF_CTRL_C) break;
}

Zmienna signals zawiera maskę bitową sygnałów wysyłanych do programu przez system operacyjny. Wartością początkową tej maski jest 0, co oznacza brak sygnałów. Kiedy metoda MUIM_Application_NewInput() zostaje wykonana na obiekcie aplikacji, MUI ustawia w tej zmiennej bity sygnałów, których się spodziewa. Z reguły są to sygnały z portów komunikacyjnych okien, gdzie Intuition umieszcza wiadomości o nadchodzących zdarzeniach. Następnie program wywołuje funkcję systemową Wait() z exec.library. Funkcja ta zatrzymuje proces do czasu nadejścia któregokolwiek sygnału, dla którego bit w podanej masce jest jedynką. W trakcie oczekiwania na sygnał proces jest wstrzymany i nie zużywa czasu procesora. Oprócz sygnałów "zamówionych" przez MUI do maski dodawany jest systemowy sygnał CTRL-C. Każdy dobrze napisany program dla MorphOS-a powinien dać się przerwać za pomocą tego sygnału. Sygnał ten może być wysłany z okna konsoli przez wciśnięcie kombinacji klawiszy CTRL + C (stąd nazwa), a także za pomocą TaskManagera i innych narzędzi. W momencie, gdy do programu nadejdzie co najmniej jeden z określonych maską sygnałów, funkcja Wait() wychodzi z powrotem do programu. W przypadku, gdy otrzymano sygnał CTRL-C, pętla ulega zakończeniu. Pozostałe sygnały są tłumaczone przez MUI na zmiany atrybutów poszczególnych obiektów, a następnie wykonywane są przypisane im notyfikacje. Wszystko to odbywa się wewnątrz metody MUIM_Application_NewInput(). Na jej zakończenie aktualizowana jest maska sygnałów. Jeżeli którakolwiek z notyfikacji wykonała na obiekcie aplikacji metodę MUIM_Application_ReturnID(), parametr tej metody jest zwracany jako wynik MUIM_Application_NewInput(). Gdy parametrem tym okaże się być stała MUIV_Application_ReturnID_Quit, pętla ulega przerwaniu.

Każdy dodatkowy kod umieszczony w głównej pętli programu wprowadza opóźnienia w obsłudze i rysowaniu GUI. Jeżeli program wykonuje jakieś zadania silnie obciążające procesor na dłuższy czas, najlepszym sposobem jest wykonywanie tych zadań w procesie potomnym. Obciążanie głównego procesu programu długotrwałymi zadaniami obliczeniowymi powoduje, że program będzie sprawiał wrażenie powolnego i nie reagującego na poczynania użytkownika.