Wrt "controls" in the rexx program and the underlying Windows controls, it
occurred to me that
a diagram in the Guide would help. Here's a rough sketch of what I have in
mind:
+----------+ +------------------+ Window on Screen
| ooDialog |<--------->| Windows | ____________
+----------+ +--------------- | /____________\
| | | | |
+----------------+ | | | A |
| +---+ +---+ | +---+ +---+ | |<---->| |
| | A"| | B"| | | A'| | B'| | | | B |
| +---+ +---+ | +---+ +---+ | | | |
| | | | \____________/
| myProg.rex | +--+
+----------------+
A" and B" are the Rexx objects that represent the underlying Windows
controls, A' and B' are those underlying Windows controls, and A and B are
the controls visible on the screen to the user.
Maybe having a specific name for the rexx objects would be useful. In the
Guide, I talk about them as "proxy controls", since they could be said to be
proxies for the "real" underlying Windows controls (and then I drop this
term, having hopefully explained the difference).
Do you think this diagram adds to clarity, or to confusion? Is it correct at
this level of abstraction?
Thx
Oliver
PS: I'm working on another diagram to show the diffs between userDialog,
RcDialog and ResDialog wrt when and what things happen on dialog
creation/setup.
-----Original Message-----
From: Mark Miesfeld [mailto:miesf...@gmail.com]
Sent: 09 August 2011 21:03
To: Open Object Rexx Users
Subject: Re: [Oorexx-users] ooDialog - defineDialog method
On Tue, Aug 9, 2011 at 2:29 PM, Oliver Sims
<oliver.s...@simsassociates.co.uk> wrote:
> Wrt RcDialogs and ResDialogs:
> I've been creating controls - e.g. ecCustNo = self~newEdit(...) - in
> the initDialog method. But I've just re-read various things in the
> ooDialog Reference, and it appears that better practice would be to
> create them in the defineDialog method, since that's what it's there for
(it appears).
>
> Is this a reasonable conclusion?
No. <grin>
defineDialog() is for adding controls to / creating controls in the dialog
template of a UserDialog. With both a RcDialog and a ResDialog, the dialog
template is already defined.
In this line of code:
ecCustNo = self~newEdit(...)
you are not creating the control, you are instantiating a Rexx object that
represents the underlying Windows dialog control. The newEdit() method will
in fact fail if the underlying dialog does not yet exist.
This is the case in defineDialog(), the underlying dialog does not yet
exist.
In defineDialog() the programmer is still in the process of defining the
dialog template. It is impossible at this point for the underlying Windows
dialog to exist. Many, if not the majority of object methods in ooDialog
*require* that the underlying dialog has been created by the operating
system. All of those methods can not be used in defineDialog. All of those
methods can be used in initDialog(), or after initDialog() has been invoked.
This is a point that is often hard for people to understand. I have seen a
lot of people confused by this.
Now with a RcDialog, the defineDialog() method is still invoked. The
programmer could use that to add *additional* controls to the dialog
template by using the UserDialog createXXX methods. (A RcDialog is a
subclass of a UserDialog, so it has all the methods of the
UserDialog.) But these controls would be *added* to the controls that
already exist in the .rc file. If for instance you added a control here
with the same ID as one already in the template (because it was in the .rc
file) things would fail. The OS would refuse to created the underlying
dialog from the template. (Because of the duplicate control IDs.)
With a ResDialog, the defineDialog() method is never even invoked.
The dialog template has already been compiled and can not be changed.
--
Mark Miesfeld
----------------------------------------------------------------------------
--
uberSVN's rich system and user administration capabilities and model
configuration take the hassle out of deploying and managing Subversion and
the tools developers use with it. Learn more about uberSVN and get a free
download at: http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
