Overview
The Window_SupportExternal SWI is used to provide additional functions to extension gadgets. These operations are listed below. Unless otherwise stated, the operations are present in all distributed versions of the Window module.
Technical Details
The reason code is passed in R1. Flags in R0 should be zero unless otherwise stated, and R2 onward are specific to the reason code:
| Reason | Meaning |
|---|---|
| 0 | Create icon |
| 1 | Reserved |
| 2 | Create object |
| 3 | Create gadget |
| 4 | Allocate memory |
| 5 | Free memory |
| 6 | Extend allocated memory |
| 7 | Simple move gadget |
| 8 | Remove icons |
| 9 | Add icons |
| 10 | Call after |
| 11 | Call every |
| 12+ | Reserved |
SWI Calls
| R1 | = | 0 (Create icon) |
| R2 | = | Pointer to wimp icon definition |
| R0 | = | Icon handle or -1 if failed to create |
This call creates a wimp icon from the given definition except when the Window module is in 'plotting' mode.
A C equivalent is available:
int glib_create_icon(WimpCreateIconBlock *i);
| R0 | = | Flags (bit 0 selects the form of R2) |
| R1 | = | 2 (Create object) |
| R2 | = | Pointer to template name (R0 bit 0 clear), or pointer to in memory object definition (R0 bit 0 set) |
| R0 | = | Object id or zero if failed to create |
This call creates a toolbox object and returns its Object id. The reason for using this as opposed to toolbox_create_object (SWI Toolbox_CreateObject) is that the Window module first checks for plotting rather than creation mode. If the Gadget provides a plot handler, then it may safely use Toolbox_CreateObject SWI in its add handler.
| R1 | = | 3 (Create gadget) |
| R2 | = | Object id (must be current Object id) |
| R3 | = | Pointer to gadget definition |
| R4 | = | Tag (&800 to &FFF) |
| R0 | = | Component id or 0 if failed to create |
This call, used for implementing composite gadgets, creates a gadget from the given template definition. The Window module generates a unique Component id for the gadget derived from the tag - It will be of the form &?????ttt. The use of a tag allows improved reaction to events on composite gadgets in that if a Composite Gadget creates all its Gadgets with tag 999, then its event routines can return immediately if the Component id's lower bits do not equal 999. Tags do not require registration, but it is worth advising the maintainers of the Window module so that, where possible, clashes can be avoided. In order to receive Toolbox events a module must register an interest in them - this is described in application note 280. Note that the failure condition returns 0 rather than -1 as with other gadget calls.
A C equivalent is available:
int create_gadget(int o,int *i,int f);
| R1 | = | 4 (Allocate memory) |
| R2 | = | Amount of memory to allocate in bytes |
| R0 | = | Pointer to memory or NULL |
This call allocates memory from the Window module's allocator using either the RMA or the Toolbox dynamic area.
A C equivalent is available:
void *mem_allocate(int amount);
| R1 | = | 5 (Free memory) |
| R2 | = | Pointer to memory to free |
| R0 - R2 | = | Preserved |
This call frees memory that was previously allocated by the Window modules allocator, such as with Window_SupportExternal 4.
A C equivalent is available:
void mem_free(void *tag);
| R1 | = | 6 (Extend memory) |
| R2 | = | Pointer to memory to extend |
| R3 | = | Change in size |
| R0 | = | Pointer to memory or NULL if extend failed |
This call reallocates memory that was previously allocated by the Window modules allocator, such as with Window_SupportExternal 4. The change may be positive or negative to grow or shrink the block accordingly. The pointer to the block may have to change and this is returned in R0. A failure will preserve the original data. Note that this is not an equivalent call to C's 'realloc' function.
A C equivalent is available:
void mem_extend(void *tag, int change);
| R1 | = | 7 (Simple move gadget) |
| R2 | = | Object id of parent object |
| R3 | = | Component id of gadget to move |
| R4 | = | Pointer to new bounding box |
| R1 - R4 | = | Preserved |
This call moves all the icons associated with a gadget to the position specified by the new bounding box in the same manner as the internal gadgets. This call is only present in Window 1.98 and later. Versions of GLib before 0.05 do not use this operation and instead use a method of registering a temporary gadget, performing the move and then deregistering the gadget. The earlier form is strongly discouraged due to its adverse effects on certain versions of the Window module. If you use glib 0.05 or later you should ensure Window 1.98.
The 'type' parameter of the C function is ignored in GLib 0.05 and later.
A C equivalent is available:
void glib_move_gadget(int type, ObjectId obj, ComponentId id, BBox *box);
| R1 | = | 8 (Remove icons) |
| R2 | = | Object id of parent object |
| R3 | = | Component id of gadget to remove |
| R4 | = | Pointer to a list of icon handles, terminated by -1 |
| R1 - R4 | = | Preserved |
This call allows a gadget to inform the Window module that it no longer uses the icon handles given within the list. This allows gadgets to change the number of icons which they use dynamically during their life. This operation is present in Window 1.99 and later.
A C equivalent is available:
void glib_remove_icons(ObjectId obj, ComponentId id, int *icons);
| R1 | = | 9 (Add icons) |
| R2 | = | Object id of parent object |
| R3 | = | Component id of gadget to add |
| R4 | = | Pointer to a list of icon handles, terminated by -1 |
| R1 - R4 | = | Preserved |
This call allows gadgets to inform the Window module that the gadget has created the icon handles given within the list. This allows gadgets to change the number of icons which they use dynamically during their life. This operation is present in Window 1.99 and later.
A C equivalent is available:
void glib_add_icons(ObjectId obj, ComponentId id, int *icons);
| R1 | = | 10 (Call after) |
| R2 | = | Object id of parent object |
| R3 | = | Component id of gadget to register a timer event on |
| R4 | = | Delay in centiseconds, or 0 to remove the call after |
| R1 - R4 | = | Preserved |
This call is used to cause the Window module to call the gadget at its entry point after a number of centiseconds have passed (on a Wimp poll return, so the system is known to be unthreaded). Only a single CallAfter (or CallEvery) may be associated with a gadget. The timer will only begin its operation when the parent window object is shown. It will be removed when the window is hidden. This call is present in versions of Window after 2.03.
A similar function can be used to explicitly remove such a timer:
void glib_gadget_timer_remove(ObjectId object, ComponentId component);
A C equivalent is available:
void glib_gadget_timer_after(ObjectId object, ComponentId component,
int delay);
| R1 | = | 11 (Call every) |
| R2 | = | Object id of parent object |
| R3 | = | Component id of gadget to register a timer event on |
| R4 | = | Delay in centiseconds, or 0 to remove the call every |
| R1 - R4 | = | Preserved |
This call is identical to the CallAfter call except that the callback will recur after each trigger.
A C equivalent is available:
void glib_gadget_timer_every(ObjectId object, ComponentId component,
int delay);