Hi david,

>We all have different ways of decomposing problems.

We do, and therefore anyones prefference coulde anotherones no-no.

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

I agree with the UDF statement (Though there may be exceptions). In the case I described the code belongs to the object itself, not to the form. Anyway's you won't solve the problem when you want to add the controls to a toolbar in stead of a form.

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

That should work fine for VFP native controls. How about ActiveX controls ? Do you subclass them before using them on a form ?

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

I have a somewhat different error routines. Depending on the kind of error, the user can choose to cancel, ignore and/or retry. Some errors are real errors, some are merely warnings (like line too long, numeric data was lost etc.). I can extent this in having a more intelligent mechanism in which the handler can "learn" which errors are futile and which are not.

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

There are whole tribes (like me) still using the good old VFP database. When doing so, the error event is a real threat in handling the RI correctly.

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

Well, basicly I think you're right, but since not all programming aspects in VFP are OO this is hard to do. One problem is that the error event not only captures the error occured in the current object, but also might capture errors that are not related to the object itself (Error that occurs in menus, RI, OKLs, reports (?), etc.). Also, one must forget to use ON ERROR DO .... in their programs as the won't work anymore when an error event is into scope. So IMO, the VFP error handling capabilities should be improved in order to makes the OO error handling to operate cleanly. Until that point, we've to consider the right strategy to handle errors based on a number of application characteristics. IMO, the ON ERROR ... strategy seems to have the best global characteristic. However, I'm aware that in a Middle tier component or a C/S front ent (to some less extend) the error event certainly can have advantages.

Walter,