The full code for our new
DEF PROChandle_pane_windows(main%)
LOCAL toolbar%
@@ -112,7 +111,14 @@ toolbar%!28 = main%!28
SYS "Wimp_OpenWindow",,toolbar%
ENDPROC
-A complete copy of the new application can be found in
Now that
q%!28 = -1 : REM Window to open behind (-1 is top of stack)
+
+SYS "Wimp_OpenWindow",,q%
+PROChandle_pane_windows(q%)
+
+With all of these changes in place, a complete copy of the new application can be found in
The small difference described in the previous section matters, because of a small change introduced as part of the Nested Wimp. A couple of the changes documented in the Nested Window Manager Functional Specification are “Redraw Optimisation” and improvements to the “Invalid Rectangle Handling”. Between them, these have a big impact on the handling of panes.
+The difference described in the previous section matters, because of a small improvement introduced as part of the Nested Wimp. A couple of the changes documented in the Nested Window Manager Functional Specification are “Redraw Optimisation” and improvements to the “Invalid Rectangle Handling”. Between them, these have a big impact on the handling of panes.
When an application calls
What this means in practice is that the Nested Wimp will notice that despite the toolbar pane ending up behind the main window in
On earlier versions of the Wimp, however, our new optimised approach will result in the main window and its toolbar pane following the sequence shown in
Given all of this, is the optimisation described in this chapter of any use? The answer is “yes,” but probably not in all circumstances.
+ +If an application needs the Nested Wimp for some other reason, and will not run without it, then there’s no harm in relying on the redraw optimisation in order to simplify the pane handling code. However, it’s also worth remembering that the Nested Wimp will deal with many pane requirements – including those in this chapter – directly, with no need for any custom event handling; we’ll see how this works in
For applications which do not need the Nested Wimp for other reasons, and would otherwise work fine back to RISC OS 3 or earlier, it seems a shame to restrict their compatibility for no good reason. Save for the situation when the window first opens, the more compatible solution is no less efficient than this optimised one: they both call
If you do use the optimisation, though, it’s a good idea to check for its presence in the
RMEnsure WindowManager 3.80 Error PaneDemo requires the Nested Window Manager.
+
+
+