On Fri, Jul 1, 2011 at 4:40 AM, <os...@simsassociates.co.uk> wrote: > I think I've asked this before, but if so I can't find your response. So > sincere apologies if you've already answered it. > > The context is controls, and doing things to/with them. In the Guide, I'm > trying to explain why some methods are on the control, while some are on the > dialog with the control as a parameter.
Well, I have my own theory as to why this is, but of course it is just speculation. I'll add that speculation down below. However, I'm not sure we really need to explain it too much. You could just say something along the lines of: in many cases there are several ways to accomplish the same thing. The programmer can choose the method that seems most convenient for the given situation. > My current explanation in the Guide > is as follows: > > "Note that in some cases the method invoked is directly on the control > object, and in other cases the method belongs to the dialog object with the > control being specified in a method parameter. The reason for this is that > some methods (such as setText) are applicable to all controls, and so can be > invoked on any control, while others (such as focusControl) have meaning > within the context of the dialog as a whole." > > Now I know this is a simplification, but my question is, is the above text > just plain wrong, or do you think it's close enough? Or do you think > something should be added/changed? I don't think it is just plain wrong. It's probably not plain right either. As I said, you might simply want to point out that there are several ways to do the same thing, programmers should use what seems best suited to their needs. Take setText(). In the Windows API, every *window* has text associated with it. The setText method is a method of the WindowBase mixin class. In ooDialog, every object that is a window inherits WindowBase. So, every dialog object and every dialog control object has a setText method. The real reason for this is that all those objects are windows. Now, there are methods of a dialog object, like insertComboEntry() and getCurrentComboEntry() that have to do with a dialog control. The ComboBox class has the same methods. The reason for this is, my theory for this is, that the original developers used an abstraction that didn't view dialog controls as objects. If you look you see that there are only these types of methods in the dialog object for combo boxes, listboxes, edit controls, buttons, and scroll bars. These dialog controls are the basic controls from Windows 3.1, from 16-bit Windows. There are no such methods for list-views, tree-views, progress bars, tab controls, etc.. All the controls in Windows that were introduced in 32-bit Windows and later, In addition, if you read the original IBM ooDialog documentation, you will see that it puts forth an explanation that there are two objects, the Rexx dialog object and the underlying Windows dialog. It goes on to state that the dialog controls are the "data" of the dialog. So, in that abstraction it makes sense that if you wanted to know the current selected index of a combo box, you would ask the dialog object. Because the dialog object would know what its "data" is. My theory is that, as time past, either the original developers realized that their abstraction of only two objects was not robust and changed their abstraction to include dialog controls as objects, or new developers joined the project who did not use the original abstraction, but rather used an abstraction that they were many objects, which included dialog control objects. Again, though, I don't know that we need to go into that much explanation of the why. I personally would never think to ask the dialog object what the selected index in a combo box was, I would just ask the comobox directly. Other programmers might prefer to ask the dialog object. -- Mark Miesfeld ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ Oorexx-users mailing list Oorexx-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-users
