Complete first pass at Chapter 8.

Standardise the use of bit n throughout the document.

Chapters/ch01-an-example-application.xml

@@ -286,7 +286,7 @@ ENDPROC</code>
 
 <p>This follows the standard approach to opening a window: obtain the parameter block required by <swi>Wimp_OpenWindow</swi> with a call to <swi>Wimp_GetWindowState</swi>, then adjust the parameters as required.</p>
 
-<p>If the window isn&rsquo;t currently on screen &ndash; which we can tell by looking at the &lsquo;window is open&rsquo; flag at bit 16 of the window flags stored at offset 32 into the returned parameter block &ndash; then we take the opportunity to adjust the window&rsquo;s size and position so that its visible area is centred on the screen and as large as possible without filling more than three quarters of the display. The screen width and height are read using an <function>FNread_mode_dimension()</function> function that we&rsquo;ll define shortly, and this information is used to decide the maximum size that we wish the window to be. The window&rsquo;s visible area coordinates (at offsets 4 to 16 in the block) are then updated to centre the window. If the window is already open, we leave the coordinates alone as we don&rsquo;t want it to jump around or resize itself on screen. Finally, the scroll offsets &ndash; at offsets 20 and 24 into the block &ndash; are reset to zero so that the window appears fully scrolled to the top-left regardless of size.</p>
+<p>If the window isn&rsquo;t currently on screen &ndash; which we can tell by looking at the &lsquo;window is open&rsquo; flag at bit&nbsp;16 of the window flags stored at offset 32 into the returned parameter block &ndash; then we take the opportunity to adjust the window&rsquo;s size and position so that its visible area is centred on the screen and as large as possible without filling more than three quarters of the display. The screen width and height are read using an <function>FNread_mode_dimension()</function> function that we&rsquo;ll define shortly, and this information is used to decide the maximum size that we wish the window to be. The window&rsquo;s visible area coordinates (at offsets 4 to 16 in the block) are then updated to centre the window. If the window is already open, we leave the coordinates alone as we don&rsquo;t want it to jump around or resize itself on screen. Finally, the scroll offsets &ndash; at offsets 20 and 24 into the block &ndash; are reset to zero so that the window appears fully scrolled to the top-left regardless of size.</p>
 
 <p>The handle of the window to open behind (at offset 28 into the block) is set to &minus;1, indicating &ldquo;at the top of the stack&rdquo;, and then the block is passed to <swi>Wimp_OpenWindow</swi> to perform the operation. Taken together, this will mean that if the user clicks on our iconbar icon and the window is not open, it will be opened in front of the other windows and centred on the screen. If the window <em>is</em> open, however, a click on the iconbar will simply bring it to the top of the stack in its current position.</p>
 

Chapters/ch02-a-side-toolbox.xml

@@ -62,11 +62,11 @@
 
 <p>Next, we must adjust the window&rsquo;s flags and parameters to meet the requirements of a toolbox pane, as seen in <reference id="fig-side-box-flags"/>. This is the <window>Edit window</window> dialogue in <cite>WinEd</cite>; other template editors will have a close equivalent.</p>
 
-<p>The first action is to turn off <em>all</em> of the window furniture &ndash; including the title bar. The pane won&rsquo;t be able to move independently of the window that it&rsquo;s attached to, so there&rsquo;s no need to give the user the option of trying! Under the heading of <icon>Window behaviour</icon>, the <icon>Moveable</icon> flag is also unset &ndash; this corresponds to the &lsquo;window is moveable&rsquo; flag in bit 1 of the window flags, and indicates that the <em>user</em> can&rsquo;t initiate window movement &ndash; the <em>application</em> still can, though.</p>
+<p>The first action is to turn off <em>all</em> of the window furniture &ndash; including the title bar. The pane won&rsquo;t be able to move independently of the window that it&rsquo;s attached to, so there&rsquo;s no need to give the user the option of trying! Under the heading of <icon>Window behaviour</icon>, the <icon>Moveable</icon> flag is also unset &ndash; this corresponds to the &lsquo;window is moveable&rsquo; flag in bit&nbsp;1 of the window flags, and indicates that the <em>user</em> can&rsquo;t initiate window movement &ndash; the <em>application</em> still can, though.</p>
 
 <image id="fig-side-box-flags" file="side-box-flags.png" title="Editing the pane&rsquo;s window flags in WinEd"/>
 
-<p>The other flag which we have set is <icon>Pane</icon>, which corresponds to the &lsquo;window is a pane&rsquo; flag at bit 5 of the window flags. The <cite>Programmer&rsquo;s Reference Manual</cite> is a little vague about what this flag does, but most developers will probably have been disappointed to discover that what it <em>doesn&rsquo;t</em> do is cause the window follow its parent around the screen automatically! In fact it does a few important things, which we&rsquo;ll discuss later in this chapter.</p>
+<p>The other flag which we have set is <icon>Pane</icon>, which corresponds to the &lsquo;window is a pane&rsquo; flag at bit&nbsp;5 of the window flags. The <cite>Programmer&rsquo;s Reference Manual</cite> is a little vague about what this flag does, but most developers will probably have been disappointed to discover that what it <em>doesn&rsquo;t</em> do is cause the window follow its parent around the screen automatically! In fact it does a few important things, which we&rsquo;ll discuss later in this chapter.</p>
 
 <p>Down at the bottom of the dialogue, all of the scroll events are off, since we don&rsquo;t need the pane to scroll. In addition, all of the window colours have been left at their default, <cite>Style Guide</cite> compliant values.</p>
 
@@ -253,9 +253,9 @@ ENDPROC</code>
 
 <image id="fig-side-box-loose" file="side-box-loose.png" title="If we&rsquo;re not careful, other windows can get in the way" />
 
