Menu
▾
▴
[Oorexx-svn] SF.net SVN: oorexx-code-0:[9055] docs/trunk/oodguide/en-US/Chapter07.xml
|
From: <os...@us...> - 2013-03-01 22:33:25
|
Revision: 9055
http://sourceforge.net/p/oorexx/code-0/9055
Author: osims
Date: 2013-03-01 22:33:21 +0000 (Fri, 01 Mar 2013)
Log Message:
-----------
A few mods to Chap7 on proofreading.
Modified Paths:
--------------
docs/trunk/oodguide/en-US/Chapter07.xml
Modified: docs/trunk/oodguide/en-US/Chapter07.xml
===================================================================
--- docs/trunk/oodguide/en-US/Chapter07.xml 2013-03-01 15:39:00 UTC (rev 9054)
+++ docs/trunk/oodguide/en-US/Chapter07.xml 2013-03-01 22:33:21 UTC (rev 9055)
@@ -153,8 +153,8 @@
<section id="chap07-mvf">
<title id="ch7-mvf.title">A Model-View Framework</title>
<!-- Section 7.2 -->
- <para>This section presents the externals of the MVF. For a discussion of the internals of the
- MVF, see <xref linkend="apx5-mvf.title"/>.</para>
+ <para>This section presents the externals of the MVF. For some additional detail,
+ see <xref linkend="apx5-mvf"/>.</para>
<section id="chap07-mvf-objs">
<title id="ch7-mvf-objs.title">MVF Objective</title>
<!-- Section 7.2.1 -->
@@ -163,9 +163,12 @@
of <emphasis role="italic">how</emphasis> this is done. Thus the MVF supports
view-model-data separation of concerns in application-level components. The MVF comprises
three superclasses for application components called <computeroutput>Model</computeroutput>,
- <computeroutput>View</computeroutput>, and <computeroutput>GenericFile</computeroutput>
- (the latter for data components), plus two "manager" objects:
- <computeroutput>ObjectMgr</computeroutput>' and
+ <computeroutput>xxView</computeroutput> (where "xx" is "Rc", "Res" or "Ud")
+ <footnote><para>The three "xxView" classes are identical except for their superclasses - RcDialog, ResDialog
+ and UserDialog respectively. In the next exercise, it is planned that theses will be merged into a
+ single mixin class.</para></footnote>, and <computeroutput>GenericFile</computeroutput>
+ (for data components), plus two "manager" objects:
+ <computeroutput>ObjectMgr</computeroutput> and
<computeroutput>ViewMgr</computeroutput>.</para>
<para>When a user double-clicks on an item in say the Customer List dialog, the confident
expectation is that a Customer dialog that shows the data associated with the list item will
@@ -192,10 +195,10 @@
<para>Create a view component.</para>
</listitem>
<listitem>
- <para>Provide that view component with the data to be displayed in its dialog.</para>
+ <para>Provide the view component with the model's data.</para>
</listitem>
<listitem>
- <para>Make the dialog visible.</para>
+ <para>Make the dialog (including data) visible.</para>
</listitem>
</orderedlist>
<para>This sequence set of actions assumes that none of the component instances involved are
@@ -233,7 +236,7 @@
(which subclasses <computeroutput>GenericFile</computeroutput>). In both exercises,
launching a Customer View from the list (when the user double-clicks on a list item) is done
by the <computeroutput>showCustomer</computeroutput> method as follows (excluding code
- common to both): <programlisting><![CDATA[ CustomerListView
+ common to both): <programlisting><![CDATA[ CustomerListView
Exercise 6 Exercise 7
---------- ----------
::METHOD showCustomer UNGUARDED ::METHOD showCustomer UNGUARDED
@@ -249,7 +252,7 @@
]]></programlisting>In Exercise 6, before the CustomerView is instantiated, the CustomerData and
CustomerModel components must be instantiated, and their object IDs stored in
<computeroutput>.local</computeroutput> for later access by the CustomerView and
- CustomerModel objects. This is needed, although no data is actually read from disk, the
+ CustomerModel objects. This is needed because, although no data is actually read from disk, the
CustomerView invokes a method on CustomerModel which invokes CustomerData. </para>
<para>In Exercise 7, on the other hand, the value of
<computeroutput>info~text</computeroutput> (the index read from the selected ListView row)
@@ -257,10 +260,10 @@
<computeroutput>showModel</computeroutput> method then manages or "choreographs" the
sequence of method invocations required to surface the Customer View dialog, and (if
necessary) create the appropriate model and data objects. This choreography, using the
- <computeroutput>Model</computeroutput>, <computeroutput>View</computeroutput> and
+ <computeroutput>Model</computeroutput>, <computeroutput>xxView</computeroutput> and
<computeroutput>GenericData</computeroutput> superclasses, results in the Customer View
- being surfaced with its data read from disk and displayed. See <xref linkend="apx5-mvf-ops"
- /> for a full description of the way in which this is done.</para>
+ being surfaced with its data read from disk and displayed. See <xref linkend="apx5-mvf-ops"/>
+ for a full description of the way in which this is done.</para>
<para>Finally, note that in Exercise 7, the names of the possible List Model classes (e.g.
<computeroutput>CustomerListModel</computeroutput>) are hard-coded in the
<computeroutput>initRecords</computeroutput> method of
@@ -273,7 +276,7 @@
<!-- Section 7.2.2 -->
<para> The MVF consists of five classes: <computeroutput>ObjectMgr</computeroutput>,
<computeroutput>ViewMgr</computeroutput>, <computeroutput>Model</computeroutput>,
- <computeroutput>RcView</computeroutput>, <computeroutput>ResView</computeroutput>, and
+ <computeroutput>xxView</computeroutput> (i.e. RcView, ResView, and UdView)
<computeroutput>GenericFile</computeroutput>. These are all located in the folder
<computeroutput>ooRexx\samples\oodialog\userGuide\exercises\Support</computeroutput>.
Together, they handle the three different types of application component - view, model, and
@@ -312,8 +315,8 @@
<secondary>Person</secondary>
</indexterm>
<para>A key question is, what does the MVF look like to the programmer? This section answers
- this question using the Person component, which has minimal function other than using the
- MVF, as an example. But first, using the Message Sender, try sending a <emphasis
+ this question using the Person component (which has minimal function other than using the
+ MVF) as an example. But first, using the Message Sender, try sending a <emphasis
role="italic"><emphasis role="bold">showModel</emphasis></emphasis> message to <emphasis
role="italic"><emphasis role="bold">ObjectMgr The</emphasis></emphasis> with the data
<emphasis role="italic"><emphasis role="bold">PersonModel PA150</emphasis></emphasis>.
@@ -336,7 +339,7 @@
-- Check if an instance has already been created; if so, return .false.
idData = self~new()
return idData
-
+
::METHOD init PRIVATE
...
records = self~init:super(fileName, columns)
@@ -356,17 +359,17 @@
<para><programlisting><![CDATA[
::METHOD newInstance CLASS PUBLIC
use strict arg instanceName
- forward class (super) continue
+ forward class (super) continue
modelId = RESULT
return modelId
::METHOD init
use strict arg myData]]></programlisting>Model components such as
- <computeroutput>PersonModel</computeroutput> are required to provide a <emphasis
- role="italic">newInstance</emphasis> class method with one required argument - the
+ <computeroutput>PersonModel</computeroutput> are required to provide a
+ <computeroutput>newInstance</computeroutput> class method with one required argument - the
model's instance name. The method must be forwarded to the
- <computeroutput>Model</computeroutput> superclass, which retrieves the intended
- instance's data from its data component, then creates an instance of itself with the
+ <computeroutput>Model</computeroutput> superclass, which first retrieves the intended
+ instance's data from its data component, and then creates an instance of itself with the
instance data as a parameter. The new instance must then be returned. </para>
</listitem>
<listitem>
@@ -378,12 +381,12 @@
use strict arg modelId, rootDlg
-- create dialog, e.g. "dlg = .PersonView~new(...)"
dlg~activate(modelId, rootDlg)
- return dlg
-
+ return dlg
+
::METHOD activate UNGUARDED
use strict arg modelId, rootDlg
forward class (super) continue
- personData = RESULT
+ personData = RESULT
]]></programlisting>View components such as <computeroutput>PersonView</computeroutput> must provide
a <computeroutput>newInstance</computeroutput> class method and an
<computeroutput>activate</computeroutput> method. The
@@ -401,7 +404,7 @@
<para>The above is how a "named" component uses MVF. By "named" is meant a component whose
identity is a combination of its class and a specific "key" such as a Customer Number, or
Product Number. However, there are three other kinds of component: a "singleton" such as
- the Order Manager, a "form" such as the Order Form, and "anonymous" such as a Customer
+ a data component, a "form" such as the Order Form, and "anonymous" such as a Customer
List. These are discussed below in <xref linkend="chap07-mvfuse-kinds"/>.</para>
</section>
<!-- End of 7.2.2.1 -->
@@ -430,21 +433,21 @@
component. If the id is not in the Object Bag, then it sends
<computeroutput>newInstance</computeroutput> to
<computeroutput>className</computeroutput>. If one or both of these do not exist,
- returns <computeroutput>.false</computeroutput>.</para>
+ <computeroutput>.false</computeroutput> is returned.</para>
</listitem>
<listitem>
- <para><computeroutput>list</computeroutput> - Lists the contents of the ObjectBag in
+ <para><computeroutput>list</computeroutput> - Lists the contents of the ObjectBag on
the Command Prompt. The instance name for a View component is derived by invoking
<computeroutput>identityHash</computeroutput> on its id. The following shows the
contents of the Object Bag after (a) a CustomerList was double-clicked on the Order
Management dialog, (b) a Customer in the list was double-clicked, and (c) the <link
- linkend="ch7-msgsender.title">Message Sender</link> was used to send a 'query'
+ linkend="ch7-msgsender">Message Sender</link> was used to send a 'query'
message to <emphasis role="italic">ProductModel LM400</emphasis>: <programlisting>
<![CDATA[
Object Bag List:
----------------------------------------------------------------------------
-Class-Instance Model Id ViewClass-Inst
------------------------- ------------------------ ------------------------
+Class-Instance Model Id ViewClass-Inst
+------------------------ ------------------------ ------------------------
CUSTOMERLISTVIEW-26701042 a CUSTOMERLISTVIEW .nil
PRODUCTMODEL-LM400 a PRODUCTMODEL .nil
CUSTOMERVIEW-267047652 a CUSTOMERVIEW .nil
@@ -467,9 +470,9 @@
</listitem>
</itemizedlist>
</para>
- <para>For further information on the Object Manager, including more detail on the flow of
- control when a component is instantiated, see <xref linkend="apx5-mvf-classes-om"
- />.</para>
+ <para>For further information on how the <computeroutput>showModel</computeroutput> method of
+ the Object Manager works, see <xref linkend="apx5-mvf-ops"/>.
+ </para>
</section>
<!-- End of Section 7.2.2.2 -->
<section id="chap07-mvf-oview-model">
@@ -496,21 +499,21 @@
</indexterm> - invoked by the Object Manager (which ensures that the required data
component is instantiated) with an instance name as the single parameter. The id of
the data component is retrieved from Object Manager, after which
- <computeroutput>getRecord</computeroutput> or
- <computeroutput>getFile</computeroutput> as appropriate is invoked on the data
+ <computeroutput>getRecord</computeroutput> (or
+ <computeroutput>getFile</computeroutput> for a "list" component) is invoked on the data
component. Then <computeroutput>self~new</computeroutput> is invoked with model's
- data as a parameter. Model also provides an instance attribute
- <computeroutput>myData</computeroutput> that contains instance data returned from
+ data as a parameter. <computeroutput>Model</computeroutput> also provides an instance attribute
+ <computeroutput>myData</computeroutput> that contains the instance data returned from
the data component.</para>
</listitem>
<listitem>
<para><computeroutput>getInstanceName</computeroutput>
- <indexterm>
- <primary>getInstanceName</primary>
- </indexterm> is invoked by ObjectMgr-showModel for anonymous components only. It
- adds 1 to a class variable and returns it. Note - for
- <computeroutput>OrderForm</computeroutput>, the method is over-ridden and a "new
- order number " is returned.</para>
+ <indexterm><primary>getInstanceName</primary></indexterm>
+ is invoked by the Object Manager's <computeroutput>showModel</computeroutput>
+ method for anonymous components only (such as a <computeroutput>CustomerListModel</computeroutput>).
+ It adds 1 to a class variable and returns it. Note - for
+ <computeroutput>OrderFormModel</computeroutput>, <indexterm><primary>OrderFormModel</primary></indexterm>
+ the method is over-ridden and a new order number is returned.</para>
</listitem>
<listitem>
<para><computeroutput>query</computeroutput>
@@ -532,8 +535,8 @@
role="bold"><emphasis role="italic">PersonModel PA150</emphasis></emphasis>.
A directory is returned by <computeroutput>PersonModel</computeroutput>, and
the Message Sender presents the directory in name-value form in its <emphasis
- role="bold">Reply</emphasis> field as follows: <programlisting><![CDATA[dob: 751513; baseSalary: 38000; number: PA150; jobDescr: Packer;
-familyName: James; firstName: Alfred;
+ role="bold">Reply</emphasis> field as follows: <programlisting><![CDATA[dob: 751513; baseSalary: 38000; number: PA150; jobDescr: Packer;
+familyName: James; firstName: Alfred;
]]></programlisting></para>
</listitem>
<listitem>
@@ -603,7 +606,10 @@
<para>
<itemizedlist>
<listitem>
- <para><computeroutput>activate</computeroutput> - This is invoked by the subclass,
+ <para><computeroutput>activate</computeroutput>
+ <indexterm><primary>activate method</primary><secondary>in View superclass</secondary></indexterm>
+ <indexterm><primary>View superclass</primary><secondary>activate method</secondary></indexterm>
+ - This is invoked by the subclass,
which must provide the view's model id as the single argument. A
<computeroutput>query</computeroutput> message is invoked on the model, which
returns the model's data as a directory. In addition, this method saves information
@@ -611,16 +617,20 @@
</para>
</listitem>
<listitem>
- <para><computeroutput>leaving</computeroutput><indexterm>
- <primary>leaving method</primary>
- </indexterm> - This method is automatically invoked by ooDialog when a dialog
- closes. Its only function is to remove the view from the Object Manager's table.
+ <para><computeroutput>leaving</computeroutput>
+ <indexterm><primary>leaving method</primary></indexterm>
+ <indexterm><primary>View superclass</primary><secondary>leaving method</secondary></indexterm>
+ - This method is automatically invoked by ooDialog when a dialog
+ closes. Its only function is to inform the Object Manager that the view is about
+ to close. The Object Manager then removes the view from the Object Bag (otherwise
+ it might later try to surface a non-existant view!).
</para>
</listitem>
<listitem>
<para><computeroutput>offset</computeroutput><indexterm>
- <primary>offset method</primary>
- </indexterm> - This method offsets dialogs from the Order Management dialog when
+ <indexterm><primary>offset method</primary></indexterm>
+ <indexterm<primary>View superclass</primary><secondary>offset method</secondary></indexterm>
+ - This method offsets dialogs from the Order Management dialog when
first opened. Although not used elsewhere in this exercise, the effect can be seen
using the "Person" component in the <computeroutput>Samples\Person</computeroutput>
folder. First, use the Message Sender to launch a Person dialog (for example send
@@ -722,7 +732,7 @@
Customer and some Product data not present in the Order Data (for example, Customer
Discounts and Product Names). Thus it also over-rides its superclass method, and builds a
directory called "dirOrderRecord" whose format is as follows:<programlisting><![CDATA[ "dirOrderRecord" format (using data values from Order No SO-1234):
-
+
Indexes Items
+- - - - - - - - - - - - - - - - - - - - - - - - +
| OrderNo | SO-1234 |
@@ -734,13 +744,13 @@
| CustAddr | 2145 Engle Blvd,Hardtown,FL |
+- - - - - + - - - - - - - - - - - - - - - - - - +
| Zip | 37043 |
- +- - - - - + - - - - - - - - - - - - - - - - - - +
+ +- - - - - + - - - - - - - - - - - - - - - - - - +
| Cmtd | N |
- +- - - - - + - - - - - - - - - - - - - - - - - - +
+ +- - - - - + - - - - - - - - - - - - - - - - - - +
| CustDisc | B1 |
- +- - - - - + - - - - - - - - - - - - - - - - - - +
+ +- - - - - + - - - - - - - - - - - - - - - - - - +
| Disc | 2 |
- +- - - - - + - - - - - - - - - - - - - - - - - - +
+ +- - - - - + - - - - - - - - - - - - - - - - - - +
| Date | 120821 |
+- - - - - - - - - - - - - - - - - - - - - - - - +
| OrderLineHdrs | OrderNo ProdNo Qty ProdName | <a 1D array>
@@ -845,7 +855,7 @@
defined in the first line of the file. All data files have the file extension ".txt".
<computeroutput>GenericFile</computeroutput> returns a single record (for example a
Customer record) in a "record directory", whose format is as follows:<programlisting><![CDATA[ "Record Directory" format (using sample data values):
-
+
Indexes Items
+- - - - - - - - - - - - - -+
| CustNo | BA0314 |
@@ -858,7 +868,7 @@
+- - - - - - - - - - - - - -+]]> </programlisting> A complete file (for example the
Customer File retrieved and displayed by the CustomerList component) is returned in "File as
Directory" format, as follows: <programlisting><![CDATA[ "File Directory" format (using sample data values):
-
+
Indexes Items
+- - - - - - - - - - - - - - - - - - - - - - - - +
|Headers | CustNo | CustName | .... | 1D array
@@ -916,15 +926,15 @@
<indexterm><primary>Re-sizing</primary><secondary>Controls</secondary></indexterm>
<indexterm><primary>Control</primary><secondary>Re-sizing</secondary></indexterm>
<indexterm><primary>Dialog</primary><secondary>Re-sizing</secondary></indexterm>
- <para>In Exercise 6, the Order Manager is a re-sizeable dialog, However, when re-sized, all controls
+ <para>In Exercise 6, the Order Manager is a re-sizeable dialog, However, when re-sized, all controls
were enlarged (or shrunk) in size. Normally, to have all controls change size is not a requirement;
- rather controls such as push buttons and edit fields should usually not change their size.
+ rather controls such as push buttons and edit fields should usually not change their size.
</para>
<para>In Exercise 7, only the "container" for the icons is required to re-size. Other controls should not change.
This is achieved by "pinning"
the other controls so that they do not move or expand/contract. For example, the "Reset Icons" button
- is pinned to the left side and to the bottom side
- of the dialog, so preventing the button from moving away from the bottom-left of the dialog. In addition,
+ is pinned to the left side and to the bottom side
+ of the dialog, so preventing the button from moving away from the bottom-left of the dialog. In addition,
to prevent the button changing its size, the top side of the button is pinned to the bottom side, and the
right side is pinned to the left side. Code to define such constraints must be placed in a
<computeroutput>defineSizing</computeroutput>
@@ -932,7 +942,7 @@
<indexterm><primary>Methods</primary><secondary>defineSizing</secondary></indexterm>
method which is automatically invoked by ooDialog before the underlying dialog is created. If nothing is defined,
the default is to do nothing. Note that in this method, no other method that requires the underlying dialog
- to exist can be invoked. Note also that this method must return <computeroutput>.false</computeroutput>.</para>
+ to exist can be invoked. Note also that this method must return <computeroutput>.false</computeroutput>.</para>
<para>Specifying how controls behave when the dialog is re-sized is done by invoking the
<computeroutput>controlSizing</computeroutput> method (a method of ooDialog's
<computeroutput>ResizingAdmin</computeroutput> class) on 'self'. As an example, the
@@ -947,7 +957,7 @@
.array~of('STATIONARY', 'BOTTOM'), -
.array~of('MYLEFT', 'LEFT' ), -
.array~of('MYTOP', 'TOP' ) -
- ...)]]>
+ ...)]]>
</programlisting>The <computeroutput>controlSizing</computeroutput>
method takes five arguments: a control's resource ID (e.g. the Reset button) and four arrays.
The first array addresses the left side of the control, the second the top, the third the
@@ -956,35 +966,35 @@
window (remembering that each dialog and each control is actually a "window"). Third the id of
the other window to which this control is pinned, the default being the resource id of the
main dialog (in our case the Order Management dialog whose resource id is
- 'IDD_ORDMGR').</para>
- <para>So, taking the second parameter as an example, "STATIONARY" means that the left side of the Reset button
+ 'IDD_ORDMGR').</para>
+ <para>So, taking the second parameter as an example, "STATIONARY" means that the left side of the Reset button
must not move away (or towards) the second parameter, i.e. the "LEFT" side of the dialog.</para>
<para>Consider the last parameter - the array 'MYTOP', 'TOP'. The keyword 'MYTOP' is a special keyword that
can only be used for the bottom edge of a control. It pins the bottom edge of the control to its top
- edge. This has the effect of keeping the height of the control constant. Similarly, 'MYLEFT' pins the right side
+ edge. This has the effect of keeping the height of the control constant. Similarly, 'MYLEFT' pins the right side
of the control to the left side, so keeping the width of the control constant. Note that the second parameter
is ignored, although it must be a valid sizing parameter.</para>
<para>The result of all this is that the Reset button does not move from the bottom left corner of the dialog,
and its size remains constant.
</para>
<para>For further information about the ResizingAdmin class, see the ooDialog Reference. In addition, the folder
- <computeroutput>Program Files\ooRexx\samples\oodialog\</computeroutput> contains examples of re-sizeable dialogs in
- <computeroutput>resizableDialogs\ResizingAdmin</computeroutput>. Here, the program
+ <computeroutput>Program Files\ooRexx\samples\oodialog\</computeroutput> contains examples of re-sizeable dialogs in
+ <computeroutput>resizableDialogs\ResizingAdmin</computeroutput>. Here, the program
<computeroutput>augmentedResize.rex</computeroutput> has copious and excellent comments on the various aspects
of re-sizing. Worth a read!</para>
</section> <!-- End of Section 7.5 -->
-
+
<!-- *********************************************************************************************** -->
<section id="chap07-orderform">
<title id="ch7-orderform.title">The Order Form</title>
- <!-- comment: Section 7.6 -->
+ <!-- comment: Section 7.6 -->
<indexterm>
<primary>Order Form dialog</primary>
</indexterm>
<para>Open an Order Form from the icon in the Order Management dialog. Although still not functional,
the format of the dialog <emphasis role="italic">looks</emphasis> much more like a usable sales order
- form than in the previous exercise. The main part of the form is a Tab Control with two tabs - one for
- entering customer details, the other for product details.
+ form than in the previous exercise. The main part of the form is a Tab Control with two tabs - one for
+ entering customer details, the other for product details.
<indexterm><primary>Tab Control</primary><secondary>Property Sheet</secondary></indexterm>
<indexterm><primary>Property Sheet</primary></indexterm>
<indexterm><primary>Property Sheet Page</primary></indexterm>
@@ -993,11 +1003,11 @@
ooDialog supports two approaches to embedding content in a Tab Control: a Property Sheet Dialog with a
Property Sheet Page for each tab, and a Resource Dialog with a Control Dialog for each tab.
<indexterm><primary>Control Dialog</primary></indexterm>
- <footnote><para>By "resource dialog" is meant
- an RcDialog, a ResDialog or a UserDialog. The two former have resources defined in a resource file, whereas
+ <footnote><para>By "resource dialog" is meant
+ an RcDialog, a ResDialog or a UserDialog. The two former have resources defined in a resource file, whereas
the latter's resources are defined programmatically.
See the ooDialog Reference for a full description.</para></footnote>
- One important difference is that while the Property Sheet Dialog approach
+ One important difference is that while the Property Sheet Dialog approach
is simpler (more is handled by the operating system), it does not allow for interesting controls to be placed
on the main dialog outside the Tab Control. Thus the alternate approach - Control Dialogs - is used for the Order Form.
</para>
@@ -1015,15 +1025,15 @@
</simplelist>
</para>
<para>The Order Form consists of three dialogs - the main Resource File Dialog (an <computeroutput>RcDialog</computeroutput>)
- plus two Control Dialogs (<computeroutput>RcControlDialog</computeroutput>) in a Tab Control. The two Control Dialogs -
- one for Customer Details and one for details of Products ordered, are
+ plus two Control Dialogs (<computeroutput>RcControlDialog</computeroutput>) in a Tab Control. The two Control Dialogs -
+ one for Customer Details and one for details of Products ordered, are
created in the <computeroutput>activate</computeroutput> method as follows:
<programlisting><![CDATA[
cd1 = .CustDetailsDlg~new("Order\OrderFormView.rc", IDD_ORDFORM_CUST_DIALOG)
cd2 = .OrderLinesDlg~new("Order\OrderFormView.rc", IDD_ORDFORM_ORDLINES_DIALOG)
tabContent = .array~of(cd1, cd2)
cd1~ownerDialog = self
- self~prep(tabContent)
+ self~prep(tabContent)
]]></programlisting>The <computeroutput>prep</computeroutput> method is then called to set up the tabs:
<programlisting><![CDATA[
::METHOD prep
@@ -1033,10 +1043,10 @@
lastSelected = 0
self~connectTabEvent(IDC_ORDFORM_TABS, SELCHANGE, onNewTab)
]]></programlisting>The 'havePositioned' array is used to determine if the page dialogs have been
- positioned, and both are marked as not positioned. Then "no tab yet selected" is set. Finally, an
+ positioned, and both are marked as not positioned. Then "no tab yet selected" is set. Finally, an
event handling method is are connected to the event 'onNewTab'.</para>
- <para>Next, in the <computeroutput>initDialog</computeroutput> method, the tabs are added to the tab control,
- their size is calculated, and the control dialog used for the first page is positioned and
+ <para>Next, in the <computeroutput>initDialog</computeroutput> method, the tabs are added to the tab control,
+ their size is calculated, and the control dialog used for the first page is positioned and
shown:
<programlisting><![CDATA[
::METHOD initDialog
@@ -1051,22 +1061,22 @@
</para>
<para>The two methods <computeroutput>calculateDisplayArea</computeroutput> and <computeroutput>positionAndShow</computeroutput>
are well-commented, and are copied from the ooDialog sample program <computeroutput>oodListViews.rex</computeroutput>
- - one of the excellent
- samples in the <computeroutput>samples\oodialog\propertySheet.tabControls</computeroutput> folder, which is in the
- <computeroutput>Program Files\ooRexx</computeroutput> folder.
+ - one of the excellent
+ samples in the <computeroutput>samples\oodialog\propertySheet.tabControls</computeroutput> folder, which is in the
+ <computeroutput>Program Files\ooRexx</computeroutput> folder.
</para>
<para>
Note that it's essential to properly close the control dialogs in the <computeroutput>cancel</computeroutput> and/or
<computeroutput>ok</computeroutput> methods. This must be done using the <computeroutput>endExecution</computeroutput>
method.</para>
- <para>Finally, the Order Form illustrates one use of the <computeroutput>DateTimePicker</computeroutput> control.
+ <para>Finally, the Order Form illustrates one use of the <computeroutput>DateTimePicker</computeroutput> control.
<indexterm><primary>DateTime class</primary></indexterm>
<indexterm><primary>DateTimePicker</primary></indexterm>
<indexterm><primary>OrderForm</primary><secondary>DateTime class</secondary></indexterm>
<indexterm><primary>OrderForm</primary><secondary>DateTimePicker</secondary></indexterm>
- This is a very fully-featured control, providing many ways of displaying and manipulating date and time.
+ This is a very fully-featured control, providing many ways of displaying and manipulating date and time.
For the Order Form it allows the user easily to specify the Order Date. It's partly configured in the
- .rc file (in ResEdit, "Use Spin Control" is set to "false" and "Format" is set to "Short Date"), and partly in code,
+ .rc file (in ResEdit, "Use Spin Control" is set to "false" and "Format" is set to "Short Date"), and partly in code,
as follows:
<programlisting><![CDATA[
::METHOD initDialog
@@ -1077,8 +1087,8 @@
maxOrderDate = today~addYears(1)
orderDate~setRange(.array~of(today,maxOrderDate))
]]></programlisting>First the format of the edit field is set. Then the ooRexx <computeroutput>DateTime</computeroutput>
- class is used to set the allowable range of dates that the user can enter: the range is from "today" (i.e. the day on
- which the dialog is used) to a year from "today".
+ class is used to set the allowable range of dates that the user can enter: the range is from "today" (i.e. the day on
+ which the dialog is used) to a year from "today".
</para>
</section>
<!-- End of Section 7.6 -->
@@ -1087,8 +1097,8 @@
<section id="chap07-next">
<title id="ch7-next">Completing the Application</title>
<!-- Section 7.7 -->
- <para>At this point, there is more to do to complete the application. For example, generic function
- such as that found in the List components could be moved to a superclass; the three view superclasses could be
+ <para>At this point, there is more to do to complete the application. For example, generic function
+ such as that found in the List components could be moved to a superclass; the three view superclasses could be
made into a single mixin class; the Order Form needs to provide for data to be entered and stored;
SQL could be used for data-on-disk; updates could properly implemented, and it would be nice if the user
could use drag-and-drop to enter data into the Order Form. It is planned that some or all of these functions
|