Programowanie sterowane zdarzeniami, notyfikacje
From MorphOS Library
Grzegorz Kraszewski
Ten artykuł w innych językach: angielski
Contents
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.
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:
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.
Reusing Triggering Value
When the action of a notification is to set an attribute in the target object, it is often desired to forward the triggering value to the target object. It is very easy, when the notification is set to occur on a particular value. Things change however, when the notification is set to occur on any value with MUIV_EveryTime. A special value MUIV_TriggerValue may be used for this. It is replaced with the actual value of the triggering attribute at every trigger. Another special value, MUIV_NotTriggerValue is used for boolean attributes and is replaced by a logical negation of the current value of the triggering attribute.
The first example uses MUIV_Trigger_Value, to display the value of a slider in a string gadget:
DoMethod(slider, MUIM_Notify, MUIA_Numeric_Value, MUIV_EveryTime, string, 3, MUIM_Set, MUIA_String_Integer, MUIV_TriggerValue);
The second example connects a checkmark with a button. When the checkmark is selected, the button is enabled. Deselecting the checkmark disables the button:
DoMethod(checkmark, MUIM_Notify, MUIA_Selected, MUIV_EveryTime, button, 3, MUIM_Set, MUIA_Disabled, MUIV_NotTriggerValue);
MUIV_EveryTime, MUIV_TriggerValue and MUIV_NotTriggerValue are defined as particular values in the 32-bit range. Because of this, it is impossible to set a notification on the value 1 233 727 793 (which is MUIV_EveryTime). It is also impossible to set the value to a fixed number 1 233 727 793 (MUIV_TriggerValue) or 1 233 727 795 (MUIV_NotTriggerValue) using MUIM_Set() in a notification.
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.