Thanks for the comments, Mark. Here's version 2 (I thought I'd leave menus
in but provide an explanation based on your comments in Notes below the
table). Any better?
-- Oliver
----------------------------------------------------------------------------
-----
Usual Dialog Creation Sequences
Method
UserDialog
RcDialog
ResDialog
Comment
Dialog Template already created by the *.rc file
Dialog Template already created in the *.dll file
init
Dialog Template (with no controls) created by the superclass
Create Menubar
.ScriptMenuBar~new
(but see Note 5.)
defineDialog
Create Controls in the Dialog Template with
self~createXxx(.) where Xxx = control type.
Can create more controls and/or menu items if required.
Not invoked.
(Template already defined by *.dll file - cannot change it - so cannot add
controls or menu items.)
Called by init method of UserDialog or RcDialog
~execute
(or ~popup,
~popupAsChild, ~executeAsync)
Underlying dialog created by Windows during the execution of
whichever of these methods is used
initDialog
Controls:
Menubar:
Create "proxy" controls with self~newXxx(.)
where Xxx = control type.
.UserMenuBar~new()
plus create menu items (but see Note 5.)
Create "proxy" controls with self~newXxx(.) where Xxx = control type.
menuBar~attachTo(.)
(but see Note 5.)
Create "proxy" controls with self~newXxx(.)
where Xxx = control type.
.BinaryMenuBar~new
(plus optional create menu items)
Called by super via dlg~execute()
Notes:
1. A Dialog Template is an in-memory construct that defines the size
and position of a given dialog and all of its controls.
2. When the defineDialog method ends, the Dialog Template is finished.
3. A ResDialog does not receive a defineDialog message (the template
was finished when the *.dll file was created).
4. The term "Underlying Dialog" is the Windows dialog instance, created
"under the covers" by Windows from the Dialog Template provided by ooDialog,
that Windows makes visible on the screen.
5. Menus:
a) Menus are completely independent objects. It makes no difference in
the dialog's cycle where they are created. The only restriction is that a
menu bar cannot be attached to a dialog until the underlying dialog has been
created by Windows. Although it is usual to attach the menu bar to the
dialog in the initDialog method, it is not a requirement.
b) The type of menu bar that can be used is not tied to the type of
dialog. That is, a ScriptMenuBar can be used in any type of dialog
(UserDialog, RcDialog, or ResDialog). This is true for all the menu bar
types and dialog types. However, although not a requirement, the usual
approach is to use a ScriptMenuBar with an RcDialog, a BinaryMenuBar with a
ResDialog, and a UserMenuBar with a UserDialog.
----------------------------------------------------------------------------
-----
_____
From: Mark Miesfeld [mailto:miesf...@gmail.com]
Sent: 14 August 2011 15:31
To: Open Object Rexx Users
Subject: Re: [Oorexx-users] ooDialog - Dialog Initialization Sequences
On Sun, Aug 14, 2011 at 8:25 AM, Oliver Sims
<oliver.s...@simsassociates.co.uk> wrote:
Here is a table I drew up to distinguish between the "initialization"
sequences of three types of dialog. Any comments welcome - especially if any
mistakes or omissions seen.
Hi Oliver
The table is mostly correct. A few comments.
Menus are completely independent objects. It makes no difference in the
dialog's cycle where there are created. The only restriction is that a menu
bar can not be attached to a dialog until the underlying dialog has been
created by operating system. Although it makes sense to attach the menu bar
to the dialog in the initDialog() method, it is not a requirement.
In addition, the type of menu bar that can be used is not tied to the type
of dialog. I.e., a ScriptMenuBar can be used in any type of dialog
(UserDialog, RcDialog, ResDialog.) This is true for all the menu bar types
and dialog types. Again, it probably makes sense that a programmer will use
a ScriptMenuBar with a RcDialog and a UserMenuBar with a UserDialog, it is
not a requirement.
It may be misleading to put too much about menu bars in your table.
The underlying Windows dialog is created during the execute() method, not
before it. (Or during one of the related execute methods, popup(),
popupAsChild(), or executeAsync().)
Also, you have "Underlying dialog (Dialog Template) created? Maybe you mean
the underlying dialog is created from the dialog template. ? In both a
RcDialog and a ResDialog, the dialog *template* has been created before the
Rexx program is even started. In a User dialog the dialog template is
created during the create() method of a UserDialog and controls are added to
that template in the defineDialog() method. When the defineDialog() method
ends, the dialog template is finished.
--
Mark Miesfeld
<Old table deleted for size reasons>
----------------------------------------------------------------------------
--
FREE DOWNLOAD - uberSVN with Social Coding for Subversion.
Subversion made easy with a complete admin console. Easy
to use, easy to manage, easy to install, easy to extend.
Get a Free download of the new open ALM Subversion platform now.
http://p.sf.net/sfu/wandisco-dev2dev
_______________________________________________
Oorexx-users mailing list
Oorexx-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-users
------------------------------------------------------------------------------
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
