>>>I read what she wrote. I solidly disagree with her on this point. But, she's staying out of it and not offering solid reasons why it's a good idea apart from style preferences.
>
>Since this isn't US politics, you're allowed to disagree without being a bad person. ;-)
>
>FWIW, I see both sides of this and would tend to follow the other herd not least because different invocations do sometimes need to perform something extra in the GUI. As an example, right-click in a grid might need to save/restore alias() or RECNO() depending on what's going on, but not when it's called from a button. If you found that, no doubt you'd move the shared functionality to a method. Or even a linear proc: sometimes I wllfully create old-fashioned linear code to avoid clicking/hunting around for methods that are also encapsulated in the VFP IDE.

I've had a couple cases like this. I've added a parameter to the event and then test PCOUNT(). If it was 0, it's called from an event. If it's 1, it's called programmatically.

Always more than one way to accomplish a task.

We had a legacy edit form that was used for add and edit. It can be launched from a grid by double-clicking, or programmatically if it starts up from some other location. The easiest fixup to address the legacy needs and the new auto-startup feature, was to pass a parameter to the add button's click event, and doing exactly that as above we knew if it was launching from a type of automation, or from a user input.

No refactoring. Just a little ingenuity. And, when you look at the click event code, you'll see the parameter and the comment explaining why and how it exists.