Confusion of SetAll() parameter 2

[Mike Lewis]

The other day, I was chatting to a fellow VFP developer, who was confused about the SetAll() method, and wondered if he had discovered a bug.

He was trying to use SetAll() to change the font of a number of objects, and was surprised that the font change was applied to objects based directly on VFP native classes "despite what it says in the Help".

He was referring to a line in the Help that says that the third parameter to SetAll() "specifies the class name (the class on which the object is based, not the Visual FoxPro base class for the object)." He interpreted that to mean that you couldn't use SetAll() with objects based on VFP base (i.e. native) classes.

Now that's not what the Help says, but I agreed that it was badly worded. I think most developers would understand what it means, but in case anyone else is confused about this, let me clarify:

1. If you don't specify a third parameter to SetAll(), it will operate on all objects, regardless of class.​

2. If you specify a base class as the third parameter, it will operate on all objects directly based on that class, but not those based on subclasses of the class.​

3. Similarly, if you specify a subclass, it will operate on all objects based on that subclass, not on those based directly on the base class. (I suppose this is obvious.)​

4. Also, if you specify a subclass, it won't operate on objects based on parent classes or child classes of the specified subclass. (This is a logical conclusion of points 2 and 3.)​

So, clearly, there's no question of this being a bug, but the wording of the Help could be clearer.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Chris Miller]

I agree, in short specifying a class you affect objects of this class and only this class.

So if you want to influence textboxes, for example, including all subclasses of them you have no choice but using multiple Setall calls.
The misunderstanding of not being able to use it on base classes is not very limiting, is it? You should subclass everything to have a root class you can later use for implementing a general behvior or feature or be able to apply a workaround of bugs. And if you do that anyway, you won't need to use SetAll on native base classes.

Chriss

 

[TamarGranor]

Here's how we put in it HackFox:

Unfortunately, SetAll isn't as cool as it could be. Although you can specify that all objects of a particular class are changed, you can't specify that all objects that have a particular class somewhere in their class hierarchy or even all objects based on a particular base class should be affected. Since we rarely use objects based on the VFP base classes, and work with an assortment of classes derived from each base class, using SetAll to make a change to all the buttons or all the combos on a form is harder than we'd like.

Tamar

 

[Chris Miller]

By the way, you could introduce a property with a property_asssign method to all classes and then call SetAll for that property. So you'd turn around the problem, let all relevant conrols have their own method.

The vNewValue parameter in the assign method could be used to pass in all necessary informaiton, think of either an array or an object based on EMPTY.

I also saw solutions using a mode property of the form and the cascading Refresh() of everything reacted according to mode, ie switch from read to edit mode or blank all controls of a filter form in a reset mode.

Chriss

 

[Mike Lewis]

Chris, good point about using _assign methods. In fact, I just remembered that I do something similar in my data-entry forms.

The form has the ability to go into and out of edit mode. This generally involves using SetAll() to toggle the ReadOnly property of the individual controls on the form. Not all controls have a ReadOnly property, but I still want to give them the appearance of being non-editable when the form is not in edit mode. So I give those controls a custom ReadOnly property, and use its _Assign method to effect the necessary change. (For example, I have a custom class based on a Container, which changes BackColor when the controls within it are not editable.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

A couple more points about SetAll() that some people find helpful:

[ol 1]
[li]SetAll() applies to all objects within the containership hierarchy. So if you have a form which contains a pageframe which contains a grid, doing SetAll at the form level will affect the pageframe itself, all objects on all pages of the pageframe, the grid, the grid's columns, and the headers and textboxes within the grid.[/li]

[li]But it doesn't affect the container which executes the SetAll(). So executing THISFORM.SetAll() will affect controls on the form but not the form itself.[/li]

[li]There is no validation check on the first parameter. So if you misspell the name of the property, there will be no error message but the method will have no effect.[/li]

[li]By the same token, you don't have to limit the call to SetAll() to those objects that actually contain the property in question. I have sometimes seen people do, for example, for a grid: [tt]THIS.SetAll("DynamicBackColor", "some condition", "Column")[/tt] on the assumption that they must specify "Column" as the third parameter because the other controls within the grid do not have a DynamicBackColor property. In fact, you can safely omit the third parameter, because the setting will be ignored for the other objects. (But I would guess providing the third parameter improves performance, because otherwise it would have to check all the other controls to see if they have the property in question).[/li]
[/ol]

Again, these points are probably familiar to most developers, but they might not all be obvious to all of us.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[atlopes]

Mike [et al.],

Just a reminder that most of the requirements expressed in the thread (if not all) were addressed by the implementation of a SetAllX method of a Custom object, as part of the VFP's Foundation Classes.

 

[Mike Lewis]

Thanks for the reminder, António. I only came across SetAllX recently, as I don't often look at the Foundation Classes.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads