Klasy pochodne od klasy "Application"

Grzegorz Kraszewski

---

Ten artykuł w innych językach: angielski

Każdy program używający MUI jest (a przynajmniej powinien być) sterowany zdarzeniami. Oznacza to, że program dostarcza zestawu akcji, które mogą być wyzwalane przez użytkownika (najczęściej za pośrednictwem myszy albo klawiatury). Najprostszym sposobem umieszczenia w programie takiego zestawu akcji jest zaimplementowanie ich jako zestawu metod jakiegoś obiektu MUI. Dla prostych aplikacji najlepszym kandydatem do dodania takich metod jest główny obiekt programu klasy Application. Bardziej złożone programy, na przykład używające interfejsu z wieloma oknami dokumentów (ang. multi-document interface), mogą dodawać akcje do innych klas, na przykład do klasy Window.

Why methods? Implementing actions as methods has many advantages:

• Methods may be used directly as notification actions. It saves a programmer from using hook tricks or cluttering the main loop with lots of ReturnID values.
• Methods may be coupled directly with scripting language interface (formerly known as ARexx interface) commands.
• Methods used in notifications are executed immediately in response to user actions. No delay is introduced by the main loop (especially if it is not empty).
• A notification triggering attribute value may be passed directly to a method as its parameter.
• Using methods improves code modularity and object encapsulation. Functionality meant to be handled in the scope of an object is handled in its method, without the code spreading across the project.

In a well designed MUI program, all program actions and functionality are implemented as methods and the program internal state is stored as a set of attributes and internal application instance data fields. An example of such a program is discussed throughly in the MUI Subclassing Tutorial: SciMark2 Port article.