-<p>There are a couple of more technical reasons, too, which relate to the behaviour of the &lsquo;window is a pane&rsquo; flag. When checking to see if our main window is at the top of the window stack, or obscured by any other windows (for the &lsquo;window is fully visible&rsquo; flag at bit 17 of the window flags), the Wimp will ignore any windows immediately in front of it so long as they have their pane flags set. Without use of the pane flag, a window whose pane obscures any part of its work area can never be reported as being fully visible by the Wimp.</p>
+<p>There are a couple of more technical reasons, too, which relate to the behaviour of the &lsquo;window is a pane&rsquo; flag. When checking to see if our main window is at the top of the window stack, or obscured by any other windows (for the &lsquo;window is fully visible&rsquo; flag at bit&nbsp;17 of the window flags), the Wimp will ignore any windows immediately in front of it so long as they have their pane flags set. Without use of the pane flag, a window whose pane obscures any part of its work area can never be reported as being fully visible by the Wimp.</p>
 
-<p>In a similar way, if a window with its pane flag set gains the caret, then the Wimp will give input focus to (and set the &lsquo;window has input focus&rsquo; flag at bit 20 of the window flags for) the first window <em>below</em> it in the stack which is not a pane. Finally, when working out which bits of a window might need redrawing following a re-size, the Wimp will treat any panes immediately above it as being transparent &ndash; on the basis that the application may be about to move them anyway.</p>
+<p>In a similar way, if a window with its pane flag set gains the caret, then the Wimp will give input focus to (and set the &lsquo;window has input focus&rsquo; flag at bit&nbsp;20 of the window flags for) the first window <em>below</em> it in the stack which is not a pane. Finally, when working out which bits of a window might need redrawing following a re-size, the Wimp will treat any panes immediately above it as being transparent &ndash; on the basis that the application may be about to move them anyway.</p>
 
 <p>Keeping the <maths>Z</maths> order of the windows correct is fairly straight-forward. The window state block for the main window contains the position in the window stack at which it should be opened, in terms of the handle of the window that it is positioned beneath at offset 28. Since the toolbox pane should be in front of the main window, then returning to <function>PROChandle_pane_windows()</function> following the call to <function>PROCposition_side_toolbox()</function>, we can copy this value into the pane&rsquo;s block so that the pane appears at the correct position in the stack.</p>
 

Chapters/ch06-the-nested-wimp.xml

@@ -217,7 +217,7 @@ toolbar%!28 = -1</code>
 
 <p>Bit&nbsp;0 is interesting in itself, as for the first time it makes it possible to change the window flags of a window after it has been created. Previously, doing things like changing the window furniture (scroll bars, back icons, and so on) required a window to be deleted with <swi>Wimp_DeleteWindow</swi> and then re-created with the new flags. Now, with the Nested Wimp, an application can simply put the desired new values into the correct place within the block passed to <swi>Wimp_OpenWindow</swi>, and set this bit of the nesting flags.</p>
 
-<p>However, this is beside the point: what we&rsquo;re interested in at present are the anchor points between bit 16 and bit 27. These define how a child window is attached to its parent; in our case, how our toolbar will be attached to the main window. Each of the anchor points is given by a two-bit value, with the possible meanings listed in <reference id="table-nest-wimp-nest-values"/>.</p>
+<p>However, this is beside the point: what we&rsquo;re interested in at present are the anchor points between bit&nbsp;16 and bit&nbsp;27. These define how a child window is attached to its parent; in our case, how our toolbar will be attached to the main window. Each of the anchor points is given by a two-bit value, with the possible meanings listed in <reference id="table-nest-wimp-nest-values"/>.</p>
 
 <table id="table-nest-wimp-nest-values" title="The Nesting Values for Wimp_OpenWindow">
 <columns>

Chapters/ch07-responsive-nesting.xml

@@ -128,6 +128,11 @@ ENDPROC</code>
 
 <p>The second point is that we call <function>PROCadjust_toolbar_content</function> <em>after</em> calling <swi>Wimp_OpenWindow</swi>. When the SWI has returned, the Wimp will have updated the parent window and all of its children to their new positions &ndash; at least within its data structures, if not on screen. This means that we are safe to query the position of any of the windows using the usual Wimp SWIs.</p>
 
+<p>We will also need to adjust the position of the icon when the window is first opened, so a call to <function>PROCadjust_toolbar_content</function> is added after the call to <swi>Wimp_OpenWindow</swi> in <function>PROCopen_main_window</function>.</p>
+
+<code lang="bbcbasic">SYS &quot;Wimp_OpenWindow&quot;,,toolbar%, &amp;4B534154, !main%, &amp;09A90000
+PROCadjust_toolbar_content</code>
+
 <p>Finally, <function>PROCadjust_toolbar_content</function> is defined as shown in <reference id="list-resp-nest-adjust"/>.</p>
 
 <code id="list-resp-nest-adjust" lang="bbcbasic" title="Adjusting the toolbar icon position">DEF PROCadjust_toolbar_content
@@ -164,7 +169,7 @@ ENDPROC</code>
 
 <download id="dl-resp-nest-resize" file="NestedFixed2" title="A fixed toolbar with a responsive writeable icon" compatibility="armv7"/>
 
-<p>So far, we have used the Nested Wimp to recreate the same toolbars that we were able to produce by hand using older versions of the Wimp. It has more interesting tricks up its sleeve, however, and we will start to look at these in <reference id="chap-moving-furniture">the next chapter</reference>.</p>
+<p>So far, we have used the Nested Wimp to recreate the same toolbars that we were able to produce by hand using older versions of the Wimp. It has more interesting tricks up its sleeve, however, and we will start to look at these in <reference id="chap-move-furniture">the next chapter</reference>.</p>
 </section>
 </chapter>
 </manual>