[Oorexx-devel] [Fwd: Re: ooRexx Logo]
Hi there, Gray Wilson has come up with a set of new ooRexx logos on the oorexx-users list, which he offers for free use to the Rexx community (cf. enclosed e-mails)! Enclosed please find his announcement e-mail and a link to an impressive set of renderings of mime-type icons following the target platform designs. He certainly has invested a lot of time and seems to be a very talented person in that way too! [Personally, I will take advantage of the BSF4Rexx and OpenOffice.org-Rexx logos for the upcoming version of BSF4Rexx 4.0.] Whether the community and/or RexxLA would take on these new logos in lieu of the existing ones will probably need some discussions in the respective groups. As Gray continues to add new platforms for the ooRexx logos, you may want to check out the website he points to in his e-mail. Also, if you want to give him feedback, you may want to use the user mailing list on Sourceforge: http://sourceforge.net/mailarchive/forum.php?forum_name=oorexx-users. ---rony Original Message Subject: Re: ooRexx Logo Date: Mon, 14 Sep 2009 03:19:04 +0100 From: Gray Wilson gdwz-z02xgkufpwys+fvcfc7...@public.gmane.org Reply-To: Open Object Rexx Users oorexx-users-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org To: Open Object Rexx Users oorexx-users-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org Newsgroups: gmane.comp.lang.rexx.oorexx.user Thanks, Rony and Peter for your encouragement. I've updated the set with another XP style filetype icon, giving a total of 72 pngs. http://graywz.deviantart.com/art/Open-Object-Rexx-Icons-136889466 I will work on an OSX style icon and upload it later this week. Thanks again Gray Original Message Subject: Re: ooRexx Logo Date: Sun, 13 Sep 2009 16:59:33 +0100 From: Gray Wilson gdwz-z02xgkufpwys+fvcfc7...@public.gmane.org Reply-To: Open Object Rexx Users oorexx-users-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org To: Open Object Rexx Users oorexx-users-5nwgofrqmnerv+lv9mx5uipxlwaov...@public.gmane.org Newsgroups: gmane.comp.lang.rexx.oorexx.user Hi Rony (and everyone) I've uploaded a complete ooRexx application-and-filetype set of icons for Linux and Windows. http://graywz.deviantart.com/art/Open-Object-Rexx-Icons-136889466 I took the liberty of using a code stub (written by you in Resurrecting REXX, Introducing Object Rexx) in some of the icons. I hope you don't mind. The images are in ICO and PNG formats, and I've included the full Photoshop PSD source files for freedom and flexibility. But please let me know if you'd like me to change or add anything. Best wishes Gray Wilson -- 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
[Oorexx-devel] Some theory / philosophy on refactoring (existing public) classes
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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
Re: [Oorexx-devel] Some theory / philosophy on refactoring (existing public) classes
Mark, this sounds good to me too. I think Ideally the ooDialog user should just be able to requires one class and everything should be there for them. You might want to make them choose one class for use with a resource file and another for use with the dynamic methods, but I don't even know if that is necesary from an ooDialog user's standpoint. The distinction between the old controls and the 'new' 32 bit controls was history before I ever met ooDialog. Jon 2009/9/14 Rick McGuire object.r...@gmail.com 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 miesf...@gmail.com 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 Oorexx-devel@lists.sourceforge.net 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 Oorexx-devel@lists.sourceforge.net 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
