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.
2. Normally the object is flat, when you enter the control, it becomes 3D.
3. The all have logic to set a filter on the bound table based on the current value
4. etc.

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.

>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.
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<\PRE>

Walter,