On Sun, Aug 7, 2011 at 9:04 AM, Oliver Sims <oliver.s...@simsassociates.co.uk> wrote:
> I display a bitmap image in an "about" dialog, and use the following code to > do so: > > resImage = .ResourceImage~new( "", self) -- Create an > instance of a resource image > image = resImage~getImage(IDB_PROD_ICON) -- Create an image from the > Product bitmap > stImage = self~newStatic(IDC_PRODABT_ICON_PLACE)~setImage(image) -- > Create a static text and set the image in it > > Having read the ooDialog Reference, I understand what's happening in this > code - it's: > (1) Create a ResourceImage instance > (2) invoke getImage on the ResourceImage instance in order to get an Image > instance > (3) Set the Image instance into the image-static (or "picture") control. > > It's done this way (as I understand) because setImage on the Static control > needs an instance of .Image, but the only way I can get my image out of the > resource file (the *.dll) is to use an instance of .ResImage. > > I guess my question is, is there a simpler way to do this? It seems a bit of > a long way round... Well, I don't know. It seems a sort of philosophical question. There is not a simpler way in ooDialog for the Rexx programmer to do it, at this time. If that is the question. You are doing it the same way I would do it. If you are asking could the implementation be changed so that it *was* simpler for the Rexx programmer, then I would say "at what cost?' The implementation could be changed so that the only code you would need is: stImage = self~newStatic(IDC_PRODABT_ICON_PLACE)~setImage(IDB_PROD_ICON) *if* self was restricted to a ResDialog only. Makes sense to me, I think that all users should *only* use .ResDialog dialogs to begin with. You could add a bunch of optional arguments to setImage() that would allow the Rexx programmer to code the whole thing in one line: stImage = self~newStatic(IDC_PRODABT_ICON_PLACE)~setImage(id, fileName, image, resourceImage, flags) where file name could be the name of a icon file, or the name of an executable module containing resources, image could be an already instantiated .Image object, resourceImage could be an already instantiated .ResourceImage. Some arguments would be optional, the flags would control how things worked. There is a philosophy that each method should do one thing only and do it extremely well. Which I ascribe to. There is another philosophy that the implementation of Rexx should make things as easy as possible for the Rexx programmer, which I also ascribe to. Adding a bunch of optional arguments to make setImage() do a lot of different things violates the first philosophy big time. Some might say that it enforces the second philosophy and that the second philosophy should dominate, because it is more "Rexxish." But, is it really simpler for the Rexx programmer to have a bunch of optional arguments that cause the method to do any number of different things? (I don't think so.) * It is much harder to figure out what arguments are needed to do which thing correctly. * It is harder to use the method when coding because you would need to go to the reference more often. * It makes the implementation code more prone to errors which leads to more bugs. * If the method does not work, it can be extremely hard to figure out why it failed. All, in all, I think the current implementation is the correct way to do things. * It is not restrictive, the image can come from any way that is convenient to the Rexx programmer. * The implementation code for each method is much simpler so it is less error prone, meaning it is less likely that the Rexx programmer will encounter failures due to the underlying implementation. * When the icon does not appear in the dialog, it is much easier for the Rexx programmer to check for errors at each step of the process, making it easier for the programmer to debug his program. * Each of the objects used in the process are very flexible and have many other uses than simply getting an icon image. -- Mark Miesfeld ------------------------------------------------------------------------------ BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA The must-attend event for mobile developers. Connect with experts. Get tools for creating Super Apps. See the latest technologies. Sessions, hands-on labs, demos & much more. Register early & save! http://p.sf.net/sfu/rim-blackberry-1 _______________________________________________ Oorexx-users mailing list Oorexx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-users
