Hi Walter, See below.

>Hi david,
>
>>Well I've never come across code that I'd really want to share across Textbox and Spinner.
>
>Sorry to say so, but the fact that you did not come accross such cases does not say me anything. For example I've got subclasses for textboxes, editboxes, comboboxes and spinners which have more or less the same code in it for creating a simular behaviour:
>
>1. Display changed data in red, non changes in blue.

We do that.

>2. Normally the object is flat, when you enter the control, it becomes 3D.

We do that.

>3. The all have logic to set a filter on the bound table based on the curret value

Okay, we don't do that.

>4. etc.

We do that too :-))
>
>In VFP there is no way to do this in a clean way other than having the (almost) the same code in all four classes.

BUT : I can imagine a. that the app is running in several instances and b. therefor some high level class is convenient. Sadly it would need some up-generated methods for that, and I think it can't be done. But, it WOULD be useful. Or the other approach : be able to start the life of an object in an object that suits all objects. That object must have a common denominator of properties and methods of the underlaying objects. I can imagine other languages having that. Anyway, it could IMO be done and would be VERY useful.
The best approach would be that the top level object would obtain the common denominator of the underlaying object automatically. It would be a new dimension in OOP for me ...
And it would solve David's complaints (which in general are legitimate ...).

>
>>I'm a very strong believer in only having code in one place, redundant code should be avoided all the time. In the PTF OOP book the lowest level classes there all had the exact same Error() method:
>
>Well, I've got some real trouble with the Error event in all objects.
>1. I do have to make sure that every object has an error event.
>2. Errors in procedural code cannot be handled this way: They're captured by the first object in the executing line, not neccesary related to the executed code.

I am not sure what you mean by "procedural code" in combination with "... captured by the first object ...". But I gues I am unexperienced on the Error method. But I can add this to it :

It would be rather normal to have one READ EVENTS in the whole app, in effect during the life of the app. Well, sure we have more (incl. CLEAR EVENTS ;) In fact, they are all over the place.
Not familiar with that : well, just try to have the real unbound OO - Biz functions app. Bot have to be in control at their times, and the only way to give control to the biz functions, is to let go of the Event stuff.
This may be hard to undestand (and is more hard to explain), as long as it is accepted that there are stupids around (like me) who do that.
Anyway, so much for the Error event. It just won't fire ...
But that is probably why the ON ERROR still exists, and I'm glad for that.

Peter

>3. Code in Error methods do conflict with the ON ERROR function in the RI code in the database container, making the RI mechanism fail.
>
>I never thought using the error event was worth the trouble. I almost never use them. In cases where I could expect an error the good old strategy would also work:
>
>

cOldError = ON("ERROR")
>ON ERROR Do MyStuff
>
>...
>
>ON ERROR &cOldError

>
>Walter,