|
|
| Line 92: |
Line 92: |
| | } | | } |
| | | | |
| − | ====Locating Objects in the Object Tree====
| |
| − |
| |
| − | After the complete object tree is created, there is no access to any object except ''Application'' and ''Window'', as pointers to them are kept in global variables. A way to access other objects (in fact all of them except of groups) is needed. There are a few ways to do this:
| |
| − | * Adding more global variables. This is the simplest way and may work well in such a simple project. The disadvantage is it breaks object oriented design principles (like data encapsulation) and creates a mess when number of global variables reaches 50, 100 or more.
| |
| − | * Store pointers in fields of some subclass instance data (for example ''Application'' one). A good idea, but a bit tedious to implement. Object's instance data area does not exist until the object is fully created and the ''Application'' object is created as the last one. Then pointers to subobjects have to be stored in some temporary variables.
| |
| − | * Use ''MUIA_UserData'' attribute and ''MUIM_FindUData()'' method to find objects dynamically. This is the best solution when objects are accessed rarely (for example once, just to set notifications). For frequently accessed objects (let's say several times a second) it may be combined with caching objects' pointers in an instance data of some subclassed object.
| |
| − | The last approach works as follows: every object to be searched has the ''MUIA_UserData'' attribute set to some predefined unique value. Then at any time the object may be found by this value using ''MUIM_FindUData()'' method on a direct or indirect parent objects (it may be the ''Window'' or ''Application'' object).
| |
| − |
| |
| − | #define OBJ_BUTTON_FFT 36
| |
| − |
| |
| − | /* Somewhere in the constructor of the button */
| |
| − | MUIA_UserData, OBJ_BUTTON_FFT,
| |
| − | /* ... */
| |
| − |
| |
| − | /* Let's get the pointer to FFT button now */
| |
| − |
| |
| − | Object *fft_button;
| |
| − |
| |
| − | fft_button = (Object*)DoMethod(Application, MUIM_FindUData, OBJ_BUTTON_FFT);
| |
| − |
| |
| − | This operation is so common, that it is usually encapsulated in a macro:
| |
| − |
| |
| − | #define findobj(id, parent) (Object*)DoMethod(parent, MUIM_FindUData, id)
| |
| − |
| |
| − | fft_button = findobj(OBJ_BUTTON_FFT, Application);
| |
| | --> | | --> |
Revision as of 14:43, 4 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.
