Hi David,

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

I know... yes you can do that, but in fact because of encapsulation issues you don't want to do this either, so basicly I endend up putting the same object into different subclasses of baseclasses. In fact in order to solve this problem VFP should support multiple inheritance in which all the major behaviour is inherited from the baseclass, but some methods and properties could be inherited from a custom class.


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

I guess you can. My problem with this strategy is that the contols become less independent (self contained). I want to avoid (as much as possible) on one object depending on another, esspecially for basic UI classes.

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

OK, that is you vision. Personally I like to develop database apps like they were just applications like outlook or excell. Just see the application as a document holder. Therefore toolbars are neccesary. For example: if my reports (Crystal Reports) were generated they show in a new window like a document: You can search through the document, Adjust the view (zoom), have a document view (the group tree), can archive, print, export and mail it.


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

Numeric data was lost in my applications only seem to occur when something dividing by 0 so the variable contains ****** . Not something I want to stop the application with. Of course this is something that has to looked into, but since I have about a hundred sites where my applications are running I'll never be there and solve the issue inmediately.

About the line too long: It seems I confused it with another error which occurs when the contents of a string does not fit into the SAY borders. I forgot the errorno. This is pretty harmless error. If you look at the list of error messages there are a number of errors you typically want to ignore (but do want to log) and hide for the user.


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

As the author of the TaxRiBuilder I do know what it takes to write a good RI mechanism. Handling errors is one of them. I guess I could make an object doing the RI stuff with an error event on it. However it will slow down the RI as it has to create the RI object and constantly checking if it exists afterwise. I do not say it is impossible, but it don't seem to make a lot of sense.

walter,