SNIP
>
>If you want to shield yourself from unexecpted behaivor, only use BindEvent() with the 2 parameter passed at the end. That should get you most way there. To get you the rest of the way the there, never BindEvent() to a native VFP event. Problem solved.

Yes, that's how I would envision adapting it in an existing application, that's for sure.
And while it solves the 'unexpected' part to a large degree, I'd still like to give the next (code) reader a chance to see all the BINDEVENT()s. I think that a SetBinds() method is the way to go. I expect I'd be able to make it handle 'dynamic' BINDs/UNBINDs too with a little thought.

>
>>I guess I misused the term "class code" (see above). What would I call code that is NOT "built in" to a class (VCX or prg-based) but is for the instantiated object within the application itself?
>
>Like I said, you don't want any code that doesn't reside in a class. That said, the word for what you're thinking of is most likely "client code".
>
>The code that uses a specific class is the client code of that class. The client code would most likely setup its event bindings, but that really depends on what the system calls for and the design pattern you're using to implement it.

Yes, client code is the term. Thanks! I know I'll only be coding this stuff in client code myself.