Difference between revisions of "Subclassing Application Class"
From MorphOS Library
(→Methods and Attributes: Section removed, does not belong here.) |
m (Commented out some text to be restructured/moved.) |
||
| Line 2: | Line 2: | ||
| − | |||
Every MUI application is (or at least should be) an event driven one. It means the application provides a set of actions, which may be triggered with user activity (like using mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of metods added to some MUI object. For simple programs, the best candidate for adding such methods is the master ''Application'' object. More complex programs (for example ones using multi-document interface) may add actions to other classes, for example ''Window'' one. | Every MUI application is (or at least should be) an event driven one. It means the application provides a set of actions, which may be triggered with user activity (like using mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of metods added to some MUI object. For simple programs, the best candidate for adding such methods is the master ''Application'' object. More complex programs (for example ones using multi-document interface) may add actions to other classes, for example ''Window'' one. | ||
| Line 13: | Line 12: | ||
| − | + | <!-- | |
====Creating Textfields==== | ====Creating Textfields==== | ||
| Line 118: | Line 117: | ||
fft_button = findobj(OBJ_BUTTON_FFT, Application); | fft_button = findobj(OBJ_BUTTON_FFT, Application); | ||
| + | --> | ||
Revision as of 15:11, 3 January 2011
Grzegorz Kraszewski
Every MUI application is (or at least should be) an event driven one. It means the application provides a set of actions, which may be triggered with user activity (like using mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of metods added to some MUI object. For simple programs, the best candidate for adding such methods is the master Application object. More complex programs (for example ones using multi-document interface) may add actions to other classes, for example Window one.
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 teens 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 of 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 method, as its parameter.
- Using methods improves code modularity.