Revision: 6975
http://oorexx.svn.sourceforge.net/oorexx/?rev=6975&view=rev
Author: miesfeld
Date: 2011-05-28 23:33:32 +0000 (Sat, 28 May 2011)
Log Message:
-----------
[3308860] Typos in ooDialog Reference. Patch supplied by Oliver Sims
Modified Paths:
--------------
docs/trunk/oodialog/dataAttributes.xml
docs/trunk/oodialog/dialogControlObject.xml
docs/trunk/oodialog/dialogObject.xml
docs/trunk/oodialog/edit.xml
docs/trunk/oodialog/listview.xml
docs/trunk/oodialog/overview.xml
docs/trunk/oodialog/resources.xml
docs/trunk/oodialog/userdialog.xml
docs/trunk/oodialog/windowBase.xml
Modified: docs/trunk/oodialog/dataAttributes.xml
===================================================================
--- docs/trunk/oodialog/dataAttributes.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/dataAttributes.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -62,7 +62,7 @@
the control.
</para>
<para>
- In order to better understand the data attribute methods, it is userful to first discuss this concept in general.
+ In order to better understand the data attribute methods, it is useful to first discuss this concept in general.
During the <link linkend="sctHistory">original</link> development of ooDialog the abstraction used was that there were
only two objects. One was the Rexx dialog object and the other was the <link
linkend="ovvUnderlying">underlying</link> system dialog that the user sees on the screen. Dialog controls were not
@@ -230,7 +230,7 @@
<varlistentry id="termCreateAutoNames"><term><emphasis role="bold">UserDialog create... methods:</emphasis></term>
<listitem>
<para>
- In the typical <computeroutput>UserDialog</computeroutput>all cotrols are added to the dialog by using one of the
+ In the typical <computeroutput>UserDialog</computeroutput> all controls are added to the dialog by using one of the
<link linkend="sctCreateMethods">create...</link> methods. This is similar to using one of the connect... methods.
The attribute name argument can be omitted, or the specified attribute name might not be valid. For these cases,
the internally generated name is created in this way:
Modified: docs/trunk/oodialog/dialogControlObject.xml
===================================================================
--- docs/trunk/oodialog/dialogControlObject.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/dialogControlObject.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -45,7 +45,7 @@
<indexterm><primary>dialog control object</primary></indexterm>
<indexterm><primary>DialogControl class</primary></indexterm>
<para>
- This chapter discussses the <emphasis role="italic">dialog control object</emphasis> is a fashion similar to the <link
+ This chapter discussses the <emphasis role="italic">dialog control object</emphasis> in a fashion similar to the <link
linkend="chpDialogObject">dialog object</link>. It lists the methods that are common to all dialog controls. In the
graphical user interface (GUI) for the Windows operating system both dialogs and dialog controls are windows.
Therefore, many of the methods of a dialog control object are the same as the methods of the dialog object. These are
Modified: docs/trunk/oodialog/dialogObject.xml
===================================================================
--- docs/trunk/oodialog/dialogObject.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/dialogObject.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -1434,6 +1434,7 @@
</programlisting>
<para>
+ <indexterm><primary>dlgData.</primary></indexterm>
Although the dialog object is an abstract class that the programmer will not instantiate directly, the programmer
should understand the arguments of the dialog object's <emphasis role="italic">new</emphasis>() method. Recall that
in ooRexx, when a new object is instantiated, the <emphasis role="italic">new</emphasis> method invokes the <emphasis
Modified: docs/trunk/oodialog/edit.xml
===================================================================
--- docs/trunk/oodialog/edit.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/edit.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -2715,7 +2715,7 @@
<varlistentry><term><emphasis role="bold">Arguments:</emphasis></term>
<listitem>
<para>
- The signle argument is:
+ The single argument is:
<variablelist>
<varlistentry id="argsAddStyle"><term>style [required]</term>
<listitem>
Modified: docs/trunk/oodialog/listview.xml
===================================================================
--- docs/trunk/oodialog/listview.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/listview.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -2362,7 +2362,7 @@
listView = self~newListView(IDC_LV_PROPERTIES)
d = .Directory~new
- if listView~getClumnInfo(column, d) then do
+ if listView~getColumnInfo(column, d) then do
msg = "Column Title : " d~text || .endOfLine || -
"Column Number: " d~subitem || .endOfLine || -
@@ -2618,7 +2618,7 @@
</para></listitem></varlistentry>
<varlistentry><term>width</term>
<listitem><para>The width of the column, in pixels. If you omit this argument, the column
-is sized automatically.
+is sized automatically to the widest item in the list.
</para></listitem></varlistentry>
</variablelist>
</para></listitem></varlistentry>
Modified: docs/trunk/oodialog/overview.xml
===================================================================
--- docs/trunk/oodialog/overview.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/overview.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -284,6 +284,7 @@
<section id="ovvDialogTemplate"><title>Dialog Template</title>
<para>
+ <indexterm><primary>Template, Dialog</primary></indexterm>
The <link linkend="ovvUnderlying">underlying</link> dialog seen by the user is created by the operating system from a
dialog template in memory. The template describes the size and position of the dialog and all of its controls. The
template also contains modifiers that control the style, behavior, and attributes of the dialog and its controls. To
@@ -600,6 +601,8 @@
<section id="defModalModeless"><title>Modal and Modeless Dialogs</title>
<para>
+ <indexterm><primary>Modal dialog</primary></indexterm>
+ <indexterm><primary>Modeless dialog</primary></indexterm>
Dialogs are executed in two basic ways. A <emphasis role="italic">modal</emphasis> dialog blocks keyboard and mouse
input to all other windows started by the program. The user can not switch to another window in the program without
closing the modal dialog. In ooDialog this is often all other dialogs started by the program. A <emphasis
Modified: docs/trunk/oodialog/resources.xml
===================================================================
--- docs/trunk/oodialog/resources.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/resources.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -382,7 +382,7 @@
<varlistentry><term>type</term>
<listitem>
<para>
- Specifies the type of the image: bitmap, icon, or cursor. You can use <link
+ A number between 0 and 255 that specifies the type of the image: bitmap, icon, or cursor. You can use <link
linkend="mthToIDClsImage">.Image~toID()</link> to get the correct numeric value for one of the
following symbols:
<simplelist type='horiz' columns='2'>
Modified: docs/trunk/oodialog/userdialog.xml
===================================================================
--- docs/trunk/oodialog/userdialog.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/userdialog.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -46,7 +46,9 @@
<para>
The <computeroutput>UserDialog</computeroutput> class is a concrete subclass of the <link
linkend="chpDialogObject">dialog</link> object. This class allows the programmer to dynamically define the dialog
- <link linkend="ovvDialogTemplate">template</link> in memory. The class provides methods to begin the dialog template,
+ <link linkend="ovvDialogTemplate">template</link> in memory.
+ <indexterm><primary>Template, Dialog</primary></indexterm>
+ The class provides methods to begin the dialog template,
to create the dialog controls within the dialog dialog template, and to read and parse a resource <link
linkend="defResourceScript">script</link>. These methods allow the programmer to create a dialog with any of the
styles or behaviors supported by the Windows operating system, and to create any of the dialog controls supported by
@@ -515,6 +517,8 @@
the x, y position arguments. The <link linkend="mthCreateCenter">createCenter</link> convenience method can also
be used to create a centered dialog.
</para>
+ <indexterm><primary>THICKFRAME</primary></indexterm>
+ <indexterm><primary>Resize a dialog</primary></indexterm>
</listitem></varlistentry>
<varlistentry><term>THICKFRAME</term>
<listitem>
@@ -6677,7 +6681,7 @@
<varlistentry><term>AUTOSCROLLV</term>
<listitem>
<para>
- Automatically scrolls text up when the user presses ENTER on the last line. This style only effects multi-line
+ Automatically scrolls text up when the user presses ENTER on the last line. This style only affects multi-line
edit controls and is not needed if a vertical scroll bar is added.
</para>
</listitem></varlistentry>
Modified: docs/trunk/oodialog/windowBase.xml
===================================================================
--- docs/trunk/oodialog/windowBase.xml 2011-05-27 03:43:14 UTC (rev 6974)
+++ docs/trunk/oodialog/windowBase.xml 2011-05-28 23:33:32 UTC (rev 6975)
@@ -3552,7 +3552,7 @@
</programlisting>
<para>
- Retrives the position of the window in pixels.
+ Retrieves the position of the window in pixels.
</para>
<variablelist>
<varlistentry><term><emphasis role="bold">Details</emphasis></term>
@@ -3574,7 +3574,7 @@
<listitem>
<para>
The position of the window, in pixels, as a <link linkend="clsPoint">Point</link> object. In the unlikely event of
- an error, the x and y co-ordingates will be 0. Of course those coordinates could be valid, check
+ an error, the x and y co-ordinates will be 0. Of course those coordinates could be valid, check
<computeroutput>.SystemErrorCode</computeroutput> for a possible error code.
</para>
</listitem></varlistentry>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 6970
http://oorexx.svn.sourceforge.net/oorexx/?rev=6970&view=rev
Author: miesfeld
Date: 2011-05-27 00:26:24 +0000 (Fri, 27 May 2011)
Log Message:
-----------
[3307124] Chapters updtedat. Patch supplied by Oliver Sims
Modified Paths:
--------------
docs/trunk/oodguide/Chapter04.xml
docs/trunk/oodguide/oodguide.xml
Added Paths:
-----------
docs/trunk/oodguide/appendix01.xml
Modified: docs/trunk/oodguide/Chapter04.xml
===================================================================
--- docs/trunk/oodguide/Chapter04.xml 2011-05-26 19:34:02 UTC (rev 6969)
+++ docs/trunk/oodguide/Chapter04.xml 2011-05-27 00:26:24 UTC (rev 6970)
@@ -51,15 +51,15 @@
-->
-<chapter id="chapFour"><title>Using Resource Dialogs</title>
-<!-- Note: Could becalled "Resource-based Dialogs" or some such... -->
+<chapter id="chapFour">
+ <title>Using Resource Dialogs</title>
+<!-- Note: Could be called "Resource-based Dialogs" or some such... -->
<indexterm><primary>Resource Dialogs</primary></indexterm>
<indexterm><primary>CustomerView component</primary></indexterm>
<indexterm><primary>ProductView component</primary></indexterm>
-<para>
- In this chapter, we start to build the sample application. The completed application
- is a rather simplistic sales order processing application. It will look something
- like the following design mockup:
+<para>In this chapter, we start to build components of the eventual sample application.
+The completed application will be a rather simplistic sales order processing application, and
+will look something like the following design mockup:
<figure id="fig0401"><title>The Sales Order Management Application</title>
<mediaobject>
<imageobject>
@@ -69,50 +69,51 @@
</mediaobject>
</figure>
The purpose of this application is to provide a vehicle for
- exploring ooDialog concepts and facilities, and this chapter addresses the use of
- "resource files". The term "resources" mean the GUI controls or widgets - edit fields,
- lists, buttons, menus, etc. - that populate a window. The easiest and arguably the
+ exploring various ooDialog concepts and facilities, and this chapter addresses the use of
+ "resource files" in the context of two "View" components - CustomerView and "Product View".
+</para>
+<para>
+ A resource file is a file that defines the GUI "resources" such as edit fields,
+ lists, buttons, menus, etc. that populate a window. The easiest and arguably the
best way to define the layout of GUI controls in a dialog window is to use a "resource editor".
A resource editor is a "wysiwyg" (what you see is what you get) development tool
- that allows a developer to design a window layout visually. This avoids the sometimes
+ that allows a developer to design a window layout visually. The output is a resource file.
+ This avoids the sometimes
tortuous effort of laying out the dialog programmatically. Although using a resource editor
is certainly not the be-all and end-all of ooDialog programming, it's very useful
for getting started quickly, and is the recommended way to define ooDialog window layouts.
</para>
-<para>
- The vehicles for exploring resource files will be the Customer
+<para>The vehicles for exploring resource files will be the Customer
and Product parts of the sample application. Although simplistic, the application is sufficiently
complex for some naming and coding conventions to be useful, and the first section of this chapter
describes these conventions. Then the use of human-readable
resource scripts is introduced in the context of a "Customer View" dialog.
- Third, the three major parts of a dialog are identified. The last section
+ Third, the three major parts of a dialog are discussed. The last section
then introduces the use of compiled (binary) resource files in the context of a ProductView component.
</para>
<section id="chap04-convs"><title>Naming and Coding Conventions</title><!-- section 4.1 -->
<section id="chap04-convs-names"><title>Naming Conventions</title><!-- section 4.1.1 -->
-<para>
- Readers may prefer to skip this section, at least for the tiem being, and go straight
+<para>Readers may prefer to skip this section, at least for the tiem being, and go straight
to <link linkend='chap04-resourcefile'>Resource Scripts and Resource File Editors</link>.
</para>
-<para>
- At the beginning of Chapter 2 there was a brief discussion about separation of concerns into
- three areas: the UI including both presentation and user action, the "business", and accessing data.
- From here onwards, this approach becomes an important convention for the structure of the sample
- Order Management application. Essentially we
- adopt a "component" approach to the application. Thus the "customer"
- concept is implemented by three "main" classes <computeroutput>CustomerView</computeroutput>,
- <computeroutput>CustomerModel</computeroutput>, and <computeroutput>CustomerData</computeroutput>.
- By "main class" is meant the class that implements the business concept as opposed to subsidiary
- classes such as an "address" class that might be used within the Customer component. Such subsidiary
- classes are typically included in the same file as the main class. The name given to
- the group of main classes that contribute to a single important business concept
- such as "customer" is "business component". Thus in our sample application, CustomerView,
- CustomerModel and CustomerData are the three parts of the Customer Business Component.
+<para>At the beginning of Chapter 2 there was a brief discussion about separation of concerns into
+ three areas: the UI including both presentation and user action, the "business", and
+ accessing data. From here onwards, this approach becomes an important convention for the
+ structure of the sample Order Management application. Essentially we adopt a "component"
+ approach to the application. Thus the "customer" concept is implemented by three "main"
+ classes <computeroutput>CustomerView</computeroutput>,
+ <computeroutput>CustomerModel</computeroutput>, and
+ <computeroutput>CustomerData</computeroutput>. By "main class" is meant the class that
+ implements the business concept as opposed to subsidiary classes such as an "address" class
+ that might be used within the Customer component. Such subsidiary classes are typically
+ included in the same file as the main class. The name given to the group of main classes
+ that contribute to a single important business concept such as "customer" is "business
+ component". Thus in the sample application, CustomerView, CustomerModel and CustomerData are
+ the three parts of the Customer Business Component.
</para>
-<para>
- The naming convention
+<para>The naming convention
used to distinguish between the three different kinds of main class is to provide one of the suffices
"View", "Model", or "Data" to the class name. Thus for example:
<computeroutput>CustomerView</computeroutput> will be the name of the "UI" part of the
@@ -123,17 +124,13 @@
<computeroutput>xxxMAD.rex</computeroutput>, where "xxx" is the business concept name,
and MAD is short for "Model and Data".
</para>
-<para>
- By the way, in real-life systems
- there would probably be four parts to a concept such as "customer" - a view and a user-oriented model
- both suppporting the user, and, supporting multiple concurrent users on a
- server or back-end system, a business-oriented "model"
- plus a data part that accesses the corporate database. Also by the way, in real-life supply chain
- management apps addresses are typically treated as separate entities rather than being lumped
- in with such concepts as Customer, Employee or Supplier.
-</para>
-<para>
- Finally, variables often have a prefix that indicates what the variable is.
+<para>By the way, in real-life systems there would probably be four parts to a concept such as
+ "customer" - a view and a user-oriented model both supporting the user, and, supporting
+ multiple concurrent users on a server or back-end system, a business-oriented "model" plus a
+ data part that accesses the corporate database. Also by the way, in real-life supply chain
+ management applications, addresses are typically treated as separate entities rather than
+ being lumped in with such concepts as Customer, Employee or Supplier. </para>
+<para>Finally, variables often have a prefix that indicates what the variable is.
For example, an edit control that holds a customer number would be named
<emphasis role='italic'>ecCustNo</emphasis>, the <emphasis role='italic'>ec</emphasis>
being short for "edit control".
@@ -141,134 +138,135 @@
</section><!-- End of section 4.1.1 -->
<section id="chap04-convs-coding"><title>Coding Conventions</title><!-- section 4.1.2 -->
-<para>
- The following coding conventions are used in the exercise code. First, ooRexx
- keywords are capitalized.
- Second, classes, methods, and routines are separated from each other by dotted
- or solid lines which in some editors are displayed in a different color from the
- executable code. This provides useful visual separation of methods and classes
- which is useful in larger programs.
- Third, camel case is used for variable names, with class names having their first
- letter capitalized. Fourth,
- when a rex program in one of the exercises is run, comments produced with
- an ooRexx "say" instruction may appear in the command prompt window. The format
- used for these comments is [classname]-[methodname]-[nn] - a little excessive for
- simple single-class programs, but useful for larger multi-class applications.
- Finally, variables in oorexx classes may often have prefixes indicating what they
- are; for example, an instance of an edit control containing a customer number
- would be called <emphasis role='italic'>ecCustNo</emphasis>.
+<para>The following coding conventions are used in the exercise code. First, ooRexx keywords are
+ capitalized. Second, classes, methods, and routines are separated from each other by dotted
+ or solid lines which in some editors are displayed in a different color from the executable
+ code. This provides useful visual separation of methods and classes which is useful in
+ larger programs. Third, camel case is used for variable names, with class names having their
+ first letter capitalized. Finally, when an ooRexx program in one of the exercises is run,
+ comments produced with an ooRexx "say" instruction may appear in the command prompt window.
+ The format used for these comments is [classname]-[methodname]-[nn] - a little excessive for
+ simple single-class programs, but useful for larger multi-class applications.
</para>
</section><!-- End of section 4.1.2 -->
</section><!-- End of section 4.1 -->
<section id="chap04-resourcefile"><title>Resource Scripts and Resource File Editors</title><!-- section 4.2 -->
-<para>
- Our first foray into the sample Order Management application is to examine a simple
+<para>Our first foray into the sample Order Management application is to examine a simple
Customer View component built using a resource editor.
</para>
-<para>
- But which resource editor? Well, if you happen to have Microsoft's development kit, you'll find it has a
- resource editor. Alternatively, there are a number of fee and free resource editors available
- on the web. The author of this Guide happened to use a freeware product called
- ResEdit (see <ulink url="http://www.resedit.net/"><citetitle>www.resedit.net</citetitle></ulink&gt;), and occasional
- hints about ResEdit usage will appear from time to time. In addition, comments about the use of resource file editors
- will assume ResEdit, and may well be inapplicable to other resource editors. If you plan to use ResEdit, please be
- aware that a number of Microsoft header files are required. These can be obtained at no charge from
- <ulink url="http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505"><citetitle>Microsoft Windows SDK</citetitle></ulink>
- They should be downloaded into a folder, and the full path name of that folder must be specified to ResEdit
- in "Options-Preferences-General-Include paths".
+<para>But which resource editor? Well, if you happen to have Microsoft's development kit, you'll
+ find it has a resource editor. Alternatively, there are a number of fee and free resource
+ editors available on the web. The author of this Guide happened to use a freeware product
+ called "ResEdit" (see
+ <!-- <ulink url="http://www.resedit.net/"><citetitle>www.resedit.net</citetitle></ulink&gt; -->),
+ and occasional hints about ResEdit usage will appear from time to time. In addition, comments
+ about the use of resource file editors will assume ResEdit, and may well be inapplicable to
+ other resource editors. If you plan to use ResEdit, please be aware that a number of Microsoft
+ header files are required. These can be obtained at no charge from
+ <!-- <ulink url="http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c17ba869-9671-4330-a63e-1fd44e0e2505"&gt;
+ <citetitle>Microsoft Windows SDK</citetitle></ulink>. -->
+ They should be downloaded into a folder, and the full path name of that folder must be
+ specified to ResEdit in "Options - Preferences - General - Include paths".
</para>
-<para>
- A resource file editor outputs a window layout to a "resource file", which ooDialog can then
+<para>A resource file editor outputs a window layout to a "resource file", which ooDialog can then
use to lay out controls on a dialog automatically. There are two kinds of resource file:
a human-readable file with the extension ".rc" (and sometimes ".dlg"), and a binary (compiled)
file with the extension ".res".
</para>
-<para>
- Locate the folder <computeroutput>Exercise04a</computeroutput>, and run
- <computeroutput>Startup.rex</computeroutput>. You see a "Customer" dialog.
- Explore the menu and behavior of this dialog. Note the following:
- <itemizedlist>
- <listitem><para>A number of comments appear on the console; ignore them for the time being.</para></listitem>
- <listitem><para>The title bar (the blue bar right at the top of the dialog window)
- shows not the Customer's name, but the string "*CustomerName*", sugegesting that the programmer has
- either made an error or (as in this case) has left a marker for future modification.</para></listitem>
- <listitem><para>Edit controls are shown grayed out or "disabled" - that is, not editable.</para></listitem>
- <listitem><para>The "Action" menu has four items.</para></listitem>
- <listitem><para>One button - "Record Changes" is disabled, the other is not.</para></listitem>
- </itemizedlist>
- Make sure you exercise the menu items and buttons to explore the dialog's behavior.
- You'll find that some expected behavior is not implemented, and results in a message-box - for example
- "PRINT is not a method of CustomerView".
- Note also the tab order - that is, the order <indexterm><primary>Tab order</primary></indexterm>
- of controls reached as you press the tab key. This is defined by the sequence in
- which controls appear in the .rc file. If the tab order is not as you'd like it, you
- can edit the .rc file and use cut-and-paste to achieve the desired tab order.
+<para>Locate the folder <computeroutput>Exercise04a</computeroutput>, and run
+ <computeroutput>Startup.rex</computeroutput>. You see a "Customer" dialog. Explore the menu
+ and behavior of this dialog. Note the following: <itemizedlist>
+ <listitem>
+ <para>A number of comments appear on the console; ignore them for the time being.</para>
+ </listitem>
+ <listitem>
+ <para>The title bar (the blue bar right at the top of the dialog window) shows not the
+ Customer's name, but the string "*CustomerName*", suggesting that the programmer has
+ either made an error or (as in this case) has left a marker for future
+ modification.</para>
+ </listitem>
+ <listitem>
+ <para>Edit controls are shown grayed out or "disabled" - that is, not editable.</para>
+ </listitem>
+ <listitem>
+ <para>The "Action" menu has four items.</para>
+ </listitem>
+ <listitem>
+ <para>One button - "Record Changes" is disabled, the other is not.</para>
+ </listitem>
+ </itemizedlist>Make sure you exercise the menu items and buttons to explore the dialog's
+ behavior. You'll find that some expected behavior is not implemented, and results in a
+ message-box - for example "PRINT is not a method of CustomerView". Note also the tab order -
+ that is, the order <indexterm>
+ <primary>Tab order</primary>
+ </indexterm> of controls reached as you press the tab key. This is defined by the sequence in
+ which controls appear in the .rc file. If the tab order is not as you'd like it, you can edit
+ the .rc file and use cut-and-paste to achieve the desired tab order. </para>
+<para>Now double-click the file <computeroutput>CustomerView.rc</computeroutput> in the
+ <computeroutput>Exercise04a</computeroutput> folder. The file should open in ResEdit (or
+ your own preferred resource editor). In the ResEdit "Resources" window, double-click on
+ <computeroutput>IDD_DIALOG1</computeroutput> and the dialog layout tool opens, looking like
+ this: <figure id="fig0402">
+ <title>A Resource Editor</title>
+ <mediaobject>
+ <imageobject>
+ <!-- Note! - if we include a /imagedata tag we get an error for DSSSL! -->
+ <imagedata fileref="Chapter04-image2.jpg" scale="70">
+ </imageobject>
+ </mediaobject>
+ </figure>
+ <!-- Should the window also be shown to show how close it is to the ResEdit view?? -->
+ </para>
+ <para>You might move or re-size some of the controls, save the file, then re-run Exercise04a to
+ see your changes implemented. Check the files in the
+ <computeroutput>Exercise04a</computeroutput> folder. The files needed by ooDialog to create
+ the window are <computeroutput>CustomerView.rc</computeroutput> and
+ <computeroutput>CustomerView.h</computeroutput>. Both of these are generated by the resource
+ editor. (ResEdit tip: to cause the .h file to be named the same as the .rc file, on the menu
+ bar select Options - Preferences - Code Generation - Files, then set the "Header file name" to
+ "<emphasis role="italic">%barefilename%.h"</emphasis>.)
+ </para>
+<para>Finally, a hint from hard experience. Some resource editors have been known,
+very occasionally, to assign same ID number to two different controls in the .h file,
+or to omit a resource from the .rc file. So, if it seems that
+the wrong method is being invoked for a given symbolic ID, or some other error occurs
+which on re-checking the code seems inexplicable, it could be worth checking the .h file
+to see whether the same number has been assigned to two symbolic IDs. If so, you
+can try hand-editing the .h file then re-starting the resource editor. If the .h
+file looks OK, then you might check the .rc file to see if all the resources are there.
</para>
-<para>
- Now double-click the file <computeroutput>CustomerView.rc</computeroutput> in the
- <computeroutput>Exercise04a</computeroutput> folder. The file should open in
- ResEdit (or your own preferred resource editor). In the ResEdit "Resources" window, double-click on
- <computeroutput>IDD_DIALOG1</computeroutput> and the dialog layout tool opens, looking like this:
- <figure id="fig0402"><title>A Resource Editor</title>
- <mediaobject>
- <imageobject>
- <!-- Note! - if we include a /imagedata tag we get an error for DSSSL! -->
- <imagedata fileref="Chapter04-image2.jpg" scale="70">
- </imageobject>
- </mediaobject>
- </figure>
- You might move or re-size some of the controls, save the file, then re-run Exercise04a to
- see your changes implemented. Check the files in the <computeroutput>Exercise04a</computeroutput>
- folder. You'll see the files needed for
- ooDialog to create the window that was defined in the resource editor. They are
- <computeroutput>CustomerView.rc</computeroutput> and <computeroutput>CustomerView.h</computeroutput>.
- Both of these are generated by the resource editor. (ResEdit tip: to cause the .h file
- to be named the same as the .rc file, on the menu bar select Options - Preferences - Code Generation -
- Files, then set the "Header file name" to "<emphasis role='italic'>%barefilename%.h"</emphasis>.)
- Other header files from the downloaded Microsoft SDK are also required, and are
- automatically loaded by ResEdit from the folder(s) defined in its "Include paths"
- (found in Options - Preferences - General).
-</para>
</section>
<section id="chap04-rcdialogcode"><title>Coding an RcDialog Class</title><!-- section 4.3 -->
-<para>
- Now that we have a notion about what we want to build a Customer View component), and some
- inkling of how to define dialog layouts
- using a resource editor, let's look at the code. First, look at <computeroutput>Startup.rex</computeroutput>.
- There's only one executable statement: <emphasis role='italic'>call startCustomerView</emphasis>.
- This routine is in the <computeroutput>CustomerView.rex</computeroutput> file. It's generally good
- practice to separate application startup concerns from the various working parts of the application
- - including creating new dialogs.
-</para>
-<para>
- Open <computeroutput>CustomerView.rex</computeroutput> with a text editor.
- Look for the <computeroutput>CLASS</computeroutput> statement:
- <programlisting>
+<para>Having discussed coding conventions and resource editors, this section now looks in detail at
+ the code in the <computeroutput>Exercise04a</computeroutput> folder. First, look at
+ <computeroutput>Startup.rex</computeroutput> in an editor. There's only one executable
+ statement: <emphasis role="italic">call startCustomerView</emphasis>. This routine is in the
+ <computeroutput>CustomerView.rex</computeroutput> file (it's generally good practice to
+ separate application startup concerns - such as creating new dialogs - from the various
+ working parts of the application). </para>
+<para>Now look at <computeroutput>CustomerView.rex</computeroutput> in an editor. Look for the
+ <computeroutput>CLASS</computeroutput> statement: <programlisting>
<![CDATA[
::CLASS 'CustomerView' SUBCLASS RcDialog PUBLIC
]]>
- </programlisting>
- The <computeroutput>CustomerView</computeroutput> class is a subclass of the ooDialog built-in
- class <computeroutput>RcDialog</computeroutput>, which gets its dialog layout from a
- resource script file (human-readable using a text editor.
- RcDialog is one of two important ooDialog classes that use
- resource scripts; the other is <computeroutput>ResDialog</computeroutput>, which uses a binary
- (compiled) resource file. More information can be found in chapter 6 of the ooDialog Reference.
-</para>
-<para>
- View classes can be seen as consisting of three major parts: setting up the dialog,
- specifying the active controls, and handling the application data and function. Let's look at
- each of these in the context of <computeroutput>CustomerView.rex</computeroutput>.
-</para>
+ </programlisting><computeroutput>CustomerView</computeroutput> is a subclass of the
+ ooDialog built-in class <computeroutput>RcDialog</computeroutput>, which gets its dialog
+ layout from a resource script file that is human-readable (using a text editor). RcDialog is
+ one of two important ooDialog classes that use resource scripts; the other is
+ <computeroutput>ResDialog</computeroutput>, which uses a binary (compiled) resource file as
+ illustrated in the last section of this chapter. More information on resource files can be
+ found in chapter 6 of the ooDialog Reference. </para>
+<para>View classes can be seen as consisting of three major parts: setting up the dialog window,
+ specifying the "active" controls (i.e. controls that need to be accessed programmatically),
+ and handling the application data and function. Let's look at each of these in the context of
+ <computeroutput>CustomerView.rex</computeroutput>. </para>
-<section id="chap04-rcdialogcode-setup"><title>Setting Up the Dialog</title><!-- section 4.3.2 -->
-<para>
- When you ran <computeroutput>StartUp.rex</computeroutput>, there were an initial set
- of comments displayed in the command prompt window, as follows:
- <programlisting>
+<section id="chap04-rcdialogcode-setup"><title>Setting Up the Dialog Window</title><!-- section 4.3.1 -->
+<para>When you ran <computeroutput>StartUp.rex</computeroutput>, there were an initial set of
+ comments displayed in the command prompt window, as follows: <programlisting>
<![CDATA[
D:\...\Exercise04a>startup
StartCustomerView Routine-01: .CustomerView~new...
@@ -278,48 +276,60 @@
CustomerView-activate-01
CustomerView-initDialog-01
]]>
- </programlisting>
- These comments trace the process of establishing a dialog to the point of making the window visible
- - in other words, setting up the dialog. The process is as follows:
- <orderedlist>
- <listitem><para>The routine in <computeroutput>CustomerView.rex</computeroutput>
- creates an instance of the <computeroutput>CustomerView</computeroutput> class
- that's a subclass of <computeroutput>RcDialog</computeroutput>.</para></listitem>
- <listitem><para>In the <emphasis role='italic'>init</emphasis> method of the
- new view instance, first the superclass is invoked (this is an
- ooDialog requirement), and then the <emphasis role='italic'>createMenuBar</emphasis>
- method is called.</para></listitem>
- <listitem><para>the <emphasis role='italic'>createMenuBar</emphasis> method then
- creates a menubar (in this case an instance of the .ScriptMenuBar class - see
- section 25.6 of the ooDialog Reference), referring to the menubar's ID in the .rc file.
- Note that after creation, the menubar is just another object, and is not
- yet associated with the dialog. The code at this point boldly assumes that
- the menubar instance was successfully created (not really best practice) and returns
- to the <emphasis role='italic'>init</emphasis> method and from there back
- to the ...</para></listitem>
- <listitem><para>...<computeroutput>StartCustomerView</computeroutput> routine,
- which invokes the dialog's <emphasis role='italic'>activate</emphasis> method.
- </para></listitem>
- <listitem><para>The <emphasis role='italic'>activate</emphasis> method
- issues <computeroutput>ShowTop</computeroutput> to
- the view's superclass, which then sends itself an
- <emphasis role='italic'>initDialog</emphasis> message.</para></listitem>
- <listitem><para>The <emphasis role='italic'>initDialog</emphasis> method attaches
- the menubar to itself (that is, to the dialog instance). It also does an
- additional three things that are nothing to do with establishing the dialog
- but which are part of managing controls and handling application data.
- </para></listitem>
- </orderedlist>
-</para>
-<!-- Need link to mini-sections about control objects, event handlers, and get/show data. -->
-<para>
- The above process requires four methods and a total of 19 oorexx statements
- including the <computeroutput>method</computeroutput> statements but excluding the
- <emphasis role='italic'>say</emphasis> instructions. And if we didn't care too much for
- effective program structure or error checking, it could be squished down to
- just nine instructions as follows:
+ </programlisting>These comments trace the process of establishing a dialog to the point of
+ making the window visible - in other words, setting up the dialog. One routine and four
+ methods are involved, as follows: <orderedlist>
+ <listitem>
+ <para>The routine in <computeroutput>CustomerView.rex</computeroutput> creates an
+ instance of the <computeroutput>CustomerView</computeroutput> class that's a subclass
+ of <computeroutput>RcDialog</computeroutput>.</para>
+ </listitem>
+ <listitem>
+ <para>In the <emphasis role="italic">init</emphasis> method of the new view instance,
+ first the superclass is invoked (this is an ooDialog requirement), and then the
+ <emphasis role="italic">createMenuBar</emphasis> method is called. Note that if the
+ menubar creation fails, then <emphasis role="italic">initCode</emphasis> is an
+ attribute of a <computeroutput>.Dialog</computeroutput> instance. It represents the
+ success of initialization of a dialog object. For a dialog object, after the <emphasis
+ role="italic">init</emphasis> method has executed the <emphasis role="italic"
+ >initCode</emphasis> attribute will be zero if the dialog initialization detected no
+ errors. The attribute will be non-zero if initialization failed or an error was
+ detected. </para>
+ </listitem>
+ <listitem>
+ <para>The <emphasis role="italic">createMenuBar</emphasis> method then creates a menubar
+ (in this case an instance of the .ScriptMenuBar class - see section 25.6 of the
+ ooDialog Reference), referring to the menubar's ID in the .rc file. Note that after
+ creation, the menubar is just another object, and is not yet associated with the
+ dialog. The code at this point boldly assumes that the menubar instance was
+ successfully created (not really best practice) and returns to the <emphasis
+ role="italic">init</emphasis> method and from there back to the ...</para>
+ </listitem>
+ <listitem>
+ <para>...<computeroutput>StartCustomerView</computeroutput> routine, which invokes the
+ dialog's <emphasis role="italic">activate</emphasis> method. </para>
+ </listitem>
+ <listitem>
+ <para>The <emphasis role="italic">activate</emphasis> method issues
+ <computeroutput>SHOWTOP</computeroutput> to the view's superclass, which then sends
+ itself an <emphasis role="italic">initDialog</emphasis> message.</para>
+ </listitem>
+ <listitem>
+ <para>The <emphasis role="italic">initDialog</emphasis> method attaches the menubar to
+ itself (that is, to the dialog instance). The remainder of the method is concerned
+ with specifying the active controls, which is addressed in the next section.</para>
+ </listitem>
+ </orderedlist>
+ </para>
+<para>The above process requires four methods and a total of 19 ooRexx statements including the
+ <computeroutput>::Method</computeroutput> statements but excluding the <emphasis
+ role="italic">say</emphasis> instructions. And if we didn't care too much for effective
+ program structure or error checking, it could be squished down to just nine instructions as
+ follows:
<programlisting>
<![CDATA[
+ ::ROUTINE startCustomerView PUBLIC
+ dlg = .CustomerView~new("customerView.rc", IDD_DIALOG1, dlgData., "customerView.h")
::CLASS CustomerView SUBCLASS RcDialog PUBLIC
::METHOD init
forward class (super) continue
@@ -327,145 +337,320 @@
::METHOD initDialog
menuBar = .scriptMenuBar~new("CustomerView.rc", "IDR_MENU1", self, , , .true)
menuBar~attachTo(self)
- ::ROUTINE startCustomerView PUBLIC
- dlg = .CustomerView~new("customerView.rc", IDD_DIALOG1, dlgData., "customerView.h")
]]>
</programlisting>
- And if the <computeroutput>::class</computeroutput>, <computeroutput>::method</computeroutput>,
- <computeroutput>::routine</computeroutput> directives are excluded, only five statements
- are required.
-</para>
+ And if the <computeroutput>::class</computeroutput>,
+ <computeroutput>::method</computeroutput>, and <computeroutput>::routine</computeroutput>
+ directives are excluded, only five statements are required: <emphasis role="italic">~new</emphasis>
+ to create a dialog instance, call super in the <emphasis role="italic">init</emphasis>
+ method, do <emphasis role="italic">execute("SHOWTOP")</emphasis>, create a menubar,
+ and attach the menubar to self.</para>
<para>
In other words, dialogs of significant complexity can be created and displayed with
- only five executable statements. And that, gentle reader, is the real power of resource dialogs.
+ only five executable statements. And that is the real power of resource dialogs.
</para>
</section>
<section id="chap04-rcdialogcode-controls"><title>Specifying the Active Controls</title><!-- section 4.3.2 -->
-<para>
- An "active control" is a control that requires behavior to be programmed, while
- a "passive" control (such as text that is never changed) appears only in
- the resource file, and is of no concern to the program. The behavior associated
- with an active control is
- of two kinds: outbound or program-to-window - i.e. providing the user with information, and
- inbound - i.e. signalling the progam about a user event.
- Outbound behavior means changing the state of a control - for example,
- disabling a pushbuton, or displaying text in an
- edit control. Inbound behavior is a user event that requires the program to
- take some action - e.g. selecting a menu item, or clicking a pushbutton.
- For both inbound and outbound behavior, the relevant controls must be specified
- in the ooRexx program, and a reference to them established.
-</para>
-<para>
- Now controls are actually created by Windows based on information
- in the resource file, with each control being created and managed by
- facilities built into the Windows operating system. However,
- the ooRexx programmer accesses controls via ooDialog classes, so that each
- control on a window is represented in an ooRexx program by an ooRexx object.
- Under the covers, ooDialog
- provides the required link between the ooRexx objects and the underlying Windows
- facilities - and hence with the visible controls on the screen. By the way,
- and rather obviously (but we'll say it anyway), this means that ooDialog
- cannot provide any GUI function that is not already provided by the underlying
- Windows facilities.
-</para>
-<para>
- ooDialog provides a class for each control type (see chapters
- 11 through 24 of the ooDialog reference), and, as mentioned, instances of
- these classes invisibly connect to the underlying Windows mechanisms.
- The connection
- for each control is done via the the control's symbolic ID in the .rc file.
- Thus in order to use active controls, and so provide the requires application
- function, the programmer must first specify them. This is typically done in the
- <emphasis role='italic'>initDialog</emphasis> method.
- For example, to display the Customer Number in an edit control (outbound active
- behavior), it's first necessary to create an instance of an ooDialog edit
- control; for example:
- <programlisting>
+<para>An "active control" is a control that requires behavior to be programmed, while a "passive"
+ control (such as text that is never changed) appears only in the resource file, and is of no
+ concern to the program. The behavior associated with an active control is of two kinds:
+ outbound or program-to-window - i.e. providing the user with information, and inbound or
+ window-to-program - i.e. signaling the progam about a user event. Outbound behavior means
+ changing the state of a control - for example, disabling a pushbutton, or displaying text in
+ an edit control. Inbound behavior is a user event that requires the program to take some
+ action - e.g. the user selects a menu item, or clicks a pushbutton. Much inbound behavior is
+ ignored by the program (e.g. the user placing the cursor in an edit control). For both
+ inbound behavior that is relevant to the program, and also for outbound behavior, the
+ relevant controls must be made available to the programmer as ooRexx objects. </para>
+<para>Now controls are actually created by Windows, based on information in the resource file, with
+ each control being created and managed by facilities built into the Windows operating
+ system. However, the ooRexx programmer accesses controls via instances of ooDialog classes,
+ so that each control on a window is represented by an ooRexx object that is really a proxy<indexterm>
+ <primary>Proxy for controls</primary>
+ </indexterm> for the underlying Windows control. And it is ooDialog that creates the
+ required link between such ooRexx objects and the underlying Windows controls - and hence
+ between the ooRexx object and the visible controls on the screen. By the way, and rather
+ obviously (but we'll say it anyway), this means that ooDialog cannot provide any GUI
+ function that is not already provided by the underlying Windows facilities. </para>
+<para>To manage controls, ooDialog provides a class for each control type (see chapters 11 through
+ 24 of the ooDialog reference). The link between an ooRexx control and the underlying Windows
+ control is created via the control's symbolic ID in the <computeroutput>.rc</computeroutput>
+ and <computeroutput>.h</computeroutput> files. Creating the ooRexx control proxies is
+ typically done in the <emphasis role="italic">initDialog</emphasis> method. In the
+ <computeroutput>CustomerView</computeroutput> code for example, in order to display the
+ Customer Number in an edit control (outbound active behavior) an ooRexx proxy is created in
+ the <emphasis role="italic">initDialog</emphasis> method as follows: <programlisting>
<![CDATA[
ecCustNo = self~newEdit("IDC_EDIT_CUST_NO")
]]>
- </programlisting>
- The variable <emphasis role='italic'>ecCustNo</emphasis> is the edit control
- that will contain the customer number; <emphasis role='italic'>self</emphasis> is the
- dialog instance; <emphasis role='italic'>newEdit</emphasis>
- is the method of the Dialog Control object (see chapter 4 of the ooDialog Reference)
- that creates a new edit control, and "IDC_EDIT_CUST_NO"
- is the symbolic ID recorded in the .h and .rc files generated by the resource
- editor. After execution of this statement,
- <emphasis role='italic'>ecCustNo</emphasis> is an instance of the ooDialog
- <computeroutput>Edit</computeroutput> class, and ooDialog has made sure, in the
- instance's creation, that it is internally linked to the edit control on the
- screen identified in the .h and .rc files as
- <emphasis role='italic'>IDC_EDIT_CUST_NO</emphasis>.
-</para>
-<para>
- Suppose now that the user has pressed a button, and we want to capture that
- event to provide some feedback to the user (inbound active behavior).
- This is done by an "event handler" - that is,
- code that handles the event. In ooDialog programs,
- an event handler is a method. The following statement in the
- <computeroutput>CustomerView</computeroutput> class defines the handler method
- for the event of the user clicking the "Show Last Order" button:
- <programlisting>
+ </programlisting>The variable <emphasis role="italic">ecCustNo</emphasis> is the proxy
+ ooRexx object for the Windows edit control that will contain the customer number; <emphasis
+ role="italic">self</emphasis> is the dialog instance; <emphasis role="italic"
+ >newEdit</emphasis> is the method of the Dialog Object (see chapter 3 of the ooDialog
+ Reference) that creates the ooRexx proxy for the underlying Windows control; and <emphasis
+ role="italic">IDC_EDIT_CUST_NO</emphasis> is the controls' symbolic ID from the
+ <computeroutput>.h</computeroutput> file. After execution of the statement, <emphasis
+ role="italic">ecCustNo</emphasis> is an instance of the ooDialog
+ <computeroutput>Edit</computeroutput> class, and ooDialog has made sure, in the instance's
+ creation, that it is internally linked to the edit control on the screen identified in the
+ .h and .rc files as <emphasis role="italic">IDC_EDIT_CUST_NO</emphasis>. </para>
+<para>To avoid tedious repetition, from now on this document will assume an understanding of the
+ relationship between a proxy ooRexx instance and the underlying Windows control, and will
+ mention only the ooRexx control - without using the term "proxy". </para>
+<para>A number of other outbound active controls are created in the <emphasis role="italic"
+ >initDialog</emphasis> method - as many as there are fields on the dialog that need to
+ have data placed in them when the dialog opens. In addition, a "Record Changes" pushbutton
+ object is created so that the button can be enabled (outbound active behavior) when a user
+ chooses the menu option "Update..." (inbound active behavior). </para>
+<para>After this, the following statement appears: <programlisting>
<![CDATA[
- self~connectButtonEvent("IDC_SHOW_LAST_ORDER","CLICKED",showLastOrder)
+ self~connectButtonEvent("IDC_RECORD_CHANGES","CLICKED",recordChanges)
]]>
- </programlisting>
- This statement connects the pushbutton event <emphasis role='italic'>Clicked</emphasis>
- for the button whose ID is <emphasis role='italic'>IDC_SHOW_LAST_ORDER</emphasis>
- with the event handler method <emphasis role='italic'>showLastOrder</emphasis>.
+ </programlisting>This is an example of specifying an "event handler" (inbound active
+ behavior). Suppose the user presses the "Record Changes" button. Windows signals the event.
+ The above statement states that this event - that is, the pushbutton (identified in the
+ <computeroutput>.h</computeroutput> file as
+ <computeroutput>IDC_RECORD_CHANGES</computeroutput>) is
+ <computeroutput>CLICKED</computeroutput> - will invoke the <emphasis role="italic"
+ >recordChanges</emphasis> method. In other words, the statement defines <emphasis
+ role="italic">recordChanges</emphasis> as the event-handling method for the "Record
+ Changes" pushbutton. The same is done for the "Show Last Order" pushbutton, where the event
+ handler is specified to be the method <emphasis role="italic">lastOrder</emphasis>. </para>
+<para>
+ Notice that each of the event handler methods are specified as
+ <computeroutput>UNGUARDED</computeroutput>. In general, an event handler should
+ be unguarded to preclude the possibility that some guarded method in the dialog
+ object is executing at the time the event notification is generated. For further
+ information, see ooDialog Reference sections 2.2.4, the introduction to
+ section 5.7, and also section 5.7.1.
</para>
<para>
- In general, specification of active controls is done in the
- <emphasis role='italic'>initDialog</emphasis> method. In the
+ Specification of active controls is generally done in the
+ <emphasis role='italic'>initDialog</emphasis> method. Indeed, in the
<computeroutput>CustomerView</computeroutput> class, specification of active
- controls occupies most of the <emphasis role='italic'>initDialog</emphasis>
- method. The last two statements - and indeed most of the methods in the class - belong to the
- Application and Data Function category.
+ controls occupies most of this method.
</para>
-</section>
+<para> Note that MenuBar actions are not specified. This is because the menu items in
+ <computeroutput>CustomerView.rex</computeroutput> are "auto-connected" (see the <link
+ linkend="apx-connections" endterm="connections.title"/> appendix). Auto-connection is
+ specified in the last parameter of the <emphasis role="italic">.ScriptMenuBar~new</emphasis>
+ statement (see section 25.6 of the ooDialog Reference) in the <emphasis role="italic"
+ >createMenuBar</emphasis> method: <programlisting> <![CDATA[
+ menuBar = .ScriptMenuBar~new("CustomerView.rc", "IDR_MENU1", self, , , .true)
+ ]]> </programlisting>
+ <indexterm>
+ <primary>menuBar</primary>
+ <secondary>RcDialog</secondary>
+ </indexterm>
+ <indexterm>
+ <primary>RcDialog</primary>
+ <secondary>menuBar</secondary>
+ </indexterm> Setting this parameter to <computeroutput>.true</computeroutput> (the default
+ is <computeroutput>.false</computeroutput>) specifies that all menu items will be connected
+ automatically to a method with the same name as the visible caption or text. In
+ <computeroutput>CustomerView.rc</computeroutput> the "File" sub-menu is: <programlisting> <![CDATA[
+ MENUITEM "New Customer...", IDM_NEWCUST___1
+ MENUITEM "Update...", IDM_UPDATE___1
+ MENUITEM "Print...", IDM_PRINT___1
+ MENUITEM "Last Order", IDM_XXYYZZ
+ ]]> </programlisting>Spaces and trailing dots are stripped, giving method names of
+ "NewCustomer", "Update", "Print", and "LastOrder". In the "Menu Methods" part of the
+ <computeroutput>CustomerView</computeroutput> code, a method is provided for three of
+ these menu items. There is deliberately no method provided for "Print" in order to show what
+ happens when you don't provide a method for an auto-connected menu item (you get an error
+ message box from ooDialog). </para>
+<para>But before the menu actions will work, the <emphasis role="italic">menuBar</emphasis> object
+ must be associated with the dialog object. This is done by this statement (at the beginning
+ of the <emphasis role="italic">initDialog</emphasis> method): <programlisting> <![CDATA[
+ menuBar~attachTo(self)
+ ]]>
+</programlisting></para>
+<para>At this point, the dialog is displayed complete with all its controls. But there is no data
+ shown. When executed, it looks as if the data appears at the same time as the window, but it
+ does not. To illustrate this, insert a <emphasis role="italic">call SysSleep 3</emphasis>
+ statement just before and just after the statement <emphasis role="italic">
+ menuBar~attachTo(self)</emphasis> and run the program. You'll see the window without
+ menubar, then the menubar will appear, and then the data. </para>
+<para>The last two statements in the <emphasis role="italic">initDialog</emphasis> method kick off
+ the initial parts of the Application and Data Function category. The first invokes a method
+ to retrieve the data for this customer, the second to display it. At which point the view
+ sits back and waits for the user to do something. </para>
+</section> <!-- end of section 4.3.2 -->
<section id="chap04-rcdialogcode-appdata"><title>Application Data and Function</title> <!-- section 4.3.3 -->
-<para>Designing the application function and data handling part of a main view class
-is more complex than is often thought. The designer has to consider
-a number of different possible states of the dialog, and also which state
-transitions are valid. Sometimes state and state transition charts
-are used to plan and record UI interactions. And, in doing this design work,
-the first consideration is the user. Indeed, providing
-what the user needs and likes is probably the most difficult aspect of GUI development.
-But who is "the user"? Well, this document would be going well outside its remit to
-embark on such a discussion. Suffice to say that there are a number of sources for
-information on usability, among which one of the author's favorites is
-"The Inmates Are Running The Asylum" by Alan Cooper. But here, the main concern
-is use of ooDialog rather than UI design, and so in this document, UI design takes
-second place.
+<para>Designing the application function and data handling part of a main view class is more complex
+ than is often thought. The designer has to consider a number of different possible states of
+ the dialog, and also which state transitions are valid. Sometimes state and state transition
+ charts are used to plan and record UI interactions. And, in doing this design work, the
+ first consideration is the user. Indeed, providing what the user needs and likes is probably
+ the most difficult aspect of GUI development. But who is "the user"? Well, this document
+ would be going well outside its remit to embark on addressing this question. Suffice to say
+ that there are a number of sources for information on usability, among which one of the
+ author's favorites is "The Inmates Are Running The Asylum" by Alan Cooper. But here, the
+ main concern is use of ooDialog rather than UI design per se, and so in this document, UI
+ design takes a back seat.</para>
+<para>In the case of <computeroutput>.CustomerView</computeroutput>, the application behavior is
+ very simple: <itemizedlist>
+ <listitem>
+ <para>On initial display of the CustomerView instance, populate the controls with data.
+ This is done by invoking (at the end of the <emphasis role="italic"
+ >initDialog</emphasis> method) the <emphasis role="italic">getData</emphasis> and
+ <emphasis role="italic">showData</emphasis> methods. The first gets the data for
+ this customer, and the second displays that data. The dialog then waits for user
+ input. </para>
+ </listitem>
+ <listitem>
+ <para>On "Update" being menu-selected, the edit controls are first enabled so that the
+ user can modify the data, and the "Record Changes" button is enabled.</para>
+ </listitem>
+ <listitem>
+ <para>On the "Record Changes" button being pressed, first a check is made as to whether
+ anything has in fact been changed. If so, a comment is output to the console, and the
+ state is set back to the starting position with the "Record Changes" button and edit
+ controls disabled. If nothing has been changed, a message box is displayed. </para>
+ </listitem>
+ <listitem>
+ <para>Finally, several minimal or dummy actions are provided as place-markers for
+ possible future use: three menu items (New Customer..., Print..., and Last Order) and
+ a "Show Last Order" pushbutton. The last two - the "Last Order" menu item and the
+ "Show Last Order" pushbutton illustrate how - if ever required - two or more events
+ can invove the same event handler. </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+<para>This function is delivered through nine methods: five event handler methods (three for menu
+ items and two for pushbuttons) and four methods supporting the event handlers. Between them,
+ they deliver the application and data function. The following examines the ooDialog aspects
+ of the application function. </para>
+
+<section><title>The getData and showData Methods</title> <!-- section 4.3.3.1 -->
+<para>the <emphasis role='italic'>getData</emphasis> method merely puts dummy data
+ into a directory object (in the next chapter it will retrieve data from the View's model
+ object).
</para>
<para>
-
+ The <emphasis role='italic'>showData</emphasis> method uses the
+ <emphasis role='italic'>setText</emphasis> method (see section 5.4.27 of the
+ ooDialog Reference) to set the text of the various
+ controls to the customer's data. There are two things to note here:
+ <itemizedlist>
+ <listitem><para>First, each control is in fact a separate window in its own right.
+ Thus the <emphasis role='italic'>setText</emphasis> method can be used to set the
+ text for any control. For example, the text on a pushbutton can be changed using this method.
+ To check this out, try inserting the statement:
+ <programlisting>
+ <![CDATA[
+ custControls[btnRecordChanges]~setText("Press me")
+ ]]>
+ </programlisting>
+ at the end of the <emphasis role='italic'>update</emphasis> method. When "Update"
+ is menu-selected, the text on the button changes.
+ </para></listitem>
+ <listitem><para>Second, the Customer Address data is an array, which for display
+ in a multi-line edit control must be transformed into a text string with line-ends
+ inserted at appropriate places. This kind of transformation is very usual
+ within view classes; after all, it's the responsiblity of any View class (or
+ of its subsidiary classes or routines) to handle any re-formatting for display purposes.
+ </para></listitem>
+ </itemizedlist>
</para>
+</section> <!-- end of section 4.3.3.1 -->
+<section>
+ <title>The Update and Record Changes Methods</title>
+ <!-- section 4.3.3.2 -->
+ <para> The <emphasis role="italic">update</emphasis> method enables the edit controls and
+ the "Record Changes" button so that the user can make changes and then make the changes
+ permanent (i.e. "record" them). Enabling edit controls is done by sending them the message
+ <emphasis role="italic">setReadOnly</emphasis> with the parameter
+ <computeroutput>.false</computeroutput>. For example: <programlisting>
+ <![CDATA[
+ custControls[ecCustName]~setReadOnly(.false)
+ ]]>
+ </programlisting>
+ </para>
+ <para>Pushbuttons are enabled by invoking <emphasis role="italic">enableControl</emphasis>
+ on the dialog, the parameter being the control's symbolic ID as shown in the first
+ statement below. The second statement below puts focus on the push-button - in this case
+ by invoking the <emphasis role="italic">state</emphasis> method of the control object.
+ Finally, the cursor is placed in the Customer Name edit control by invoking the dialog's
+ <emphasis role="italic">focusControl</emphasis> method.
+ <programlisting>
+ <![CDATA[
+ self~enableControl("IDC_RECORD_CHANGES")
+ custControls[btnRecordChanges]~state = "FOCUS" -- Put focus on the button
+ self~focusControl("IDC_EDIT_CUST_NAME") -- place cursor in the CustName edit control.
+ ]]>
+ </programlisting>
+ </para>
+ <para>Note that in some cases the method invoked is directly on the control object, and in
+ other cases the method belongs to the dialog object with the control being specified in a
+ method parameter. The reason for this is that some methods (such as <emphasis
+ role="italic">setText</emphasis>) are applicable to all controls, and so can be invoked
+ on any control, while others (such as <emphasis role="italic">focusControl</emphasis>)
+ have meaning within the context of the dialog as a whole. </para>
+ <para><emphasis role="bold">[OS Note: I believe that this explanation may be too simplistic
+ and quite possibly wrong. To be reviewed!]</emphasis></para>
+ <para>The dialog is now in a state whereby the user can make changes to the data. When the
+ user presses the "Record Changes" button, the <emphasis role="italic"
+ >recordChanges</emphasis> method is invoked. Processing from this point is almost all
+ plain ooRexx with little ooDialog involvement: <itemizedlist>
+ <listitem>
+ <para>The <emphasis role="italic">xformView2App</emphasis> method is invoked and
+ returns the data from the edit controls as a directory, with the address element
+ being an array. To read data that the user has entered, the method uses the
+ <emphasis role="italic">getText</emphasis> and <emphasis role="italic"
+ >getLine</emphasis> methods of the Edit Control. </para>
+ </listitem>
+ <listitem>
+ <para>Then the <emphasis role="italic">checkForChanges</emphasis> method is invoked
+ with, as a parameter, the data returned from <emphasis role="italic"
+ >xformView2App</emphasis> method. </para>
+ </listitem>
+ <listitem>
+ <para>If the data has not changed, a message box is displayed. If it has changed, then
+ the old data is replaced with the new. In either case:</para>
+ </listitem>
+ <listitem>
+ <para>The edit controls are set to read-only, and the "Record Changes" button is
+ disabled. </para>
+ </listitem>
+ </itemizedlist></para>
+ <para>Finally, one method not yet mentioned is the <emphasis role="italic">ok</emphasis>
+ method. For this dialog, <emphasis role="italic">ok</emphasis> is a no-op method provided
+ only to prevent the window being closed should the user press the enter key. </para>
+ <para><emphasis role="bold">[OS: This no longer seems to be the case - so last statement to
+ be reviewed!!]</emphasis></para>
+ </section> <!--end of section 4.3.3.2 -->
+
</section> <!-- end of section 4.3.3 -->
</section> <!-- end of section 4.3 -->
<section id="chap04-resfile"><title>Using Binary Resource Files</title> <!-- section 4.4 -->
+<para> Notes: </para>
<para>
- To be completed.
-
-
-<!-- -->
-Of the 13 methods of <computeroutput>CustomerView</computeroutput>, only 3 are to do with displaying a dialog
-
-
-
-mention why activate.
+ For a ResDialog, you use a resource-only DLL. A resource-only DLL is a resource script
+ (.rc) file compiled into binary format. ResEdit is capable of doing this compilation, with
+ two caveats:
+ <itemizedlist>
+ <listitem>
+ <para>You have to do it from the command line:</para>
+ <para><computeroutput>resedit -convert UserMenuBar.rc UserMenuBar.dll</computeroutput></para>
+ </listitem>
+ <listitem>
+ <para>It only works for 32-bit DLLs - that is, you need to be on a 32-bit system.</para>
+ </listitem>
+ <listitem>
+ <para>To work, the *.h file and any *.bmp files must be in the same directory
+ as the .rc file. If present and referenced by the .rc file, any *.bmp files
+ are also compiled into the DLL. At run-time, all that is needed is the DLL
+ and the.h file.</para>
+ </listitem>
+ </itemizedlist>
</para>
-<!--
+</section>
-Mention resedit and Options -> Preferences -> Code generation -> Files -> Header file name
-%barefilename% to get .h file same name as .rc file.
--->
-</section>
</chapter>
Added: docs/trunk/oodguide/appendix01.xml
===================================================================
--- docs/trunk/oodguide/appendix01.xml (rev 0)
+++ docs/trunk/oodguide/appendix01.xml 2011-05-27 00:26:24 UTC (rev 6970)
@@ -0,0 +1,273 @@
+<!--#########################################################################
+ #
+ # Description: Open Object Rexx: ooDialog User Guide XML file.
+ #
+ # Copyright (c) 2011-2011, Rexx Language Association. All rights reserved.
+ #
+ # This program and the accompanying materials are made available under
+ # the terms of the Common Public License v1.0 which accompanies this
+ # distribution. A copy is also available at the following address:
+ # http://www.oorexx.org/license.html
+ #
+ # Redistribution and use in source and binary forms, with or
+ # without modification, are permitted provided that the following
+ # conditions are met:
+ #
+ # Redistributions of source code must retain the above copyright
+ # notice, this list of conditions and the following disclaimer.
+ # Redistributions in binary form must reproduce the above copyright
+ # notice, this list of conditions and the following disclaimer in
+ # the documentation and/or other materials provided with the distribution.
+ #
+ # Neither the name of Rexx Language Association nor the names
+ # of its contributors may be used to endorse or promote products
+ # derived from this software without specific prior written permission.
+ #
+ # THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+ # "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+ # LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
+ # FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+ # OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ # SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
+ # TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
+ # OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
+ # OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
+ # NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ # SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ #
+ #########################################################################
+-->
+
+<!-- Appendix 01 version 00-01 - Connections (??title??)
+ This is all about connections between menus and buttons with programs.
+-->
+<appendix id="apx-connections"><title id="connections.title">Connections</title>
+<indexterm><primary>Connections</primary></indexterm>
+
+<para>
+ This appendix discusses the various ways in which events published by menu items
+ and pushbuttons can be connected to the ooRexx program.
+
+<para><emphasis role='bold'>Note: This appendix is in initial note form taken
+from several sources - it has yet to be merged, completed, checked, and
+properly marked up.</emphasis></para>
+
+<section id="app01-menus"><title>Connecting Menu Command Items to Dialog Methods</title>
+<para>
+There are basically three ways to connect menu command items to a dialog:
+<itemizedlist>
+ <listitem><para>autoConnection</para></listitem>
+ <listitem><para>connection request</para></listitem>
+ <listitem><para>directly connect</para></listitem>
+</itemizedlist>
+In general the three ways should not be mixed without without using some
+forethought. Autoconnection should never be used with the other two.
+Mixing the three ways of connecting command items to methods can result in
+unpredicatable results:
+<itemizedlist>
+ <listitem><para>
+ The same command item can end up connected to different methods, which
+ method is invoked is non-deterministic.</para></listitem>
+ <listitem><para>Numerous entries for the same command item connected to the same method
+ can happen.</para></listitem>
+ <listitem><para>Both of the above can result in the message table becoming far larger than
+ necessary.</para></listitem>
+</itemizedlist>
+
+</para>
+
+<section id="app01-menus-auto"><title>Autoconnection</title>
+<para>
+ With autoconnection on, *each* time a menu bar is attached to a dialog every
+ command item in the menu is connected to a method in the dialog it is
+ attached to. Either a method constructed from the text of the menu item or
+ all menu items are connected to a single method.
+</para>
+<para>
+ Note that if autoconnection is on, the automatic connection of menu items is
+ *always* done when a menu bar is attached to a dialog, even if the
+ connection request way of attaching menu items is also in use.
+</para>
+<para>
+ Autoconnection can be explicitly turned on by using:
+ <programlisting>
+ <![CDATA[
+ ::method setAutoConnection
+ use strict arg on, msg = ""
+ ]]>
+ </programlisting>
+ *before* a menu bar is attached to a dialog.
+</para>
+<para>
+ setAutoConnection() can also be used to turn autoconnection off at any time.
+</para>
+<variablelist><title>Font Filename Extensions</title>
+ <varlistentry>
+ <term>BinaryMenuBar</term>
+ <listitem><para>Turning autoconnection on can also be specified in the new method of a
+ .BinaryMenuBar</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>UserMenuBar:</term>
+ <listitem><para>Autoconnection can be turned on in .UserMenuBar~new().
+ Autoconnection can also be turned on explicitly using setAutoConnection()
+ after the UserMenuBar is created, but before it is attached to a dialog.
+ </para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ScriptMenuBar:</term>
+ <listitem><para>Similar to a UserMenuBar, autoconnection can be turned on after
+ the menu is created but before it is attached to a dialog.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>PopupMenu</term>
+ <listitem><para>When a popup menu is used as a submenu of a menu bar, autoconnection is
+ meaningless. A submenu can not be attached or assigned to a dialog.</para>
+ <para>When a popup menu is used as a context menu, autoconnection can be turned
+ on, either explicitly using setAutoConnection() or by using the autoConnect
+ option in the assignTo() method.</para>
+ <para>Note that setAutoConnection() has to be invoked on the top-level menu of the
+ context menu. Invoking it on a submenu of the context menu would have no
+ effect.</para>
+ <para>When the track() or show() methods are used with a popup menu,
+ autoconnection is ignored.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>insertItem() method.</term>
+ <listitem>
+ <para>If autoconnection is turned on in the menu bar that the item is inserted
+ into and the menu bar is already attached to a dialog, then the item will be
+ automatically connected, using either the autoconnectionMethod name or a
+ method name constructed from the text of the item.</para>
+ <para>This will *only* be done if the item is being inserted by ID and being
+ inserted into a menu bar, not being inserted into a popup menu.</para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+
+</section>
+
+<section id="app01-menus-requ"><title>Connection Request</title>
+<para>
+ A connection request is made when a menu command item is to be connected to
+ a specific method name in a dialog, before the menu bar has been attached to
+ a dialog. Obviously it is impossible to connect the item to a dialog
+ method, before it is known what dialog the menu bar is going to be connected
+ to.
+</para>
+<para>
+ Connection requests are made by specifying a method to invoke when adding a
+ command item to a UserMenuBar through addItem(), or by specifying the
+ connect argument in .ScriptMenu~new().
+</para>
+<para>
+ The request can also, possibly, be made by specifying a method to inovke
+ when inserting a command item through insertItem(), see below.
+</para>
+<variablelist><title>Font Filename Extensions</title>
+ <varlistentry>
+ <term>BinaryMenuBar</term>
+ <listitem><para>A connection request is not used, except possibly though the insertItem()
+ method, see below.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>UserMenuBar</term>
+ <listitem><para>In a UserMenuBar, a connection request can be made in the addItem() method
+ by specifying a method name as the last argument to addItem()</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>ScriptMenuBar</term>
+ <listitem><para>Connection requests are made by using the 'connnect' argument in the
+ ScriptMenuBar~new() method. If 'connect' is true, then a connection request
+ is made for each command item found in the resource script, using a method
+ name constructed from the text of the command item.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>PopupMenu</term>
+ <listitem><para>Connection requests have no meaning in a popup menu,
+ there is no such thing.</para></listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>insertItem() method</term>
+ <listitem><para>A connection request can be made through the insertItem() method under these
+ specific conditions. The insertItem() is invoked on a menu bar, not using
+ by position, and the menu bar is not currently attached to a dialog. Then a
+ connection request is made by using the last arguments to the method,
+ 'connect' and possiblly 'methodName.' If the menu bar is already attached
+ to a dialog, then those last two arguments connect the item immediatley.
+ </para></listitem>
+ </varlistentry>
+</variablelist>
+
+</section>
+
+</section>
+
+<section id="app01-bams"><title>Menus and Pushbuttons Method Connection</title>
+<para>
+ This note deals with connection of Command Events from menu items and pushbuttons
+ to ooRexx methods.
+</para>
+
+<section id="app01-bams-btns"><title>Buttons</title> <!-- 1 -->
+
+<section id="app01-bams-btns-auto"><title>Auto-connection</title><!-- 1.1 -->
+<para>
+For a UserDialog, the createPushButton() method takes an argument that specifies
+the method to connect for the click event. For an RcDialog, the new method allows
+you to automatically connect the buttons:
+ <programlisting>
+ <![CDATA[
+ >>--init(--script--,--id--+------------+--+---------+--+--------+--+------------+--)--><
+ +-,-dlgData.-+ +-,-hFile-+ +-,-opts-+ +-,-expected-+
+ ]]>
+ </programlisting>
+Section 6.2.1 of the doc is correct for the opts argument; use the CONNECTBUTTONS,
+CONNECTRADIOS, or CONNECTCHECKS keyword(s).
+</para>
+</section>
+<section id="app01-bams-btns-expl"><title>Explicit Connection</title><!-- 1.2 -->
+<para>
+ Use the method connectButtonEvent()
+</para>
+</section>
+</section>
+<section id="app01-bam-menus"><title>Menu Items</title><!-- 2 -->
+<para>
+ When a user clicks on a menu item (that is not a separator or a sub-menu), then a menu command event is raised. [See
+ section 25.2 of the ooDialog Reference]
+ With menu objects there are 2 basic ways to connect the menu command events to
+ a method in the Rexx dialog. Either the command events can be connected automatically
+ by the ooDialog framework. Or the command events can be connected explicitly by the
+ programmer.
+</para>
+<section id="app01-bam-menus-auto"><title>Auto-connection</title><!-- 2.1 -->
+<para>For the BinaryMenuBar, ScriptMenuBar, and UserMenuBar, the new() method has an optional
+ argument towards the end of the argument list for automatically connecting the
+ menu items. When set to .true, all the menu command items are automatically connected
+ when the menu bar is attached to a dialog. The programmer provides methods whose names
+ are the same as the captions (or visible text) of the menu items (excluding blanks
+ and any trailing dots). Thus for a menu item that has the caption Do this the programmer would provide a method with
+ the name dothis.
+</para>
+</section>
+<section id="app01-bam-explicit"><title>Explicit connection</title><!-- 2.2 -->
+<para>
+ Use the connectCommandEvent method of the Menu class (you can invoke it on the
+ MenuBar class if you wish). See section 25.3.48 of the ooDialog Reference.
+</para>
+</section>
+</section>
+
+<section id="app01-bam-notes"><title>Notes</title><!-- 3 Notes -->
+<para>
+ 1. Do not use both auto and explicit for same menu command item.
+ 2. The connectMenuEvent method is actually for connecting menu events, not menu
+command events. E.g there is a menu event notification when the OS is about to
+display a menu. A menu command event is sent when a user clicks on a menu item.
+</para>
+</section>
+</section>
+
+</appendix>
Property changes on: docs/trunk/oodguide/appendix01.xml
___________________________________________________________________
Added: svn:eol-style
+ native
Modified: docs/trunk/oodguide/oodguide.xml
===================================================================
--- docs/trunk/oodguide/oodguide.xml 2011-05-26 19:34:02 UTC (rev 6969)
+++ docs/trunk/oodguide/oodguide.xml 2011-05-27 00:26:24 UTC (rev 6970)
@@ -6,6 +6,7 @@
<!ENTITY chapter2 SYSTEM "chapter02.xml">
<!ENTITY chapter3 SYSTEM "chapter03.xml">
<!ENTITY chapter4 SYSTEM "Chapter04.xml">
+<!ENTITY appendix01 SYSTEM "appendix01.xml">
<!ENTITY notices SYSTEM "../shared/notices.xml">
<!ENTITY cpl SYSTEM "../shared/CPLv1.0.xml">
<!ENTITY gethelp SYSTEM "../shared/gethelp.xml">
@@ -68,6 +69,7 @@
&chapter3; <!-- Third chapter -->
&chapter4; <!-- Fourth chapter -->
<!-- start of appendix -->
+&appendix01; <!-- First appendix -->
&notices; <!-- Notices -->
&cpl; <!-- CPL -->
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 6967
http://oorexx.svn.sourceforge.net/oorexx/?rev=6967&view=rev
Author: miesfeld
Date: 2011-05-13 20:31:43 +0000 (Fri, 13 May 2011)
Log Message:
-----------
Continue ooDialog doc revision
Modified Paths:
--------------
docs/trunk/oodialog/dialogObject.xml
docs/trunk/oodialog/eventNotification.xml
docs/trunk/oodialog/propertySheetDialogs.xml
Modified: docs/trunk/oodialog/dialogObject.xml
===================================================================
--- docs/trunk/oodialog/dialogObject.xml 2011-05-09 16:19:53 UTC (rev 6966)
+++ docs/trunk/oodialog/dialogObject.xml 2011-05-13 20:31:43 UTC (rev 6967)
@@ -284,6 +284,10 @@
<entry>Converts client-area coordinates of the dialog to its screen coordinates.</entry>
</row>
<row>
+<entry><link linkend="mthConnectActivate">connectActivate</link></entry>
+<entry>Connects the window activation event to a method in the Rexx dialog.</entry>
+</row>
+<row>
<entry><link linkend="mthConnectAllSBEvents">connectAllSBEvents</link></entry>
<entry>Connects all event notifications from a scroll bar control to a single method in the Rexx dialog.</entry>
</row>
Modified: docs/trunk/oodialog/eventNotification.xml
===================================================================
--- docs/trunk/oodialog/eventNotification.xml 2011-05-09 16:19:53 UTC (rev 6966)
+++ docs/trunk/oodialog/eventNotification.xml 2011-05-13 20:31:43 UTC (rev 6967)
@@ -59,8 +59,8 @@
<indexterm><primary>EventNotification</primary><secondary>connectHelp</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectHelp(--methodname--)-----------------------><
-
+>>--connectHelp(--+--------------+--)------------><
+ +--methodName--+
]]>
</programlisting>
@@ -75,10 +75,11 @@
<para>
The only argument is:
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
- The name of the method that to be invoked when the help event occurs. The name can not be the empty string.
+ The name of the method that to be invoked when the help event occurs. The name can not be the empty string. When
+ this argument is omitted the name defaults to <emphasis role="italic">onHelp</emphasis>.
</para>
</listitem></varlistentry>
</variablelist>
@@ -211,8 +212,8 @@
<indexterm><primary>EventNotification</primary><secondary>connectResize</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectResize(--methodName--)------------------------------><
-
+>>--connectResize(--+--------------+--)----------><
+ +--methodName--+
]]>
</programlisting>
@@ -226,11 +227,12 @@
<para>
The only argument is:
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
The name of the method that is invoked each time the size of the dialog has changed. The method name can not be the
- empty string and must be less than 256 characters in length.
+ empty string and must be less than 256 characters in length. When this argument is omitted the name defaults to
+ <emphasis role="italic">onResize</emphasis>.
</para>
</listitem></varlistentry>
</variablelist>
@@ -348,8 +350,8 @@
<indexterm><primary>EventNotification</primary><secondary>connectResizing</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectResizing(--methodName--)--------------><
-
+>>--connectResizing(--+--------------+--)--------><
+ +--methodName--+
]]>
</programlisting>
@@ -364,11 +366,12 @@
<para>
The only argument is:
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
The name of the method that is invoked each time the size of the dialog is about to be changed. The method name
- can not be the empty string.
+ can not be the empty string. When this argument is omitted the name defaults to <emphasis
+ role="italic">onResizing</emphasis>.
</para>
</listitem></varlistentry>
</variablelist>
@@ -580,14 +583,241 @@
</section>
+<section id="mthConnectActivate"><title>connectActivate</title>
+<indexterm><primary>connectActivate</primary></indexterm>
+<indexterm><primary>dialog object</primary><secondary>connectActivate</secondary></indexterm>
+<indexterm><primary>EventNotification</primary><secondary>connectActivate</secondary></indexterm>
+<programlisting>
+<![CDATA[
+>>--connectActivate(--+--------------+--)--------><
+ +--methodName--+
+]]>
+</programlisting>
+
+<para>
+ Connects an <emphasis role="italic">activate</emphasis> <link linkend="ovvEvents">event</link> notification sent to
+ the underlying dialog with a method in the Rexx dialog. This event notification is sent to both the window being
+ activated and the window being deactivated
+</para>
+<variablelist>
+ <varlistentry><term><emphasis role="bold">Arguments:</emphasis></term>
+ <listitem>
+ <para>
+ The only argument is:
+ <variablelist>
+ <varlistentry><term>methodName [optional]</term>
+ <listitem>
+ <para>
+ The name of the method that is invoked each time the size of the dialog is about to be changed. The method name
+ can not be the empty string. When this argument is omitted the name defaults to <emphasis
+ role="italic">onActivate</emphasis>.
+ </para>
+ </listitem></varlistentry>
+ </variablelist>
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term><emphasis role="bold">Return value:</emphasis></term>
+ <listitem>
+ <variablelist>
+ <varlistentry><term>0</term>
+ <listitem>
+ <para>
+ No error.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term>1</term>
+ <listitem>
+ <para>
+ An (internal) error prevented the message from being connected to a method.
+ </para>
+ </listitem></varlistentry>
+ </variablelist>
+ </listitem></varlistentry>
+ <varlistentry><term><emphasis role="bold">Remarks:</emphasis></term>
+ <listitem>
+ <para>
+ The <emphasis role="italic">active</emphasis> window is the <emphasis role="italic">top-level</emphasis> window that
+ the user is currently working with. The activate notification is only sent to top-level windows. The activate
+ notification is always sent in pairs, one notification to the window losing the activation and one to the window
+ gaining the activation. The arguments to the event handler for the notification allow the programmer to determine if
+ the window is gaining or losing the acivation.
+ </para>
+ <para>
+ Common guidelines on <link linkend="paraWhereToConnectEvents">where</link> to invoke the <emphasis
+ role="italic">connectActivate</emphasis> method and on <link linkend="sctCodingEventHandlers">how</link>
+ to code event handlers are included in the documentation for the <link
+ linkend="clsEventNotification">EventNotification</link> class.
+ </para>
+ <para>
+ The interpreter invokes the event handler directly and waits in the window <link
+ linkend="ovvWindowMessages">message</link> processing loop for the return from the event handler. Connecting the
+ activate event requires that the programmer reply to the event from the event handler in a timely manner.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term><emphasis role="bold">Details:</emphasis></term>
+ <listitem>
+ <para>
+ This method is a member of the <link linkend="clsEventNotification">EventNotification</link> mixin class.
+ </para>
+ <para>
+ Syntax errors are raised when incorrect usage is detected.
+ </para>
+ <para>
+ If the programmer does not provide a matching method in the Rexx dialog, a syntax condition will be raised if any
+ sizing events happen.
+ </para>
+ <para>
+ The underlying dialog receives the WM_ACTIVATE message as the notification for this event.
+ </para>
+ </listitem></varlistentry>
+</variablelist>
+
+<section id="evtACTIVATE"><title>Activate Event Handler</title>
+<indexterm><primary>dialog object</primary><secondary>events</secondary><tertiary>ACTIVATE</tertiary></indexterm>
+
+<programlisting>
+<![CDATA[
+::method onActivate unguarded
+ use arg status, hwnd, hFocus, isMinimized
+
+ return .false
+]]>
+</programlisting>
+
+<para>
+ The event handler for the ACTIVATE event is invoked when the dialog window is either losing or gaining the active
+ window status.
+</para>
+<para>
+ The programmer must return a value from the event handler and the interpreter waits for the return value from the
+ event handler.
+</para>
+<variablelist>
+ <varlistentry><term><emphasis role="bold">Arguments:</emphasis></term>
+ <listitem>
+ <para>
+ The event handling method recieves four arguments:
+ </para>
+ <variablelist>
+ <varlistentry><term>status</term>
+ <listitem>
+ <para>
+ A keyword that indicates if the dialog is gaining or losing the activation. The keyword will be exactly one of the
+ following:
+ </para>
+ <para>
+ <simplelist type='vert' columns='3'>
+ <member>ACTIVE</member> <member>CLICKACTIVE</member> <member>INACTIVE</member>
+ </simplelist>
+ </para>
+ <variablelist>
+ <varlistentry><term></term>
+ <listitem>
+ <para>
+ The dialog is gaining the activation through some means other than the user clicking the mouse on the window.
+ For example the user may select the window through the ALT-Tab mechanism.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term>CLICKACTIVE</term>
+ <listitem>
+ <para>
+ The dialog is gaining the activation through a mouse click.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term>INACTIVE</term>
+ <listitem>
+ <para>
+ The dialog is losing the activation.
+ </para>
+ </listitem></varlistentry>
+ </variablelist>
+ </listitem></varlistentry>
+ <varlistentry><term>hwnd</term>
+ <listitem>
+ <para>
+ The window <link linkend="defHandle">handle</link> of the window being activated or deactivated, depending on the
+ <emphasis role="italic">status</emphasis> argument. If the keyword is INACTIVE, then this is the handle of the
+ window gaining the activation. If the keyword is ACTIVE or CLICKACTIVE, it is the handle of the window losing the
+ activation.
+ </para>
+ <para>
+ <emphasis role="bold">Note</emphasis> that this argument may be 0, indicating the operating system did not pass a
+ window handle with the notification.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term>hFocus</term>
+ <listitem>
+ <para>
+ The window handle of the dialog control with the current focus when the dialog is being deactivated. When the
+ dialog is being activated <emphasis role="italic">hFocus</emphasis> will be 0.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term>isMinimized</term>
+ <listitem>
+ <para>
+ Specifies the minimized state of the window being activated or deactivated. <emphasis
+ role="italic">isMinimized</emphasis> will be <computeroutput>.true</computeroutput> if the window is minimized,
+ otherwise <computeroutput>.false</computeroutput>.
+ </para>
+ </listitem></varlistentry>
+ </variablelist>
+ </listitem></varlistentry>
+ <varlistentry><term><emphasis role="bold">Return:</emphasis></term>
+ <listitem>
+ <para>
+ The event handler for this notification must return <computeroutput>.true</computeroutput> or
+ <computeroutput>.false</computeroutput>. A return of true indicates that the notification has been processed and a
+ return of false indicates that the notification has not been processed. When the notification has not been processed
+ the interpreter passes the notification on to the operating system for its default processing.
+ </para>
+ <para>
+ The default processing done by the operating system includes things like restoring the focus to the dialog control
+ that had the focus when the dialog was deactivated, highlighting the text in an edit control if that control has the
+ focus, etc.. Under most circumstances, the programmer should return <computeroutput>.false</computeroutput> to allow
+ the dialog manager to perform this default processing. If not, the programmer should take care of these details or
+ the dialog may not behave as the user expects.
+ </para>
+ </listitem></varlistentry>
+ <varlistentry><term><emphasis role="bold">Example</emphasis></term>
+ <listitem>
+ <para>
+ The following example comes from code ooDialog uses internally to handle a problem with a <link
+ linkend="clsListView">ListView</link> control when it is used in a <link linkend="clsTab">Tab</link> control. When
+ the dialog is being inactivated the handle of the focused control is saved. When it is being activated, the handle
+ of the last focused control is passed on the to <link linkend="clsControlDialog">ControlDialog</link> that contains
+ the list-view for processing.
+
+<programlisting>
+<![CDATA[
+
+::method onActivate
+ expose listViewPageDialog lastFocused
+ use arg flag, hwnd, hFocused, isMinimized
+
+ reply .false
+
+ if flag == 'INACTIVE' then lastFocused = hFocused
+ else listViewPageDialog~updateListView(lastFocused)
+
+]]>
+</programlisting>
+ </para>
+ </listitem></varlistentry>
+</variablelist>
+
+</section> <!-- End Activate Event Handler -->
+
+</section>
+
+
<section id="mthConnectSizeMoveEnded"><title>connectSizeMoveEnded</title>
<indexterm><primary>connectSizeMoveEnded</primary></indexterm>
<indexterm><primary>dialog object</primary><secondary>connectSizeMoveEnded</secondary></indexterm>
<indexterm><primary>EventNotification</primary><secondary>connectSizeMoveEnded</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectSizeMoveEnded(--methodName--+--------------+--)-----><
- +-,-willReply--+
+>>--connectSizeMoveEnded(--+--------------+--+--------------+--)---------------><
+ +--methodName--+ +-,-willReply--+
]]>
</programlisting>
@@ -603,11 +833,12 @@
<para>
The arguments are
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
The name of the event handling method that to be invoked when the the size / move exit event occurs. The name must
- not be the empty string and must be less than 256 characters in length.
+ not be the empty string and must be less than 256 characters in length. When this argument is omitted the name
+ defaults to <emphasis role="italic">onSizeMoveEnded</emphasis>.
</para>
</listitem></varlistentry>
<varlistentry><term>willReply [optional]</term>
@@ -727,8 +958,8 @@
<indexterm><primary>EventNotification</primary><secondary>connectMove</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectMove(--methodName--)--------------------------------><
-
+>>--connectMove(--+--------------+--)------------><
+ +--methodName--+
]]>
</programlisting>
@@ -742,11 +973,12 @@
<para>
The only argument is:
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
The name of the method that will be invoked each time the dialog has moved. The name can not be the empty string
- and it must be less than 256 characters in length.
+ and it must be less than 256 characters in length. When this argument is omitted the name defaults to <emphasis
+ role="italic">onMove</emphasis>.
</para>
</listitem></varlistentry>
</variablelist>
@@ -818,15 +1050,15 @@
<indexterm><primary>EventNotification</primary><secondary>connectPosChanged</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectPosChanged(--methodName--)--------------------------><
-
+>>--connectPosChanged(--+--------------+--)------><
+ +--methodName--+
]]>
</programlisting>
<para>
The <emphasis role="italic">connectPosChanged</emphasis> method connects the position changed event notification sent
to a dialog to a method in the Rexx dialog object. This notification is sent to the dialog when its size, position, or
- place in the Z order has changed .
+ place in the Z order has changed.
</para>
<variablelist>
<varlistentry><term><emphasis role="bold">Arguments:</emphasis></term>
@@ -834,11 +1066,12 @@
<para>
The only argument is:
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
The name of the method that will be invoked each time the dialog has moved. The name can not be the empty string
- and it must be less than 256 characters in length.
+ and it must be less than 256 characters in length. When this argument is omitted the name defaults to <emphasis
+ role="italic">onPosChanged</emphasis>.
</para>
</listitem></varlistentry>
</variablelist>
@@ -910,7 +1143,7 @@
<indexterm><primary>EventNotification</primary><secondary>connectDraw</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectDraw--(--+-----+--+---------------+--)--------------><
+>>--connectDraw--(--+-----+--+---------------+--)---------------><
+--id-+ +-,--methodName-+
]]>
@@ -998,8 +1231,8 @@
<indexterm><primary>EventNotification</primary><secondary>connectMouseCapture</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectMouseCapture(--methodName--)------------------------><
-
+>>--connectMouseCapture(--+--------------+--)----><
+ +--methodName--+
]]>
</programlisting>
@@ -1015,11 +1248,12 @@
<para>
The single argument is:
<variablelist>
- <varlistentry><term>methodName [required]</term>
+ <varlistentry><term>methodName [optional]</term>
<listitem>
<para>
The nane of the method that will be invoked upon receiving this event notification. The name can not be the empty
- string and must be less than 256 characters in length.
+ string and must be less than 256 characters in length. When this argument is omitted the name defaults to <emphasis
+ role="italic">onMouseCapture</emphasis>.
</para>
</listitem></varlistentry>
</variablelist>
@@ -1068,7 +1302,7 @@
<indexterm><primary>EventNotification</primary><secondary>connectKeyPress</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectKeyPress(--methodName--,--keys-+------------+--)----><
+>>--connectKeyPress(--methodName--,--keys-+------------+--)-----><
+-,--filter--+
]]>
@@ -1487,7 +1721,7 @@
<indexterm><primary>EventNotification</primary><secondary>connectFKeyPress</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectFKeyPress(--methodName--)---------------------------><
+>>--connectFKeyPress(--methodName--)-------------><
]]>
</programlisting>
@@ -1818,7 +2052,7 @@
<indexterm><primary>EventNotification</primary><secondary>hasKeyPressConnection</secondary></indexterm>
<programlisting>
<![CDATA[
->>--hasKeyPressConnection(--+--------------+--)----------------><
+>>--hasKeyPressConnection(--+--------------+--)--><
+--methodName--+
]]>
@@ -1908,7 +2142,7 @@
<programlisting>
<![CDATA[
->>--connectCommandEvents(--id--,--methodName--)----------------><
+>>--connectCommandEvents(--id--,--methodName--)--><
]]>
</programlisting>
@@ -2043,7 +2277,7 @@
<indexterm><primary>EventNotification</primary><secondary>connectNotifyEvent</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectNotifyEvent(--id--,--event--+---------------+--)--------------------><
+>>--connectNotifyEvent(--id--,--event--+---------------+--)-----><
+-,--methodName-+
]]>
@@ -2166,7 +2400,7 @@
<indexterm><primary>dialog object</primary><secondary>connectStaticEvent</secondary></indexterm>
<programlisting>
<![CDATA[
->>--connectStaticNotify(--id--,--event--,-+---------------+--)-----------------><
+>>--connectStaticNotify(--id--,--event--,-+---------------+--)--><
+-,--methodName-+
]]>
@@ -2331,7 +2565,7 @@
<indexterm><primary>connectButtonEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectButtonEvent(--id--,--event--+----------------+--)-------------------><
+>>--connectButtonEvent(--id--,--event--+----------------+--)----><
+-,--methodName--+
]]>
@@ -2557,7 +2791,7 @@
<indexterm><primary>connectEditEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectEditEvent(--id--,--event--+---------------+--)----------------------><
+>>--connectEditEvent(--id--,--event--+---------------+--)-------><
+-,--methodName-+
]]>
</programlisting>
@@ -2692,7 +2926,7 @@
<indexterm><primary>connectListBoxEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectListBoxEvent(--id--,--event--+---------------+--)-------------------><
+>>--connectListBoxEvent(--id--,--event--+---------------+--)----><
+-,--methodName-+
]]>
@@ -2795,7 +3029,7 @@
<indexterm><primary>connectComboBoxEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectComboBoxEvent(--id--,--event--+---------------+--)------------------><
+>>--connectComboBoxEvent(--id--,--event--+---------------+--)---><
+-,--methodName-+
]]>
@@ -2927,7 +3161,7 @@
<indexterm><primary>connectScrollBarEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectScrollBarEvent(--id--,--event--+---------------+--)-----------------><
+>>--connectScrollBarEvent(--id--,--event--+---------------+--)--><
+-,--methodName=+
]]>
@@ -3131,12 +3365,14 @@
<indexterm><primary>connectEachSBEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectEachSBEvent(-id-,-mthWhenUp-,-mthWhenDown-+---------------+-+-------+-+-------+-+-------+-->
- +-,-mthWhenDrag-+ +-,-min-+ +-,-max-+ +-,-pos-+
+>>--connectEachSBEvent(-id-,-mthWhenUp-,-mthWhenDown-+---------------+--------->
+ +-,-mthWhenDrag-+
->--+-----------+-+-----------+-+----------+-+--------------+-+-------------+-+-------------+-)--------><
- +-,-mthPgUp-+ +-,-mthPgDn-+ +-,-mthTop-+ +-,-progbuttom-+ +-,-progtrack-+ +-,-progendsc-+
+>--+-------+-+-------+-+-------+--+-----------+-+-----------+-+----------+----->
+ +-,-min-+-+-,-max-+ +-,-pos-+ +-,-mthPgUp-+ +-,-mthPgDn-+ +-,-mthTop-+
+>--+--------------+-+-------------+-+-------------+-)--------------------------><
+ +-,-progbuttom-+ +-,-progtrack-+ +-,-progendsc-+
]]>
@@ -3295,7 +3531,7 @@
<indexterm><primary>connectListViewEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>-connectListViewEvent(--id--,--event--+---------------+--)-------------------><
+>>-connectListViewEvent(--id--,--event--+---------------+--)----><
+-,--methodName-+
]]>
@@ -3874,7 +4110,7 @@
<indexterm><primary>connectTreeViewEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>-connectTreeViewEvent(--id--,--event--+----------------+--)------------------><
+>>-connectTreeViewEvent(--id--,--event--+----------------+--)---><
+-,--methodName--+
]]>
@@ -4232,7 +4468,7 @@
<indexterm><primary>connectTrackBarEvent</primary></indexterm>
<programlisting>
<![CDATA[
->>--connectTrackBarEvent(--id--,--event--+---------------+--)------------------><
+>>--connectTrackBarEvent(--id--,--event--+---------------+--)---><
+-,--methodName-+
]]>
@@ -5346,7 +5582,7 @@
<indexterm><primary>defListDragHandler</primary></indexterm>
<programlisting>
<![CDATA[
->>-defListDragHandler(--id--,--item--,--point--)---------------><
+>>-defListDragHandler(--id--,--item--,--point--)----------------><
]]>
</programlisting>
@@ -5394,7 +5630,7 @@
<indexterm><primary>defTreeDragHandler</primary></indexterm>
<programlisting>
<![CDATA[
->>-defTreeDragHandler(--id--,--item--,--point--)---------------><
+>>-defTreeDragHandler(--id--,--item--,--point--)----------------><
]]>
</programlisting>
Modified: docs/trunk/oodialog/propertySheetDialogs.xml
===================================================================
--- docs/trunk/oodialog/propertySheetDialogs.xml 2011-05-09 16:19:53 UTC (rev 6966)
+++ docs/trunk/oodialog/propertySheetDialogs.xml 2011-05-13 20:31:43 UTC (rev 6967)
@@ -2,7 +2,7 @@
#
# Description: Open Object Rexx: ooDialog Reference XML file.
#
- # Copyright (c) 2010-2010, Rexx Language Association. All rights reserved.
+ # Copyright (c) 2010-2011, Rexx Language Association. All rights reserved.
#
# This program and the accompanying materials are made available under
# the terms of the Common Public License v1.0 which accompanies this
@@ -405,7 +405,8 @@
<section id="sctControlDialogs"><title>Control Dialogs</title>
<indexterm><primary>Control Dialogs</primary></indexterm>
<para>
- xxx
+ Windows supports a style for dialogs that allow the dialog to work well as a dialog within a top-level dialog. In
+ essence a dialog with this style functions as a dialog control within the top-level dialog.
</para>
<section id="clsControlDialog"><title>ControlDialog Class</title>
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 6960
http://oorexx.svn.sourceforge.net/oorexx/?rev=6960&view=rev
Author: miesfeld
Date: 2011-05-03 03:35:29 +0000 (Tue, 03 May 2011)
Log Message:
-----------
ooDialog 4.2.0 sandbox version - update release notes
Modified Paths:
--------------
sandbox/mark/ooDialog.beta/platform/windows/install/ReleaseNotes_ooDialog.4.2.0.txt
sandbox/mark/ooDialog.beta/platform/windows/install/ooDialog.4.2.0.ReadMe.txt
Modified: sandbox/mark/ooDialog.beta/platform/windows/install/ReleaseNotes_ooDialog.4.2.0.txt
===================================================================
--- sandbox/mark/ooDialog.beta/platform/windows/install/ReleaseNotes_ooDialog.4.2.0.txt 2011-05-03 03:07:20 UTC (rev 6959)
+++ sandbox/mark/ooDialog.beta/platform/windows/install/ReleaseNotes_ooDialog.4.2.0.txt 2011-05-03 03:35:29 UTC (rev 6960)
@@ -1,12 +1,12 @@
Note
====
-Go to "Release Notes ooDialog 4.2.0" in the middle of this document. That
-section is the start of the real release notes for 4.2.0. Just a stub for
-now, but starting to get filled in.
+Go to "Release Notes ooDialog 4.2.0" towards the bottom of this document.
+That section is the start of the real release notes for 4.2.0. Just a stub
+for now, but starting to get filled in.
- switch_ooDialog420_410-4.2.0.6xxx
+ switch_ooDialog420_410-4.2.0.6887
=================================
Changes since switch_ooDialog420_410-4.2.0.6800
@@ -19,12 +19,38 @@
A ooDialog User Dialog book has been started and added to the
distribution.
+Samples added:
+--------------
+ The useTools.rex example program showing how to create and use 'owned'
+ dialogs was added.
+ The simpleMenuBar.rex example program showing how to use menu bars in a
+ dialog was added.
+ Exercises to accompany the new ooDialog User Guide were added to the
+ sample programs under the oodialog\userGuide directory
+Enhancements:
+-------------
+ Constants for the scroll bar events were added to the ScrollBar class.
+ The connectResizing() method was added to the EventNotification class.
+ Implementation to create 'owned' dialogs was added. The ownerDialog
+ attribute was added to the dialog object.
+ The tables used by ooDialog (color table, message table, bitmap table,
+ etc.,) were all made dynamic in size. There is no longer any limit to the
+ number of controls that can be assigned a color, or the number of events
+ that can be connected to a method in the Rexx dialog, etc..
+
+Bugs:
+----
+ Several bugs found internally were fixed.
+
+
+
+
switch_ooDialog420_410-4.2.0.6800
=================================
Modified: sandbox/mark/ooDialog.beta/platform/windows/install/ooDialog.4.2.0.ReadMe.txt
===================================================================
--- sandbox/mark/ooDialog.beta/platform/windows/install/ooDialog.4.2.0.ReadMe.txt 2011-05-03 03:07:20 UTC (rev 6959)
+++ sandbox/mark/ooDialog.beta/platform/windows/install/ooDialog.4.2.0.ReadMe.txt 2011-05-03 03:35:29 UTC (rev 6960)
@@ -1,5 +1,5 @@
- ooDialog 4.2.0 Beta March 2011
+ ooDialog 4.2.0 Beta April 2011
=================================
ooDialog 4.2.0 is the next major release of ooDialog. This release will
This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.