On Mon, Sep 14, 2009 at 10:20 AM, Sahananda (Jon) Wolfers
<sahana...@windhorse.biz> wrote:

> I think Ideally the ooDialog user should just be able to requires one class
> ...
> The distinction between the old controls and the 'new' 32 bit controls was
> history before I ever met ooDialog.

The distinction between the old controls and the 'new' controls has
been an artificial one for a long time.

By putting some control methods in a separate AdvancedControls, the
user is currently forced to inherit that class in their subclasses.
All of the methods in the AvancedControl class really belonged in
already existing classes.  There are / were 3 basic types of methods
in AdvancedControls

1.) Methods to place a control in the in-memory dialog template.
These belonged in the existing DynamicDialog class that already had
the methods for working with the in-memory dialog template.  We
already discussed this and those methods were moved to DynamicDialog

2.) Methods to create an attribute in the dialog object to represent a
control and connect the control with the attribute.  Methods to do
that for check boxes, radio buttons, edit controls, list boxes, combo
boxes, and more, already existed in PlainBaseDialog.  So the methods
to do the same thing for the 4 'new' controls, List-view, tree-view,
track bar, and tab should have been placed alongside the existing
methods.  I have already moved those 4 methods to PlainBaseDialog.

3.) Methods to get a new control object.  Those methods, I think,
really should have just been placed in BaseDialog.  All non-trivial
dialogs are subclasses of BaseDialog.  If these methods were moved to
BaseDialog, then users would not need to inherit AdvancedControls.
They would just subclass the type of dialog they were creating and all
controls would work.  AdvancedControls would be left as a deprecated,
empty class.  All existing dialogs that inherit AdvancedControls would
just work the same, so there are no backwards compatibility issues.

That last third step is what I intend to do.  I'm going to open up a
RFE to track it, but wanted to throw the idea out here first.

--
Mark Miesfeld

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Reply via email to