>It's not so much that it fails from an error... Basically, if the control is sized to small, there's not enough room for it to place all the objects. So when the main container inits, I have it get rid of its controls and replace it with a label that says the stuff in it wasn't able to init. This would never be seen by the end user unless the programmer is dumb enough to release it without making the control big enough. :)
>
>It's just a safety net for the programmer.

In that case, use an ASSERT to write a message via DEBUGOUT indicating what failed, and give the developer the option of immediately opening the debugger to see where the ASSERT triggered, indicating that your cde behaved in an unexpected fashion. This will enable the developer to deal with the error in detail when it occurs in the context that it occurs; ASSERT doesn't fire under the runtime, so you still need to make allowance for the end-user to record the error and report it back to the developer.

ASSERT provides for runtime checking of program assumptions when running under the developer mode, and is ignored in the runtime. If you're putting in a safety net, protect the user from the consequences of the error, otherwise, all you get from them is "This piece of yafrax doesn't work!", with no hint of what went wrong.

>Michelle
>
>>I was wondering if the control.Init fails because of an error or because it is supposed to return .F. sometimes. If the former, what does your error handler do? The solution should be related to that. But I'm no expert on error handling. Books such as the Hacker's Guide will say "you could write a whole book about error handling in VFP, and someone should." Then they don't say much more about it.
>>
>>If the latter, you could still raise an error and let your error handler set the property or whatever, maybe.