>John and Mark,
>
>So how do you guys override or enhance behavior in certain instances of a control? How does your inheritance work? How does your approach support polymorphism? Do you keep your prg's with the class libraries or with the forms themselves? Do you have any forms with a private data session, (UDFs run in the data session 1)?
>
>Just a few little problems you may run into later.

Jim,
my business is writing and maintaining a complex management and accounting system for auto body shops. Complex in what it does behind the scenes but extremely easy to use for the average receptionist at the front desk and the service writers that use it all day. In that system we have a total of 29 custom controls, forms etc. Very few controls have more than one parent and those are at the max three levels from the base control. This has produced a system that is extremely fast and reliable. This system does not need constant change. In fact change is what the customers don't want.

If I were working for a customer with a large data set and many departments/users that constantly needed new views of that data then yes, following the OOP rules would be the best way to go. However, in our system we would never use one form as the parent of another form.

By the way, we are getting ready to get rid of the DBC. Too many problems with it getting whacked because of system crashes. When your customers are running 2-10 stations per site and the small ones are Windows Peer to Peer running on computers "Custom Built" buy the owner's brother in-law, system crashes are a common occurrence. You need to install VFP to correct that damn "Validate Database" error.

Much of this is "against the rules" I know, but you have to look at what you want the end result to be. Not what the current "correct thinking" is. In my case I would much rather spend a few more hours coding if it produces a more stable system.