This sounds good to me. In general, if a method does not make sense for a give class, then the appropriate error message should be "does not understand". In other words, the class should not have the method in the first place. If I understand your refactoring correctly, that would be the net result, which would be a good thing.
Rick On Mon, Sep 14, 2009 at 12:58 PM, Mark Miesfeld <[email protected]> wrote: > I'm looking for a little help, advice, or maybe even a flat out "you > can't do that" concerning the possibility of refactoring some of the > ooDialog classes. > > Specifically, I would like to move some methods out of the > AdvancedControls mixin class back to the DynamicDialog class. > > The DynamicDialog class has the methods that allow a dialog template > to be built in memory, by the Rexx programmer. It has methods like > addButton(), addListBox() that add dialog controls to the template. > > The AdvancedDialog class has methods that allow the use of, what was > probably at the time "newer" controls, like the Tree-view control. Of > course today these "newer" controls are far from new. But the class > also has several methods, like addTreeControl() that really should > have been in the DynamicDialog classe. Because: > > The DynamicDialog class has all the implementation code for managing > the in memory template, which is needed by addTreeControl(). The > functionality of adding a dialog control to the in memory template is > the functionality of the DynamicDialog class. All dialog classes that > have the ability to use this functionality have inherited the > DynamicDialog class already in the ooDialog framework. > > On the other hand, the AdvancedControls class is not inherited by any > class in the framework, it is up to the user to inherit if from the > user's subclass. Which means the user can inherit the class in > dialogs that do not support the building of the in memory template. > In these cases, if the addXXXControl() methods are invoked they fail > with raised exceptions, because the methods have to invoke > DynamicDialog methods which are not available. The AdvancedControls > class *is* inherited by dialog subclasses that do not support the > building of the in memory template, because the functionality it > provides, that of working with "new" controls, is useful to all > dialogs, whether they are "user defined" dialogs or not. > > If I moved these methods out of the AdvancedControls class into the > DynamicDialog class, where I think they belong, in all programs where > the methods currently work, they would still work. In all programs > where the methods currently don't work, they would still not work. > > Any thoughts on this? > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > trial. Simplify your report design, integration and deployment - and focus on > what you do best, core application coding. Discover what's new with > Crystal Reports now. http://p.sf.net/sfu/bobj-july > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
