Walter,
We all have different ways of decomposing problems.
>>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
>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 think I'd tend to make all of these features methods of my form class and have the controls delegate the task to the method, not a UDF.
>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.
That was done with one simple line of code in every class in my cControls.VCX where all of my first level subclasses of the VFP Baseclasses is stored.
>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 functionally treat errors as real errors that should shutdown the application. I use defensive code to guard against most foreseeable "errors". I have a couple of classes that override the Error() method to handle very specific errors. If an other errors occur then they get passed off to the ObjError() which in the runtime environment log details of the error and shutdown the app. In the dev environment the debugger is launched. Since the only procedural code I use in in small well tested UDFs errors occuring in that code are not a problem.
>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 don't use VFP based RI anymore. I use C/S data now.
>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>
I think that objects should do their own error handling and that's what drove my decision to give all my lowest level subclasses an overridden error method, which facilitates the task.
