The CDPD Public Domain Collection for CDTV 3

home *** CD-ROM | disk | FTP | other *** search

/ The CDPD Public Domain Collection for CDTV 3 / CDPDIII.bin / pd / programming / utils / dialoglib / dialog.doc < prev next >

Wrap

Text File | 1993-03-08 | 32KB | 919 lines

dialog.lib release 1.0 alpha - preliminary documentation ========= Copyright ========= The material published in this distribution is Freeware. Copyright © 1993 remains at the author, Stefan Reisner. It may only be re-distributed unmodified and in its present composition. In particular, this copyright notice must be included and must be intact. The library "dialog.lib" may be used freely in any application. When using it in a commercial project, please include a statement of this copyright in the electronic or printed documentation. ======= Contact ======= Please report any bugs you find to: Stefan Reisner >>> sr@ph-cip.uni-koeln.de Aachener Str. 399 5000 Cologne 41 Germany ========== Disclaimer ========== THERE IS NO WARRANTY FOR THE SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE SOFTWARE "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE SOFTWARE IS WITH YOU. SHOULD THE SOFTWARE PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY REDISTRIBUTE THE SOFTWARE AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE SOFTWARE (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE SOFTWARE TO OPERATE WITH ANY OTHER SOFTWARE), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. ================ General Concepts ================ The dialog library may be considered as an automatic builder for special graphical user interfaces, namely what is commonly known as dialog boxes. It deserves the attribute `automatic' because the client (the application that wants to put up a dialog box) only defines the hierarchical relationships (presently only in terms of geometry) between the so-called `elements' of the dialog. The gadget classes provided by GadTools form a subset of the set of available dialog elements (although at present not all kinds of GadTools gadgets are supported). The system is open-ended in the way that other dialog elements may be added without having to change any parts of the library. This means that there may be additional linker libraries containing special-purpose dialog elements that you simply link to your application and have instant access to them. The creation and geometrical arrangement of these elements is left to a `layout engine'. It layouts the contents of the dialog window in a way similar to the way a word processor would layout a page of a document. The library even provides support for handling the events that the dialog window sends to the application, although in its present state this support is only rudimentary. Further work has to be committed to defining not only geometrical but also functional relationships between the dialog elements. =========================================== How to define the structure of a dialog box =========================================== Each dialog element needs to store certain private information during the time it is used. To that purpose, the header file <dialog/dialog.h> defines a data structure DialogElement. The client application must define one instance of DialogElement for each element it is going to use in the dialog and must initialize it prior to the layout process. The library provides a pair of functions initDialogElement() and initDialogElementA() for initializing DialogElement structures: VOID initDialogElementA( DialogElement *de, DialogElement *root, DialogCallback dc, ULONG *error, struct TagItem *taglist ); VOID initDialogElement( DialogElement *de, DialogElement *root, DialogCallback dc, ULONG *error, ULONG first, ... ); The capital `A' at the end of the function name indicates that this function expects an actual TagItem vector being passed to it. You normally use the function without the capital `A' where you pass the tag list conveniently over the stack. These are the arguments: de - a pointer to the DialogElement structure to be initialized root - a pointer to the DialogElement structure that serves as the root element of the dialog (see below). When initializing the root element, pass a NULL pointer here dc - a pointer to a dispatch function. This function determines the type of the dialog element (there is one dispatch function for each `kind' of GadTools gadgets, for example). The dialog library provides dispatch functions for GadTools gadgets and for elements needed to describe the dialog structure. Clients may implement their own dispatchers (see below). For the root element, pass dispatchRoot here. error - a pointer to a ULONG. Before calling initDialogElement() the first time, set *error to DIALOGERR_OK (defined in <dialog/dialog.h>). Then you may call initDialogElement() any number of times and make afterwards one final check if *error still contains DIALOGERR_OK. If not, initialization has failed and you should pass control to the cleanup section of your function. Note that DIALOGERR_OK is explicitly defined as zero to make error checking more convenient. taglist - a tag list describing the properties of the dialog element. The set of recognized tag labels depends on the element type (as determined by the dispatcher you specified). The following code fragment gives an example: DialogElement root, element; ULONG error = DIALOGERR_OK; initDialogElement( &root, NULL, dispatchRoot, &error, DA_Screen, myScreen, DA_Member, &element, TAG_DONE ); initDialogElement( &element, &root, dispatchButton, &error, NGDA_TextAttr, myTextAttr, NGDA_VisualInfo, myVisualInfo, NGDA_GadgetText, "press here...", DA_Termination, TRUE, TAG_DONE ); if( error != DIALOGERR_OK ) goto cleanup; The root element is essential to every dialog. It forms the top of the hierarchy. Specify the DA_Member attribute to specify the dialog element that continues the hierarchy. In this example, the hierarchy is continued with a button (a GadTools BUTTON_KIND gadget). Since the button has no substructure (is a `leaf' in the hierarchical tree), the hierarchy ends here. Note that all dialog elements that are based on GadTools need the NGDA_TextAttr and the NGDA_VisualInfo attributes. There are some other attributes defined in <dialog/dialog.h> that relate to fields of the NewGadget structure, too. These include NGDA_GadgetText and NGDA_Flags. The DA_Termination attribute indicates that this element is a `terminal' one: activating a terminal element ends the dialog (the build-in function runSimpleDialog() respects this rule). There may be several terminal elements, for example an `ok' and a `cancel' button. After this initialization phase, the (geometrical) structure of the dialog box is well-defined and the dialog box can be realized. ============================= How to realize the dialog box ============================= The easiest way to conduct the dialog that hides away as much fuzz as possible is to invoke runSimpleDialog(). runSimpleDialog() will - determine the geometrical space requirements of the dialog - open an appropriately sized Intuition Window - layout the dialog (which creates the gadgets on the run) - attach the gadgets to the window - process incoming IDCMP events until the activation of a terminal element is detected - return the address of the terminating DialogElement structure. We, however, want to consider this process in detail, since there are many cases where runSimpleDialog() does not provide enough flexibility. You should never find a reason to get involved with the geometrical and layout aspects directly. The library provides the functions openDialogWindow() and openDialogWindowA() which do this for you: ULONG openDialogWindow( DialogElement *root, ULONG first, ... ); ULONG openDialogWindowA( DialogElement *root, struct TagItem *taglist ); error = openDialogWindow( &root, WA_Title, "Dialog", TAG_DONE ); The arguments are root - the pointer to the dialog's root element (initialized) taglist - a tag list that allows you to control some aspects of the dialog window. Recognized attributes are: WA_Title, - the window title WA_Left, WA_Top - the window position (default: centered on screen) WA_InnerWidth, WA_InnerHeight - the *minimal* dimensions of the window's interior (default: as small as possible) Do not specify other window attributes in this tag list! Note that you may specify other window attributes in the root element's tag list (see dispatchRoot documentation). The return value is either DIALOGERR_OK (success) or some other error code as defined in <dialog/dialog.h>, indicating failure. Note that DIALOGERR_OK is explicitly defined as zero to make error checking more convenient. When successful, openDialogWindow() has opened the window, created the gadgets and attached them to the window. Note that the window's IDCMP flags are automatically determined by ORing together the IDCMP requirements of all dialog elements. Never change any IDCMP flags of a dialog window! The window is always opened on the screen specified by DA_Screen in the root element's tag list (as CUSTOMSCREEN). Therefore, you must make sure that the screen remains open as long as the window exists (shouldn't pose a problem). Note that this proceeding is sanctioned by the RKRM for transient windows. For event processing we need the Window pointer. It must be obtained using the library function getDialogWindow(): struct Window *getDialogWindow( DialogElement *root ); window = getDialogWindow( &root ); Simply pass the root DialogElement pointer to it. Note that this function will return NULL except when called after openDialogWindow() and before closeDialogWindow() (see below). Having obtained the Window pointer, we can start processing IntuiMessages. Note that GT_GetIMsg() and GT_ReplyIMsg() must be used as soon as GadTools gadgets have been created (which is probably the case unless you have implemented new dispatchers that are based on conventional gadgets or BOOPSI classes). The first thing to do with a received IntuiMessage is to pass it to mapDialogEvent(): DialogElement *mapDialogEvent( DialogElement *root, struct IntuiMessage *imsg ); match = mapDialogEvent( &root, imsg ); The return value is a pointer to a DialogElement structure or NULL. When non-NULL it points to the element that `originated' the event. This includes keyboard shortcuts and additional events (see below). A dialog element will respond to additional IDCMP event classes as specified by DA_MatchEventClasses in its tag list. Typical example usages include IDCMP_CLOSEWINDOW and IDCMP_DISKINSERTED. Note that the attribute DA_MatchEventCode and DA_MatchEventQualifier are not supported yet. You should test then whether the respective element is terminal or not. If it is terminal, you should exit the event loop as soon as possible. The rest of the event processing is up to you: If some dialog elements are supposed to trigger some specific action, this is the place to do it. When you are done with the event, pass it back to GT_ReplyIMsg(). After leaving the event loop you must close the dialog window again. This is accomplished by passing the root element to closeDialogWindow(). You only have to call closeDialogWindow() if openDialogWindow() did succeed. =============================================== How to cleanup after having finished the dialog =============================================== initDialogElement() allocates certain data structures dynamically. The bound system resources must be freed before the scope of the DialogElement instance ends. This is done by passing the pointer to the DialogElement to clearDialogElement(): VOID clearDialogElement( DialogElement *de ); To continue the above example, one would write cleanup: clearDialogElement( &element ); clearDialogElement( &root ); ============= Test examples ============= There are seven small example programs included that demonstrate the usage of the library. Almost all currently supported GadTools kinds appear (integer and number have been omitted but string and text are included). ============================== Dialog element class reference ============================== The currently implemented dialog element classes are: Root HStack VStack HCons VCons HBumper VBumper HSpring VSpring Button /* GadTools */ CheckBox /* GadTools */ String /* GadTools */ Integer /* GadTools */ ListView /* GadTools */ MX /* GadTools */ Cycle /* GadTools */ Text /* GadTools */ Number /* GadTools */ The class that a DialogElement instance belongs to is determined by the dispatcher callback pointer that is passed to initDialogElement(). The dispatcher for the class XXX is a C language function with the following prototype: ULONG dispatchXXX( struct Hook *, DialogElement *, DialogMessage * ); This information is provided just for understanding; you never actually call a dispatcher hook directly. The subject of implementing new dispatchers is not covered by this document. The dispatcher must examine the DialogMessage passed to it and take action depending on the MethodID that it contains. The methods that dispatchers must support include - inquiring the element's geometrical structure - setup & determination of the element's geometrical space requirements - layout - cleanup - event matching and internal processing (in particular keyboard equivalents) We are going to discuss the properties of each class now is detail. For this discussion there is one thing left to explain: a dialog element is said to have a `structure'. This structure consists in the existence of non- existence of a horizontal and/or a vertical `baseline'. People who have worked with the Text section of graphics.library should be familiar with the term `baseline'. A single line of text only and always has a horizontal baseline. We have extended this conception for dialog elements in that they may also have a vertical baseline. It is in fact quite obvious which structure certain elements have: Consider for example a GadTools button. There is a line of text centered on the button. Therefore, we let the button inherit the horizontal baseline of the text (and no vertical baseline). Now consider a GadTools string entry gadget with the label placed to the left as it is default: Both the label and the text the user enters in the gadget have (the same) horizontal baseline. But in addition to that, the gadget is obviously divided horizontally into two distinct parts: the label and the entry field. Therefore, we say that this element also has a vertical baseline (identical to the left edge of the entry field). What is this good for? Note that just as the text baseline allows us to arrange separate words neatly on a line, our extended notion of structured dialog elements allows us to arrange several (similar) elements in either horizontal or vertical direction in a way that looks nice and tidy to the user. You can for instance arrange five string entry gadgets (with labels to their left) in a vertical `stack'. The layout engine build into the dialog library will then by default align the left edges of the entry fields, causing the labels to appear on the left and the entry fields on the right of one continuous vertical line in the dialog box! =============================================================================== Class: Root Dispatcher: dispatchRoot Purpose: Anchor to the hierarchy of dialog elements; serves as a handle for many library functions. Parameters that are global to the dialog are passed to this. Structure: no baselines Attributes: DA_Screen Screen * specifies the screen on which to open the dialog window. Must be specified! DA_Member DialogElement * specifies the element that goes below the root in the hierarchy. DA_XSpacing LONG specifies a horizontal spacing. This value determines the width of HBumpers and of the padding between window frame and the dialog imagery. Default: INTERWIDTH (defined in <libraries/gadtools.h>) DA_YSpacing LONG specifies a vertical spacing. This value determines the height of VBumpers and of the padding between window frame and the dialog imagery. Default: INTERHEIGHT (defined in <libraries/gadtools.h>) Any window attributes except WA_Left, WA_Top, WA_InnerWidth, WA_Width, WA_InnerHeight, WA_Height, WA_IDCMP, WA_SimpleRefresh, WA_CustomScreen to customize the dialog window's appearance and behaviour. =============================================================================== Class: HStack Dispatcher: dispatchHStack Purpose: Stack an arbitrary number of elements horizontally (side by side). Structure: horizontal baseline if every member has one Attributes: DA_Member DialogElement * (multiple) specifies the list of elements to be stacked horizontally. DA_Alignment LONG (-1,0,+1) controls the alignment of the stacked elements in the vertical direction: -1, top alignment: top edges are aligned 0, center alignment: if all members have a horizontal baseline, these (default) will be aligned; else each member is centered vertically within the available space +1, bottom alignment: bottom edges are aligned =============================================================================== Class: VStack Dispatcher: dispatchVStack Purpose: Stack an arbitrary number of elements vertically (side by side). Structure: vertical baseline if every member has one Attributes: DA_Member DialogElement * (multiple) specifies the list of elements to be stacked vertically. DA_Alignment LONG (-1,0,+1) controls the alignment of the stacked elements in the horizontal direction: -1, left alignment: left edges are aligned 0, center alignment: if all members have a vertical baseline, these (default) will be aligned; else each member is centered horizontally within the available space +1, right alignment: right edges are aligned =============================================================================== Class: HCons Dispatcher: dispatchHCons Purpose: Create a pair of a left (car) and a right (cdr) element. Structure: vertical baseline; horizontal baseline if car and cdr have one Attributes: DA_CAR DialogElement * specifies the left element. May be omitted. DA_CDR DialogElement * specifies the right element. May be omitted. =============================================================================== Class: VCons Dispatcher: dispatchVCons Purpose: Create a pair of a top (car) and a bottom (cdr) element. Structure: horizontal baseline; vertical baseline if car and cdr have one Attributes: DA_CAR DialogElement * specifies the top element. May be omitted. DA_CDR DialogElement * specifies bottom right element. May be omitted. =============================================================================== Class: HBumper Dispatcher: dispatchHBumper Purpose: Insert a whitespace with fixed width (see Root, DA_XSpacing); this element is typically used in HStacks. Structure: horizontal baseline Attributes: none Note: HBumpers may be re-used! You only have to prepare one DialogElement and can use it any number of times in your dialog. =============================================================================== Class: VBumper Dispatcher: dispatchVBumper Purpose: Insert a whitespace with fixed height (see Root, DA_YSpacing); this element is typically used in VStacks. Structure: vertical baseline Attributes: none Note: VBumpers may be re-used! You only have to prepare one DialogElement and can use it any number of times in your dialog. =============================================================================== Class: HSpring Dispatcher: dispatchHSpring Purpose: Balance arbitrarily extensible elements in HStacks. Structure: horizontal baseline Attributes: none Note: HSprings may be re-used! You only have to prepare one DialogElement and can use it any number of times in your dialog. =============================================================================== Class: VSpring Dispatcher: dispatchVSpring Purpose: Balance arbitrarily extensible elements in VStacks. Structure: vertical baseline Attributes: none Note: VSprings may be re-used! You only have to prepare one DialogElement and can use it any number of times in your dialog. Springs are very versatile elements that give you great freedom in designing stacks. In particular, consider what happens when a spring is placed at one or both ends of a stack. If you find that the effect of one spring on a stack is insufficient, simply double the spring (doubles the effect). =============================================================================== Class: Button (GadTools) Dispatcher: dispatchButton Purpose: Realize a GadTools button with label and optional keyboard equivalent Structure: horizontal baseline Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR Button label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut (case-insensitive). plus other GadTools or Intuition gadget attributes as they apply to a button. =============================================================================== Class: CheckBox (GadTools) Dispatcher: dispatchCheckBox Purpose: Realize a GadTools checkbox with label and optional keyboard equivalent Structure: horizontal baseline if PLACETEXT_ABOVE or PLACETEXT_BELOW, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR CheckBox label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. The label placement flags determine the element's structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut (case-insensitive). plus other GadTools or Intuition gadget attributes as they apply to a checkbox. =============================================================================== Class: String (GadTools) Dispatcher: dispatchString Purpose: Realize a GadTools string entry gadget with label and optional keyboard equivalent Structure: horizontal baseline, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR String label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. The label placement flags determine the element's structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut (case-insensitive). DA_Storage STRPTR pointer to a buffer that must can take as much characters as is specified by GTST_MaxChars. The text entered by the user is copied there each time a IDCMP_GADGETUP is heard from the gadget. plus other GadTools or Intuition gadget attributes as they apply to a string entry gadget. =============================================================================== Class: Integer (GadTools) Dispatcher: dispatchInteger Purpose: Realize a GadTools integer entry gadget with label and optional keyboard equivalent Structure: horizontal baseline, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR Integer label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. The label placement flags determine the element's structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut (case-insensitive). DA_Storage LONG * The integer that the user has entered is copied to this memory location each time a IDCMP_GADGETUP comes in. plus other GadTools or Intuition gadget attributes as they apply to a integer entry gadget. =============================================================================== Class: ListView (GadTools) Dispatcher: dispatchListView Purpose: Realize a GadTools list view gadget with label and optional keyboard equivalent Structure: horizontal baseline if PLACETEXT_ABOVE or PLACETEXT_BELOW, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR ListView label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. The label placement flags determine the element's structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut. This is only functional if an item is already selected. The unshifted keystroke selects the next item, the shifted keystroke selects the previous item. Note that this is only functional if DA_Storage specifies a valid memory location where to store the currently selected item. DA_Storage LONG * memory location where to store the currently selected item. If this is omitted, the gadget will still work (except for keyboard shortcut), but the client will never know which item the user selected. plus other GadTools or Intuition gadget attributes as they apply to a list view gadget. =============================================================================== Class: MX (GadTools) Dispatcher: dispatchMX Purpose: Realize a GadTools mutually exclusive gadget with optional keyboard equivalent Structure: vertical baseline Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut. The unshifted keystroke activates the next choice (with wrap-around), the shifted keystroke activates the previous choice (with wrap-around). Note that this is only functional if DA_Storage specifies a valid memory location where to store the currently active choice. DA_Storage LONG * memory location where to store the currently active choice. If this is omitted, the gadget will still work (except for keyboard shortcut), but the client will never know which choice the user activated. plus other GadTools or Intuition gadget attributes as they apply to a mutually exclusive gadget. =============================================================================== Class: Cycle (GadTools) Dispatcher: dispatchCycle Purpose: Realize a GadTools cycle gadget with optional keyboard equivalent Structure: horizontal baseline, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR Cycle label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. DA_EquivalentKey UBYTE specifies the keyboard shortcut. The unshifted keystroke activates the next choice (with wrap-around), the shifted keystroke activates the previous choice (with wrap-around). Note that this is only functional if DA_Storage specifies a valid memory location where to store the currently active choice. DA_Storage LONG * memory location where to store the currently active choice. If this is omitted, the gadget will still work (except for keyboard shortcut), but the client will never know which choice the user activated. plus other GadTools or Intuition gadget attributes as they apply to a cycle gadget. =============================================================================== Class: Text (GadTools) Dispatcher: dispatchText Purpose: Realize a GadTools text display gadget Structure: horizontal baseline, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR Text label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. plus other GadTools or Intuition gadget attributes as they apply to a text gadget. =============================================================================== Class: Number (GadTools) Dispatcher: dispatchNumber Purpose: Realize a GadTools number display gadget Structure: horizontal baseline, vertical baseline if PLACETEXT_LEFT or PLACETEXT_RIGHT Attributes: NGDA_TextAttr struct TextAttr * pointer to a TextAttr structure. This goes into the ng_TextAttr field of the NewGadget structure. NGDA_VisualInfo APTR APTR to the private VisualInfo structure. This goes into the ng_VisualInfo field of the NewGadget structure. NGDA_GadgetText STRPTR Number label. This goes into the ng_GadgetText field of the NewGadget structure. NGDA_Flags ULONG Flags. This goes into the ng_Flags field of the NewGadget structure. plus other GadTools or Intuition gadget attributes as they apply to a number gadget.