>>>It will take me 10 years to refactor all places where I have code in the event method (e.g. cmdSave.click()) :)
>>Start with the ones where you're calling that code from elsewhere. There should never be calls to event methods.
>>Tamar
>
>I disagree with this advice. Calls to event methods are essential to simulate the user activity programmatically. Every app I've worked on since the 1990s and VFP3 uses them routinely. We've never had any issues. We've even added parameters to things like the Click event, so that we can pass in a flag indicating it comes from a call rather than the default event.
>
>VFP is very flexible in this regard. I would never advise people not to call events, and especially so the IneractiveChange, ProgrammaticChange, Before/AfterRowColChange, or Click events. These all have particular purpose and are useful in event-driven and procedural-driven code.
>
>-----
>I've looked at the Wiki page and it suggests calling methods to do the work that could otherwise be done in the event.
>
>If you're building a class hierarchy I would agree with this. If you're dealing with base classes and parent classes culminating onto the final presentation on a form or class at the user-level, then anything you add to that final presentation, any event or method code is fully acceptable at that level. And I would debate anyone who says otherwise. :-)

As I just said to Dmitry, it's my view that if you find yourself writing code that calls a Click method or a Keypress method or some other event method, you should put that code into a new method and call it both from the event and from whatever's calling the event.

I'll extend that here to say that there are situations where you should use RaiseEvent() to make an event fire, but that's something different entirely.

Tamar