Naomi,

>The other way is using BindEvents. Check this topic in Help, not every event can be >bind, but most are.

The problem with BindEvent() is two-fold: first, since I'm not binding to a Windows event, I have to call RaiseEvent(). But if I could do that, I wouldn't have a problem in the first place.

The second problem is more profound. The surface area of a program should be restricted, as much as possible, to public methods and method arguments. One could say that events expose a _secondary_ surface area. The interaction of these two surface areas can become quite troublesome in large designs, much like multiple inheritance when used improperly. The last thing I want to do litter my code with user-defined events. The decoupling that everyone seems to be seeking these days can be achieved with proper abstraction. A dependency on events could indicate a weakness in the language.

I'll explore some options along the lines of your first suggestion. I'm having a terrible time with VFP's particular implementation of OO concepts.

Thank you.

Eric