>You are exactly right in how you interpreted what I wrote. The code does directly call:
>
>

>Object.Click()
>

>
>In the process of INIT, there is code that says:
>
>

>BINDEVENT(lo_object, "Click", THISFORM, "metrics_start") && Pre-event
>BINDEVENT(lo_object, "Click", THISFORM, "metrics_stop", 1) && Post event
>

>
>We have found that programmatic calling of the Click event will fire the two BINDEVENT bindings just as if the user had clicked the control itself. I am unaware of any difference between programmatic and user Click.

You're right. But you could use the BINDEVENT higher flags to ignore programmatic calls to Click(). Wouldn't that still give you sufficient logging information?

> Thus, the issue of a GPF has arisen from a user induced Click firing a BINDEVENT binding (pre & post) and code within the callstack of the Click event programmatically calling a Click event on some other control, also firing the associated BINDEVENT bindings (pre & post) on that control as well. These "near calls" appear to step on each others in the internal threading and VFP "loses its way", causing the subsequent GPF.

I just tried this with two bound buttons with one calling the click() of the other. The various events consistently nested as I expected i.e.:

Button1 PreClick
Button1.Click() (Call Button2.Click() here)
Button2 PreClick
Button2 Click
Button2 PostClick
Button1 PostClick

Of course that doesn't mean this would hold in more complex situations such as yours...

HTH,
Viv