--- a/Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita	Fri Jul 16 17:23:46 2010 +0100
+++ b/Symbian3/SDK/Source/GUID-7C75642D-C0C9-5392-9354-711F42DC2C61.dita	Tue Jul 20 12:00:49 2010 +0100
@@ -75,7 +75,7 @@
 diagram demonstrates that typically the <xref href="GUID-12C281FF-546C-318D-8783-F26B0F619E11.dita"><apiname>RunL()</apiname></xref> starts with
 a <xref href="GUID-C57CFECB-72CD-39EB-A83E-82A9E985F56B.dita"><apiname>GetRedraw()</apiname></xref> and ends with a call to <xref href="GUID-E3F0CB70-58E4-32FD-9828-71DF2F9976D3.dita"><apiname>RedrawReady()</apiname></xref>. </p> <fig id="GUID-B092D136-8C18-5237-A095-F8C3BBFFDDB4">
 <title>              Window Server-initiated redraw            </title>
-<image href="GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e190203_href.png" placement="inline"/>
+<image href="GUID-0528A294-AC1B-5CDD-B59C-A105F39D748F_d0e195174_href.png" placement="inline"/>
 </fig> <p>A redrawer's <codeph>RunL()</codeph> function must <b>not</b> perform
 any non-redraw drawing (that is, any drawing operations that are not bracketed
 within the calls to <codeph>BeginRedraw()</codeph> and <codeph>EndRedraw()</codeph>).
@@ -107,7 +107,7 @@
 </ol> <fig id="GUID-6E2637DC-F92A-56DE-BB07-F109F5CA681B">
 <title>              Application-initiated redrawing, "draw now" scenario
            </title>
-<image href="GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e190311_href.png" placement="inline"/>
+<image href="GUID-4BC95F70-2F3F-5CFE-B057-0C5A97430573_d0e195282_href.png" placement="inline"/>
 </fig> <p><b>The "draw deferred" scenario </b> </p> <p>The "draw deferred" redraw scenario
 is when an application simply marks a window or a rectangle within a window
 as invalid. This eventually triggers a Window Server-initiated redraw. Typically
@@ -115,7 +115,7 @@
 However, it is also possible to do this by calling <xref href="GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79.dita#GUID-683603DD-F3D3-3193-BEB3-8236C7DE7F79/GUID-28202F81-52FE-30F5-8B8C-ABED0915822E"><apiname>RWindow::Invalidate()</apiname></xref>. </p> <fig id="GUID-8B78CE09-EE92-50B3-8000-731BD9C20890">
 <title>              Application-initiated redrawing, "draw deferred" scenario
            </title>
-<image href="GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e190335_href.png" placement="inline"/>
+<image href="GUID-21EF9E6F-A0BF-5EB2-9E3F-CA6A011D4C89_d0e195306_href.png" placement="inline"/>
 </fig> <p>This approach is useful when the data to be displayed might be updated
 frequently but it is not necessary to update the display instantaneously. </p> <p>To
 illustrate how it works, consider a window that has a rectangle that is used
@@ -126,14 +126,14 @@
 the following diagram. </p> <fig id="GUID-04BCFA21-8D44-5FEA-BE29-57B40AC9CF99">
 <title>              Icons displayed using the "draw now" approach       
     </title>
-<image href="GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e190349_href.png" placement="inline"/>
+<image href="GUID-89185EBD-223F-5F52-B1CA-9F9692F7D21F_d0e195320_href.png" placement="inline"/>
 </fig> <p>However, if you use the "draw deferred" approach when each event
 occurs, the Window Server may not update the display for each one. For example,
 the Window Server does not update the display when it is superceded by a later
 call. </p> <fig id="GUID-1E0E2A3C-1E63-58F6-940F-0D439FA6C721">
 <title>              Icons displayed using the "draw deferred" approach  
          </title>
-<image href="GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e190360_href.png" placement="inline"/>
+<image href="GUID-EDC405DC-F222-59CD-836E-180F8E1D2D11_d0e195331_href.png" placement="inline"/>
 </fig> <p>If it is important that the display is updated immediately, you
 would generally use the "draw now" approach. However, if a short delay in
 the display being updated is unlikely to inconvenience the user, the "draw