Walter,

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

But if you don't want to duplicate code across control subclasses you can put it 1) in a container that they can all delegate to, 2) an external services object that they can all delegate to, 3) a UDF that they can all delegate to.

>Anyway's you won't solve the problem when you want to add the controls to a toolbar in stead of a form.

Your Form and Toolbar subclasses can delegate off to something else that they both have access to.

Personally I find toolbars pretty much a waste in a database app. Docked they take up more screen real estate than equivalent controls in a container right on each form. Docked they require more mouse motion to get to them. Undocked they are always getting on top of something and they need to be moved around. So on the whole I don't use toolbars inside my apps. I think they are good for things like VFP itself, Word, Excel etc, but not in a form centric database app IMHO.

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

Subclassing ActiveX have a whole separate set of deployment issues. When I do this I tend towards using a Helper object, that is a native VFP class, that the ActiveX makes method calls to.

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

I pretty much think things like "line too long" and "numeric data was lost" are pretty darned serious errors and should be app killing (controlled shutdown) fatal ones.

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

You are quite free to hack the RI code to fix it as needed.

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

My ON ERROR handler is believe it or not:

ON ERROR ObjError( .null., nError, cMethod, nLine )

the lifetime of this error handler is about 10 lines of startup code before the first object gets control and the last 10 lines of shutdown code after the application object goes away post CLEAR EVENTS.

I agree VFP error handling can stand some improvements. It works adequately enough for my needs. We'll have to see what might get shown off at Devcon in a couple of weeks.