[Table - 3 rows and 1 column] [Row 1, column 1] [Image] [Row 2, column 1] Acorn Nested Window Manager Functional Specification [Row 3, column 1] [Image] Document Status [Table - 13 rows and 2 columns] [Row 1, column 1] Distribution:   [Row 1, column 2] General Release [Row 2, column 1] Title:   [Row 2, column 2] Acorn Nested Window Manager Functional Specification [Row 3, column 1] Drawing Number:   [Row 3, column 2] 1215,401/FS [Row 4, column 1] Issue:   [Row 4, column 2] 1 [Row 5, column 1] Author(s):   [Row 5, column 2] Various for original document, including: [Row 6, column 1]   [Row 6, column 2] Piers Wombwell [Row 7, column 1]   [Row 7, column 2] Kevin Bracey [Row 8, column 1]   [Row 8, column 2] Later revisions for first formal specification: [Row 9, column 1]   [Row 9, column 2] Ben Avison [Row 10, column 1]   [Row 10, column 2] Andrew Hodgkinson [Row 11, column 1] Date:   [Row 11, column 2] 02/03/98 [Row 12, column 1] Change Number:   [Row 12, column 2] N/A [Row 13, column 1] Last Issue:   [Row 13, column 2] N/A Contents i. Document Status [Ref 1] ii. Issue History [Ref 2] iii. Overview [Ref 3] iv. Technical Background [Ref 4] v. User Interface [Ref 5] 1. Child and Nested Windows [Ref 6] 1. Child Windows Without a Work Area [Ref 7] 2. Furniture Windows [Ref 8] 2. Windows in General [Ref 9] 1. Invalid Rectangle Handling [Ref 10] 2. Standard Window Furniture [Ref 11] 3. Minimum Sizes [Ref 12] 4. Shift-Toggle-Sized Windows [Ref 13] 5. Error Report Dialogue Boxes [Ref 14] 3. Icons [Ref 15] 4. Menus [Ref 16] 5. Icon Bar [Ref 17] 6. Panic Redraws [Ref 18] vi. Programmer's Interface [Ref 19] 1. Wimp_Initialise (&400C0) [Ref 20] 2. Wimp_CreateWindow (&400C1) [Ref 21] 3. Wimp_CreateIcon (&400C2) [Ref 22] 4. Wimp_OpenWindow (&400C5) [Ref 23] 5. Wimp_GetWindowState (&400CB) [Ref 24] 6. Wimp_GetWindowInfo (&400CC) [Ref 25] 7. Wimp_ForceRedraw (&400D1) [Ref 26] 8. Wimp_GetWindowOutline (&400E0) [Ref 27] 9. Wimp_Extend (&400FB) [Ref 28] Issue history Originally appearing as 1116,011/FS up to issue 3, this specification now has a document number of 1215,401/FS. [Table - 7 rows and 3 columns] [Row 1, column 1] 1116,011/FS [Row 1, column 3] (Developers and, by issue 2, general release) [Row 2, column 1] 1 [Row 2, column 2] 06/02/98 [Row 2, column 3] Original Version (not released) [Row 3, column 1] 2 [Row 3, column 2] 10/02/98 [Row 3, column 3] HTML version completed for publishing on the Web [Row 4, column 1] 3 [Row 4, column 2] 16/02/98 [Row 4, column 3] Fixed up the HTML a bit, and in Wimp_CreateWindow the title foreground colour defaults to 7, not to 2 [Row 5, column 1]   [Row 5, column 2] 23/02/98 [Row 5, column 3] Various HTML tweaks; no content change [Row 6, column 1] 1215,401/FS [Row 6, column 3] (General release) [Row 7, column 1] 1 [Row 7, column 2] 02/03/98 [Row 7, column 3] Document number now 1215,401/FS. Updated history, and navigation links in the page footer now include the specifications section; no other content changes Overview Version 3.97 and 3.98 of the Wimp are beta versions, incorporating extensions required by numerous projects. The main features are: * Nested windows * Icon bar auto-fronting * Icon bar scroll regulation and acceleration * 24-bit icon colour specification * Border-less windows * New filter types * Redraw optimisation * Numerous bugfixes and other optimisations Technical Background This document documents changes to the Wimp over the version present in RISC OS 3.71, as determined from the PRM volumes 3 and 5a and the old Wimp itself. The Wimp has been written so that any given version can be built to soft-load on any OS version back to 3.10. Builds of version 3.97 and version 3.98 suitable for RISC OS 3.1x, 3.5x, 3.6x and 3.7x have been released with beta status for external testing, because a nested Wimp is a prerequisite of the browser and Java. The main differences from the RISC OS 3.7x build in those for earlier OSes are as follows: In RISC OS 3.6x and earlier, the Wimp * has no support for StrongARM * handles task memory management (rather than delegating to OS_AMBControl) In RISC OS 3.5x and earlier, the Wimp * always plots sprites using a translation table (ColourTrans module isn't new enough to plot paletted sprites from the palette) In RISC OS 3.1x, the Wimp * handles memory management significantly differently (for example, it doesn't use dynamic areas) * doesn't assume FP Emulator 4.00 or later will be present * doesn't support mode specifiers User Interface 3.1 Child and Nested Windows The single biggest enhancement to the Wimp is support for child windows: windows that are linked to and are only displayed within their parent. Each edge, and both scroll offsets of every child window are independently linked to the work area or one edge of the parent window, in whatever way suits the task. Thus, when a parent window is moved, scrolled or resized, any related changes to child windows are dealt with automatically by the Wimp. Any window may have any number of children, and within each window there is a stack of child windows, whose relative depth can change in the same manner as the top-level window stack. Child windows may change their parent at any time, jumping between stacks. Child windows may themselves have nested children within them, which may in turn have their own children, and so on. Child windows are considered to lie above any icons in their parent window, and above the parent window's caret. It should be noted that with all this added flexibility comes a potential for badly designed, non-intuitive application front-ends, so care must be taken when designing a user interface which uses the window nesting facilities. 3.1.1 Child Windows Without a Work Area In the past, it has not been possible to display windows without a work area, for example to implement a scroll bar in a non-standard place. This was due not only to a hard-coded minimum size visible area (see §3.2.3 [Ref 29]) but also due to the ever-present single-pixel border drawn by the Wimp along any edge of a window that lacks window furniture. In fact, it has previously been possible to remove the single-pixel border, but at the expense of the removal of all the window furniture at the same time, leaving an isolated work area. These restrictions have been lifted. This behaviour is in fact also available with top-level windows, but its usefulness is expected to be limited to child windows. 3.1.2 Furniture Windows Normally, child windows are clipped according to the visible area of the parent window. However, there are occasions where it is desirable for the child windows to be clipped by the window outline - that is, allowing them to overlap the window furniture. This might, for example, be used to display status information within the scrollbars, or add window furniture buttons. An additional window flag has been introduced, allowing a child window to overlap the window furniture of its parent in this way. Further, it is realised that to place such a furniture window at, for example, the bottom left of a window, would obscure the parent's scroll arrow icon. In order to compensate for this, scrollbars are allowed to move to accommodate any child window found to be touching both the outside edge of the scrollbar, and the end of the scrollbar. A window is deemed to be touching the end of the scrollbar if its end outline coordinate is within 1 pixel of the end of the scrollbar, i.e. there must be no gap between the child window outline and the final pixel of the scrollbar. The end of the scrollbar is adjusted so that it just underlaps the other end of the child window outline. The child window should normally be wide enough to cover all the area where the scroll bar would have been, as only a blank area of colour will be drawn there otherwise. Notice that these constraints allow for four furniture windows within the scrollbars of the parent. If, for example, the developer wanted two child windows in the bottom left, one window would have to be made a child of the other. Under current Wimp behaviour, if two sibling child windows are placed side by side in this manner, the scrollbar will move to accommodate both of them, but only if they are in a certain stacking order; this behaviour is not guaranteed in future versions of the Wimp, and must not be relied upon. Again, the flexibility offered by these child windows must not be abused: developers must, for example, take steps to ensure that the parent's minimum visible area is large enough for the furniture window never to overlap the parent's adjust size button. Furniture windows which are independently moveable and/or resizable are beyond the scope of the Nested Window Manager, and any attempt to give them such abilities will result in unpredictable behaviour. Such designs are thus strongly discouraged. 3.2 Windows in General 3.2.1 Invalid Rectangle Handling The way in which the Wimp calculates the invalid and block-copy rectangle lists is optimised over old Wimps, in order to increase the proportion of block-copy operations, which are usually much faster than redraws. This is done by compiling a list of changes between each call to Wimp_Poll, and only then calculating which rectangles are genuinely invalid, and which can be displayed using a quick block-copy operation. The block-copies themselves are re-ordered so that wherever possible, one copy does not invalidate screen area needed as source for another copy operation; in the rare cases where this is not possible, the least damaging alternative is chosen - that is, the one requiring the smallest invalid area to be redrawn. The upshot of this is that wherever touching or overlapping windows move together - external and internal panes, and of course, nested windows - the shuffling effect present in earlier Window Managers, where an area is alternately covered by the top window, and exposed and redrawn, is eliminated. There is also some speed gain from combining block-copy operations. In the unusual event that the window opening queue needs to be flushed before the Wimp_Poll, an extension to Wimp_OpenWindow [Ref 30] is provided. 3.2.2 Standard Window Furniture All window furniture buttons slab in, including close and toggle size. The bug regarding slabbing-in of the other furniture buttons, which could be unreliable following a Service_InvalidateCache, is fixed. Single-pixel borders can be removed from windows without removing all the other window furniture at the same time. For large work area windows, when the scroll sliders start being dragged, they jump less than in previous Wimps, and are displayed more accurately when they reach the end of the document. A plain-colour background is no longer drawn underneath the solid toolsprites, thereby reducing flicker. 3.2.3 Minimum Sizes All windows are optionally shrinkable to zero size visible area (subject to the continued visibility of any back, close, toggle size and adjust size buttons). In order to achieve this, scroll bars no longer have a minimum length (except in special cases). After the scroll slider region has been shrunk to zero length, the scroll arrows start to be plotted scaled down until the entire bar shrinks to nothing. Most conventional programs which rely upon the old behaviour continue to function as before, due to the special-case exemptions in Wimp_CreateWindow [Ref 31]. 3.2.4 Shift-Toggle-Sized Windows Windows which have been toggle-sized with Shift held down (i.e. made to fill all the screen except the icon bar) are now internally marked as being full size, and the toggle-size button indicates this by switching to the "fulled" sprite. A further click on the toggle size button will then reduce the window's size to its original size, as opposed to the previous, unhelpful behaviour, which was to enlarge the window to full screen, including covering the icon bar! 3.2.5. Error Report Dialogue Boxes Since each error button in a Wimp error box can contain user-defined text, it is possible for the text to be wider than the fixed width action buttons used in previous Wimps' error boxes. The Wimp now enlarges each action button if the width of its text (plus 36 OS units to allow for borders) is greater than that of its standard action button. 3.3 Icons A number of long-standing bugs relating to "3-D" icons are fixed: clicking on an action button that uses an antialiased font doesn't reset the Wimp font to the old bitmap system font; multiple selection of action buttons via dragging off one button and Adjust-clicking on another is no longer possible; menu clicks on action buttons no longer cause a flicker; and the 3-D plinths are drawn correctly in EX0 and/or EY0 screen modes and/or when not pixel-aligned. Icon foregrounds and backgrounds can be drawn using any 24-bit specified colour, not just one one of the Wimp colours. Any 2-, 4-, 16- or 256-colour sprites with palettes within icons are now plotted using the palette directly, rather than via a translation table. The effect of this is better colour reproduction of such sprites in 32 thousand colour and 16 million colour modes. Line spacing for multi-line text icons, first specified for RISC OS 3.10, via the parameters to the "L" command of an icon's validation string, has finally been implemented. 3.4 Menus Submenus and dialogue boxes opened from "reversed menus" are opened at the correct horizontal position again. However, the automatically-opened position still does not perfectly mirror normal menus for cases where the pointer is held over the "tick" space opposite the arrow. 3.5 Icon Bar The icon bar scrolls at a rate independent of processor speed or loading - the position is determined according to the time elapsed since scrolling started, irrespective of how many screen updates have been possible since. Also, the speed of scrolling increases linearly over time; it accelerates. This eases navigation of very wide icon bars. If the pointer is left over the bottom pixel row of the screen for 0.5 seconds, the icon bar now pops to the top of the window stack, much as it would if you had used the Shift-F12 hotkey. The icon bar remains at the top of the stack (and therefore accessible) while the pointer stays over the icon bar and/or there is an icon bar menu open. When this condition is no longer true, the icon bar returns to its original position in the window stack (note that this differs from Shift-F12 behaviour, where the icon bar always becomes a "back" object again). 3.6 Panic Redraws When a panic redraw occurs due to there being too many invalid rectangles for the Wimp to handle, the first thing drawn is a plain background. In a feature dating back to Arthur, this was hard-coded to Wimp colour 15 (now light blue) - hardly appropriate. This is changed to a mid-grey colour. Also, anticipating the increased number of invalid rectangles made likely by the nested windows system, the number of invalid rectangles allowed before a panic redraw is triggered is raised from 128 to 256. Programmer's interface [Table - 1 row and 1 column] [Row 1, column 1] Wimp_Initialise (&400c0) Wimp_Initialise recognises a new version number, in addition to the established 200, 300 and 310 versions. 380 will, at a sufficiently advanced version of the Wimp, be necessary in order to activate most of the features described in this specification. As of Wimp version 3.97, only the window foreground colour byte of the window block is affected by the version passed to Wimp_Initialise, but this must not be relied upon for future releases of the Wimp; other Nested-Wimp features may in future become reliant upon having passed 380. [Table - 1 row and 1 column] [Row 1, column 1] Wimp_CreateWindow (&400c1) The meanings of certain parts of the window block are altered and extended as follows: On entry [Table - 13 rows and 3 columns] [Row 1, column 1] R1 + 28 = window flags: [Row 1, column 2] bit [Row 1, column 3] meaning if set [Row 2, column 1] [Image] [Row 3, column 1]   [Row 3, column 2] 22  [Row 3, column 3] This bit is overwritten by the Wimp, and may be read using Wimp_GetWindowState. When set, it indicates that the window is, or will be, toggled to full size without covering the icon bar. Note that this behaviour is different to bit 18, which is set if the window is, or has been, toggled to full size including the icon bar. Toggling behaviour can only be properly resolved after Wimp_Poll returns an Open_Window_Request reason code and before the subsequent call to Wimp_OpenWindow. Flags bit 19 is set, by definition; applications may distinguish between different types of toggle-size clicks using the following truth table: [Table - 5 rows and 4 columns] [Row 1, column 1] Operation [Row 1, column 2] Bit 22 [Row 1, column 3] Bit 21 [Row 1, column 4] Bit 18 [Row 2, column 1] To full size [Row 2, column 2] 0 [Row 2, column 3] 1 [Row 2, column 4] 0 [Row 3, column 1] From full size [Row 3, column 2] 0 [Row 3, column 3] 0 [Row 3, column 4] 1 [Row 4, column 1] To semi-full size [Row 4, column 2] 1 [Row 4, column 3] 1 [Row 4, column 4] 0 [Row 5, column 1] From semi-full size [Row 5, column 2] 0 [Row 5, column 3] 0 [Row 5, column 4] 0 These are the only values that can be returned in combination with bit 19 being set. [Row 4, column 1] [Image] [Row 5, column 1]   [Row 5, column 2] 23  [Row 5, column 3] If this is a child window, make it a furniture window. (This has no meaning for top-level windows, so the bit should always be cleared in such cases to allow for future expansion). [Row 6, column 1] [Image] [Row 7, column 1] R1 + 32 = [Row 7, column 2] Title foreground and window frame colour: [Row 8, column 1] [Image] [Row 9, column 1]   [Row 9, column 2] &FF [Row 9, column 3] Window has no 1-pixel border components, but furniture can still be present (as controlled by the usual flag bits). Title foreground colour defaults to Style Guide standard colour (Wimp colour 7). [Row 10, column 1] [Image] [Row 11, column 1] R1 + 68 = [Row 11, column 2] Minium width of window (16 bits). This used to be the minimum visible width in OS units, unless a greater width was required by either of the following: a. The top edge furniture - any combination of the back, close, title and (as a special case when the vertical scrollbar is absent) the toggle-size icons. The width required by the title icon was defined as 8 OS units, except when 0 was used here, indicating that the full width of the title text or sprite will apply; b. The bottom edge furniture - the minimum (unsquashed) size horizontal scrollbar (if present), plus any adjust-size button (in the special case when the vertical scrollbar is absent). The 0 special case retains exactly the same behaviour as before (horizontal scroll bars, if present, cannot be squashed below a certain minimum width). Any other values activate the new behaviour: a horizontal scrollbar can be squashed down to zero width, and the title bar can be squashed down to zero width as long as the back and close buttons are both absent (otherwise, 8 OS units remains the minimum title icon width). A new special case, 1, is introduced, activating the new behaviour, but with an actual minimum window width of 0 rather than 1 (although it is obviously still subject to any non-squashable furniture width requirements as discussed). [Row 12, column 1] [Image] [Row 13, column 1] R1 + 70 = [Row 13, column 2] Minium height of window (16 bits). This used to be the minimum visible height in OS units, unless a greater height was required by a minimum (unsquashed) size vertical scrollbar, plus any toggle-size and adjust-size buttons (in the special cases where there is no title or horizontal scrollbar, respectively). It was also subject to a restraint that the minimum height could not be less than 2 pixels high when the vertical scrollbar was absent. The value 0 becomes a special case, and retains exactly the same behaviour as before. That is, the vertical scroll bar, if present, cannot be squashed down below a certain size. All other values activate the new behaviour: any vertical scrollbar may be squashed down to zero height, and the 2-pixel hard-minimum no longer applies. A special case, 1, is introduced, activating the new behaviour but with a minimum window height of zero rather than of 1 (subject to constraints imposed by window furniture as described). On exit Unchanged Interrupts Unchanged Re-entrancy Unchanged [Table - 1 row and 1 column] [Row 1, column 1] Wimp_CreateIcon (&400c2) The (C)olour validation string command is introduced to allow icon colours to be set from a 24-bit palette. It is typically followed by two hexadecimal numbers (BBGGRR) separated by a /, but either one may be omitted, and the relevant colour from the icon flags (or the F command) will then be used instead. It is suggested that the old-style colours should be specified to something sensible, in case the program gets run on a Window Manager that doesn't support the command. Examples: [Table - 4 rows and 4 columns] [Row 1, column 1] Validation [Row 1, column 2] Colours produced [Row 2, column 1] C008000/0080FF [Row 2, column 2] Mid green foreground, orange background [Row 2, column 3]   [Row 2, column 4]   [Row 3, column 1] CFF00FF [Row 3, column 2] Magenta foreground, background as specified in flags word [Row 3, column 3]   [Row 3, column 4] F [Row 4, column 1] C/00FFFF [Row 4, column 2] Foreground as specified in the flags word, yellow background [Row 4, column 3] F [Row 4, column 4]   Note also that the line spacing specified after the (L)ine spacing command is now acted upon. Bit 20 of the icon flags has not been part of the ESG number since at least RISC OS 3.10, and should be considered 'reserved'. [Table - 1 row and 1 column] [Row 1, column 1] Wimp_OpenWindow (&400c5) This call is the key to the nested window system. Changes are as follows: On entry [Table - 11 rows and 3 columns] [Row 1, column 1] R1 [Row 1, column 2] Pointer to block, or NULL (0 or -1) to flush all pending opens to the screen. [Row 2, column 1] [Image] [Row 3, column 1] R2 [Row 3, column 2] "TASK" (&4B534154) This is a 'magic word' to tell Wimp that the extended version of this SWI call is being made. In the extended call, R3 and R4 are as described below. Otherwise, the previous parent and flags (if any) are reused. The parent defaults to -1 and the flags default to 0, i.e. traditional Wimp behaviour is still the default. It is important to ensure that R2 does not accidentally get left with this value from a previous call in code which mixes old and new style calls. This is mostly an issue for C SWI veneers. [Row 4, column 1] [Image] [Row 5, column 1] R3 [Row 5, column 2] Handle of window to make parent (or -1 to make a top-level window) [Row 6, column 1] [Image] [Row 7, column 1] R4 = flags [Row 7, column 2] bit [Row 7, column 3] meaning if set [Row 8, column 1] [Image] [Row 9, column 1]   [Row 9, column 2] 0 [Row 9, column 3] Use extended OpenWindow block in R1 (R1 + 32 = window flags). If R3 is -1, bits 16-27 must all be clear. Otherwise, they specify how certain aspects of the child are aligned with the parent window: [Table - 7 rows and 2 columns] [Row 1, column 1] Bit pair [Row 1, column 2] Influences [Row 2, column 1] bits 16, 17 [Row 2, column 2] left edge of child [Row 3, column 1] bits 18, 19 [Row 3, column 2] bottom edge of child [Row 4, column 1] bits 20, 21 [Row 4, column 2] right edge of child [Row 5, column 1] bits 22, 23 [Row 5, column 2] top edge of child [Row 6, column 1] bits 24, 25 [Row 6, column 2] x-scroll of child [Row 7, column 1] bits 26, 27 [Row 7, column 2] y-scroll of child These flag pairs have the following meanings (as high bit, low bit): [Table - 5 rows and 2 columns] [Row 1, column 1] Setting [Row 1, column 2] Action [Row 2, column 1] 00 [Row 2, column 2] linked to work area of parent [Row 3, column 1] 01 [Row 3, column 2] linked to left / bottom of visible area of parent [Row 4, column 1] 10 [Row 4, column 2] linked to right / top of visible area of parent [Row 5, column 1] 11 [Row 5, column 2] reserved [Row 10, column 1] [Image] [Row 11, column 1]   [Row 11, column 2] 1-31 [Row 11, column 3] Reserved (0) On exit Unchanged Interrupts Unchanged Re-entrancy Unchanged Use / other notes If R4 bit 0 is set, then R1 + 32 holds the new window flags to use. This can be used, for example, to add or remove window furniture without having to delete and re-create the window. Not all window flags can be altered in this way. In particular, bits 16-22 can only be set or cleared by the Wimp, in order to reflect the window status. The Wimp will also modify the bits relating to the window furniture as follows: if bit 31 is unset (indicating the old-style bits are to be used) then bits 24-30 are updated to reflect the status indicated by bits 0, 2, 3 and 7 (but note that bit 31 itself is left unchanged). If bit 31 is set, however, bits 0, 2, 3 and 7 are cleared. All other bits are preserved (and acted upon) by the Wimp. Under previous Wimps, the window handle at R1+0 had to be owned by the task calling Wimp_OpenWindow. Because a child window need not belong to the same task as its parent, this restriction has now been lifted; this is the case even for the non-extended form (R2 not equal to the magic word "TASK"). Since RISC OS 2 (and possibly even earlier), Wimp_OpenWindow has had undocumented return conditions: values at R1+4 - R1+24 are updated to represent the actual parameters of the opened window after valid ranges have been taken into account, and the window has been forced on-screen (if applicable). Rather than continue to have programs waste time following a Wimp_OpenWindow with a Wimp_GetWindowState (except in cases where the new window flags are required), the exit conditions can now be considered official. [Table - 1 row and 1 column] [Row 1, column 1] Wimp_GetWindowState(&400cb) This call mirrors Wimp_OpenWindow. [Ref 32] If R2 = "TASK" on entry, then on exit R3 and R4 are as described above [Ref 33]. Note however that Wimp_GetWindowState has always returned the window flags in R1+32, but despite this, R4 bit 0 will always be returned cleared. [Table - 1 row and 1 column] [Row 1, column 1] Wimp_GetWindowInfo(&400cc) The returned window block's extended meanings are as for Wimp_CreateWindow. [Ref 34] [Table - 1 row and 1 column] [Row 1, column 1] Wimp_ForceRedraw(&400d1) Wimp_ForceRedraw is changed so that it can be applied to windows owned by other tasks, because a child window may belong to another task. In the past, redrawing the title bar of a window has been accomplished either by working out where the window's title bar is on the screen and calling Wimp_ForceRedraw with R0=-1 to invalidate that area, or alternatively by toggling the input focus in and out of the window to force its borders to be redrawn. Neither of these methods is particularly satisfactory: the first could cause other windows on top of the one in question to be redrawn unnecessarily, and the second redraws the rest of the borders as well, and in the case of child windows, would also cause a redraw of the parent's title bar. So Wimp_ForceRedraw is extended as follows: On entry [Table - 7 rows and 3 columns] [Row 1, column 1] R0 [Row 1, column 2] Window handle (as before) [Row 2, column 1] [Image] [Row 3, column 1] R1 [Row 3, column 2] "TASK" (&4B534154) This signals that the extended version of Wimp_ForceRedraw is being used, and R2-R4 are as stated below. [Row 4, column 1] [Image] [Row 5, column 1] R2 [Row 5, column 2] +3 Redraw title bar. Other values are reserved. [Row 6, column 1] [Image] [Row 7, column 1] R3, R4 [Row 7, column 2] Ignored. On exit Unchanged Interrupts Unchanged Re-entrancy Unchanged Notes Since the value &4B534154 ("TASK") is far too big to be an minimum x coordinate, it is safe to use as described above. [Table - 1 row and 1 column] [Row 1, column 1] Wimp_GetWindowOutline(&400e0) Previously, a window had to be open and visible on screen for this call to work. It will now work on windows which are closed or not yet visible. [Table - 1 row and 1 column] [Row 1, column 1] Wimp_Extend(&400fb) It is possible to enumerate window stacks using only Wimp_GetWindowState, but it requires that you open a "special" window of your own at the back of each stack to be enumerated, and you can only enumerate the stack from back to front. It may also return rather more information that you actually need, and so may be a little bit slower than it might be. Consequently, five new index values are added to Wimp_Extend. For each of the following, R1 holds the window handle being queried, or a value of -1 to enquire about the top-level stack (for index values 7 and 8 only). On entry [Table - 3 rows and 3 columns] [Row 1, column 1] R0 [Row 1, column 2] Reason code (see exit conditions for R1 [Ref 35]) [Row 2, column 1] [Image] [Row 3, column 1] R1 [Row 3, column 2] Window handle, or for reason codes in R0 of 7 and 8, a value of -1 to enquire about the top-level stack. On exit [Table - 1 row and 3 columns] [Row 1, column 1] R1 [Row 1, column 2] The value of R1 depends on the reason code and R1 value supplied on entry: [Table - 7 rows and 2 columns] [Row 1, column 1] Reason code in R0 [Row 1, column 2] Meaning of R1 on exit [Row 2, column 1] 0 - 5 [Row 2, column 2] Internal use only [Row 3, column 1] 6 [Row 3, column 2] Parent window [Row 4, column 1] 7 [Row 4, column 2] Frontmost child window [Row 5, column 1] 8 [Row 5, column 2] Backmost child window [Row 6, column 1] 9 [Row 6, column 2] Sibling immediately behind [Row 7, column 1] 10 [Row 7, column 2] Sibling immediately in front Interrupts Undefined Re-entrancy Undefined Use Any of the above calls can return R1 = -1 for "no window", indicating that the end of the stack was reached, or the window had no parent or child, or R1 was -1 on entry and R0 was not 7 or 8. Note also that pane windows are not skipped by any of the above calls. home [Ref 36] - manual [Ref 37] - downloads [Ref 38] - f.a.q [Ref 39] - feedback [Ref 40] hints and tips [Ref 41] - specifications [Ref 42] - other sites [Ref 43] - site map [Ref 44] [Table - 1 row and 2 columns] [Row 1, column 1] Last updated 6 March 1998 — Site comments? EMail webmaster@acorn.com [Ref 45] © Acorn Computers Limited, 1997 [Ref 46] [Row 1, column 2] [Valid HTML 4.0] [Ref 47] ============================================================================== References in this document: 1. http://www.acorn.com/browser/nested_wimp/funcspec.html#dost 2. http://www.acorn.com/browser/nested_wimp/funcspec.html#ishi 3. http://www.acorn.com/browser/nested_wimp/funcspec.html#over 4. http://www.acorn.com/browser/nested_wimp/funcspec.html#teba 5. http://www.acorn.com/browser/nested_wimp/funcspec.html#usin 6. http://www.acorn.com/browser/nested_wimp/funcspec.html#31 7. http://www.acorn.com/browser/nested_wimp/funcspec.html#311 8. http://www.acorn.com/browser/nested_wimp/funcspec.html#312 9. http://www.acorn.com/browser/nested_wimp/funcspec.html#32 10. http://www.acorn.com/browser/nested_wimp/funcspec.html#321 11. http://www.acorn.com/browser/nested_wimp/funcspec.html#322 12. http://www.acorn.com/browser/nested_wimp/funcspec.html#323 13. http://www.acorn.com/browser/nested_wimp/funcspec.html#324 14. http://www.acorn.com/browser/nested_wimp/funcspec.html#325 15. http://www.acorn.com/browser/nested_wimp/funcspec.html#33 16. http://www.acorn.com/browser/nested_wimp/funcspec.html#34 17. http://www.acorn.com/browser/nested_wimp/funcspec.html#35 18. http://www.acorn.com/browser/nested_wimp/funcspec.html#36 19. http://www.acorn.com/browser/nested_wimp/funcspec.html#prin 20. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c0 21. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c1 22. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c2 23. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c5 24. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400cb 25. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400cc 26. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400d1 27. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400e0 28. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400fb 29. http://www.acorn.com/browser/nested_wimp/funcspec.html#323 30. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c5 31. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c1 32. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c5 33. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c5 34. http://www.acorn.com/browser/nested_wimp/funcspec.html#swi400c1 35. http://www.acorn.com/browser/nested_wimp/funcspec.html#exit_r1_400fb 36. http://www.acorn.com/browser/ 37. http://www.acorn.com/browser/Manuals/Cover.html 38. http://www.acorn.com/browser/download.html 39. http://www.acorn.com/browser/faq.html 40. http://www.acorn.com/browser/bugform.html 41. http://www.acorn.com/browser/hints.html 42. http://www.acorn.com/browser/specs.html 43. http://www.acorn.com/browser/links.html 44. http://www.acorn.com/browser/map.html 45. mailto:webmaster@acorn.com 46. http://www.acorn.com/acorn/copyright.html 47. http://validator.w3.org/