Showing changes from revision #6 to #7:
Added | Removed | Changed
An icon is a rectangular area of a window’s workspace. It can be used to display either text, or a sprite, or both text and sprite, automatically. It needs the help of the application if it is to display something else to the user; for example, a graph displaying share prices.
Icons can also be writable. That is, the Wimp will deal with user input, and also handle certain editing functions such as Delete and left and right cursor movements.
Icons are defined by 32 bytes of data and 12 bytes of data named [[Icon Data]. The icon’s dimensions must also be provided in OS units. A full detailed description of an icon can be found in theIcon Data. The icon’s dimensions must also be provided in OS units. A full detailed description of an icon can be found in the Icon Block page. A quick overview can be found below.
Icons have handles that are unique within the window they reside in. Thus, an icon can be uniquely defined by it’s window/icon handles.
Note: User icon handles begin from zero, whereas system area icons (close, title bar, etc) have negative icon numbers.
Two sets of x and y co-ordinates define the size of the icon within a window.
Thirty two bytes of data are used to specify numerous settings for the icon, such as Border type, horizontal and vertical alignment, colour, font data, how the button responds to button clicks and whether the icon needs help from the application to be redrawn correctly.
The full detailed description is available in the Icon Flags page.
The Icon Data are divided into three three words (4 bytes each). Icons can be configured to use either Direct or Indirect data for the following attributes of an icon:
1 | The text to be displayed in the icon |
2 | The name of the sprite to be displayed within the icon |
3 | Both the text to be displayed and the name of the sprite to be used |
If the data is set as Direct, a 12 character limit is imposed.
If the data is set as Indirect, then there is no limit as to how many character can be used to define the above attributes.
There are three ways that an icon can be created. They are:
1 | Created at the same time as the window. |
2 | Created at run-time. |
3 | Created virtually at run-time using Wimp_PlotIcon during a redraw loop. The advantage of using a virtual icon is that they do not occupy permanent storage. |
Wimp_CreateIcon and Wimp_DeleteIcon are used to create and delete an icon. Two important side effects of using these calls are:
1 | The window is not redrawn. |
2 | The icon handles may change. |
Another method of deleting an icon is to use Wimp_SetIconState. Bit 23 of the window flags when using this call must be set, to ensure that the icon is deleted and not simply redrawn on top of itself.
Icons can be defined to be part of an Exclusive Selection Group(ESG) group. That is, only one icon per ESG can be selected at a given time. The default is for an icon not to be part of any ESG. Note: These are often referred to as Radio Buttons.
When an icon has been selected using the Wimp, the icon colours are inverted, and any other icons in the ESG will be deselected.
Mouse Button Differences
Select | When an icon has been clicked with the Select mouse button it is selected regardless of its previous state. |
Adjust | When an icon is clicked with the Adjust mouse button the state of the icon is toggled between its previous and current state. However, if an icon has its adjust bit set in the window flag, then using the Adjust mouse button to toggle the icon’s state will not have any affect on the other icons within the same ESG. |
An icon can be disabled so it cannot be selected. In this instance, the Wimp shades the icon to denote that it cannot be selected.
Sprites used in an icon can come from the following sources:
1 | The system-sprite pool |
2 | The Wimp sprite pool |
3 | A user defined memory allocation |
However, the use of system-sprites is not recommended as certain operations cannot be performed on them; for example, scaling and colour translation.
Wimp sprites are useful because one copy can be used by many applications.
User-sprites are used when sprites unique to the application are required.
The Wimp-sprite area is divided in two parts: a permanent part held in ROM and a transient expandable part held in the RMA.
The Wimp_SpriteOp allows automatic access to Wimp Sprites by name. This is a read-only access call, and the only operation allowed on Wimp sprites that can change them is the MergeSpriteFile (reason code 11) or the equivalent *IconSprites command.
For a detailed description on defining the appearance and size of sprites, see the Sprites and Icons? section in the RISC OS Style Guide.