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.

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.

Notification Loops

There may be hundreds of notifications defined in a complex program. Changing an attribute may trigger a notification cascade. It is possible that the cascade contains loops. The simplest example of a notification loop is a pair of objects having notifications on each other. Let's assume there are two sliders which should be coupled together. It means moving one slider should move the other one as well. A set of two notifications can ensure this behaviour.

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); 

When the user moves slider1 to value 13, the first notification triggers and sets slider2 value to 13. This triggers the second notification. Its action is to set slider1 value to 13, which in turn triggers the first notification again. Then the loop triggers itself endlessly... Or rather it would, if MUI had no anti-looping measures. The solution is very simple: if an attribute is set for an object to the same value as the current one, any notifications on this attribute in this object are ignored. In our example the loop will be broken after the second notification sets the value of slider1.

The Ideal MUI Main Loop

The ideal main loop of a MUI program should contain almost no code inside. All actions should be handled with notifications. Here is the code of the loop:

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;
}

The variable signals contains a bit-mask of input event signals sent to the process by the operating system. Its initial value 0 just means "no signals". When the MUIM_Application_NewInput() method is performed on the application object, MUI sets signal bits for input events it expects in the signals variable. These signals are usually signals of application windows' message ports, where Intuition sends input events. Then the application calls the exec.library function Wait(). Inside this function, the execution of the process is stopped. The process scheduler will not give any processor time to the process until one of the signals in the mask arrives. Other than input event signals set by MUI, only the system CTRL-C signal is added to the mask. Every well written MorphOS application should be breakable by sending this signal. It can be sent via the console by pressing the CTRL + C keys, or from tools like the TaskManager. When one of the signals in the mask arrives at the process, the program returns from Wait(). If the CTRL-C signal is detected, the main loop ends. If not, MUI decodes the received input events based on its received signal mask, translates events to changes of attributes of relevant objects and performs the triggered notifications. All this happens inside the MUIM_Application_NewInput() method. Finally the signal mask is updated. If any notification calls the MUIM_Application_ReturnID() method, the identifier passed is returned as the result of MUIM_Application_NewInput(). In the event of receiving the special value MUIV_Application_ReturnID_Quit the loop ends.

Any additional code inserted into the loop will introduce delay in GUI handling and redrawing. If a program does some processor intensive calculations, the best way to deal with them is to delegate them into a subprocess. Loading the main process with computational tasks may result in the program being perceived as slow and unresponsive to user actions.