diff --git a/Chapters/ch05-does-order-matter.xml b/Chapters/ch05-does-order-matter.xml index 7701cf5..22caff0 100644 --- a/Chapters/ch05-does-order-matter.xml +++ b/Chapters/ch05-does-order-matter.xml @@ -181,7 +181,7 @@ PROChandle_pane_windows(q%)

If an application needs the Nested Wimp for some other reason, and will therefore not be able to 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 the next chapter. The main thing that the Nested Wimp does not support is panes which fall outside the outline of the parent window, such as the side toolbox that we created 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 Wimp_OpenWindow once for the main window and once for each pane.

+

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 Wimp_OpenWindow once for the main window and once for each pane. The only real difference is in the complexity of the code itself, and how easy it is for developers to understand.

Which approach to use will be a decision for individual developers, based on their applications’s requirements. If you do use the optimisation, though, it’s a good idea to check for its presence in the !Run of the application using an *RMEnsure.