Difference between revisions of "Subclassing Application Class"

From MorphOS Library

(Moving out hidden contents.)
(Crosslinking++;)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
''Grzegorz Kraszewski''
 
''Grzegorz Kraszewski''
 +
----
 +
<small>This article in other languages: [[Klasy pochodne od klasy "Application"|Polish]]</small>
  
  
−
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 Programming, Notifications|event driven]] one. This means the application provides a set of actions, which may be triggered with user activity (like using the mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of methods 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 a multi-document interface) may add actions to other classes, for example the ''Window'' class.
  
 
Why methods? Implementing actions as methods has many advantages:
 
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 used directly as [[Event Driven Programming, Notifications#Notifications in MUI|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 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).
+
* 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 method, as its parameter.  
+
* A notification triggering attribute value may be [[Event Driven Programming, Notifications#Reusing Triggering Value|passed directly]] to a method as its parameter.  
−
* Using methods improves code modularity.
+
* 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.
−
<!--
 
−
 
 
−
====Creating Textfields====
 
−
 
 
−
The ''Text'' MUI class is used not only for creating static texts or labels (like in the [["Hello world!" in MUI|"Hello World!" example]]), but also framed readonly text gadgets and textual buttons. All these object differ only in attributes. A read-only framed text field has a specific background and frame:
 
−
 
 
−
Object* create_resdisplay(void)
 
−
{
 
−
  Object *obj;
 
−
 
−
  obj = MUI_NewObject(MUIC_Text,
 
−
    MUIA_Frame, MUIV_Frame_Text,
 
−
    MUIA_Background, MUII_TextBack,
 
−
  TAG_END);
 
−
 
−
  return obj;
 
−
}
 
−
 
 
−
====Creating Buttons====
 
−
As said above, a text button is an instance of the ''Text'' class too. It has more attributes than a plain label however. ''MUIA_Text_PreParse'' attribute centers the text in the object using a control code of the [[MUI text engine]]. After setting a frame and a background, a proper font is also specified with ''MUIA_Font''. Forgetting this attribute is one of common interface design errors. Next four attributes are related to user input. ''MUIA_InputMode'' attribute defines type of button (push or toggle one). ''MUIA_CycleChain'' makes the button reachable with keyboard. Incomplete keyboard support for GUI is another common error and should be avoided. All gadgets receiving user input should have ''MUIA_CycleChain'' set. Most important gadgets should be also reachable with single keys. ''MUIA_ControlChar'' sets a key, which activates the gadget. For textual gadgets a letter of this key should be also underlined with ''MUIA_Text_HiChar''. It implies that the character used should be present in the gadget label. Both these attributes should be set to small letters. ''MUIA_ControlChar'' set to a capital letter will force user to press ''SHIFT''. ''MUIA_Text_HiChar'' is case insensitive. Digits can be also used for control characters, if button labels contain them. Using other characters is strongly discouraged.
 
−
 
 
−
The function is called six times in the code, and creates six pushbuttons. The toggle button "Large Data" is created by very similar ''create_datasize_button()'' function, which differs in ''MUIA_InputMode'' value. As it is used once only, the button label and control character are hardcoded inside the function and not passed as arguments.
 
−
 
 
−
''MUIA_HorizWeight'' and ''MUIA_Text_SetMax'' attributes are used for [[layout control]]. They are described in the autodoc of ''Area'' and ''Text'' class respectively.
 
−
 
 
−
Object* create_button(char *label, char control)
 
−
{
 
−
  Object *obj;
 
−
 
−
  obj = MUI_NewObject(MUIC_Text,
 
−
    MUIA_Text_Contents, (ULONG)label,
 
−
    MUIA_Text_PreParse, "\33c",
 
−
    MUIA_Frame, MUIV_Frame_Button,
 
−
    MUIA_Background, MUII_ButtonBack,
 
−
    MUIA_Font, MUIV_Font_Button,
 
−
    MUIA_InputMode, MUIV_InputMode_RelVerify,
 
−
    MUIA_Text_HiChar, control,
 
−
    MUIA_ControlChar, control,
 
−
    MUIA_CycleChain, TRUE,
 
−
    MUIA_HorizWeight, 1,
 
−
  TAG_END);
 
−
 
−
  return obj;
 
−
}
 
−
 
 
−
====Creating Spacing Bars====
 
−
 
 
−
Horizontal and vertical bars may be used for visual separation of gadgets. They are created using ''Rectangle'' class. In a basic case the class creates just empty rectangles and is used for [[layout control]]. ''MUIA_Rectangle_HBar'' attribute adds a horizontal bar. The object has also height fixed, to avoid its vertical scaling. Bars and grouping frames should be used sparingly.
 
−
 
 
−
Object* create_hbar(void)
 
−
{
 
−
  Object *obj;
 
−
 
−
  obj = MUI_NewObject(MUIC_Rectangle,
 
−
    MUIA_Rectangle_HBar, TRUE,
 
−
    MUIA_FixHeight, 2,
 
−
  TAG_END);
 
−
 
−
  return obj;
 
−
}
 
−
 
 
−
====Creating Gauge====
 
−
 
 
−
A ''Gauge'' object creates a progress bar and an optional text on it. Gauges may be vertical or horizontal, but only horizontal ones can display text. Frame, background and font are specified as usual. An initial text causes the gauge object to have fixed height.
 
−
 
 
−
Object* create_statusbar(void)
 
−
{
 
−
  Object *obj;
 
−
 
−
  obj = MUI_NewObject(MUIC_Gauge,
 
−
    MUIA_Frame, MUIV_Frame_Gauge,
 
−
    MUIA_Font, MUIV_Font_Gauge,
 
−
    MUIA_Background, MUII_GaugeEmpty,
 
−
    MUIA_Gauge_Horiz, TRUE,
 
−
    MUIA_Gauge_InfoText, (ULONG)"Ready.",
 
−
  TAG_END);
 
−
 
−
  return obj;
 
−
}
 
−
 
 
−
-->
 

Latest revision as of 13:49, 27 January 2011

Grzegorz Kraszewski

This article in other languages: Polish


Every MUI application is (or at least should be) an event driven one. This means the application provides a set of actions, which may be triggered with user activity (like using the mouse and keyboard). The straightforward way of implementing this set of actions is to implement it as a set of methods 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 a multi-document interface) may add actions to other classes, for example the Window class.

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.

Retrieved from "https://library.morph.zone/index.php?title=Subclassing_Application_Class&oldid=1221"