As an FYI, I've passed this on to the VFP team, but first indications might be this was done "by design". If that's the case, then the documentation needs adjustment to reflect this change.

>Yeah, setting a property is the way to go now. For simple method calls, I assumed that BindEvent() would be completely polymorphic as it was in VFP8
>
>>In checking it further, there doesn't appear to be any way to get the RETURN value from the delegate, even if there is no implicit .T. return from the procedure. I changed your code to return 1 and the delegate to return 0 and was not able to see the delegates return at all. In practice with event binding, I've usually set properties indicating change in status instead of return values. Maybe what you're seeing is the reason why I've always done it that way, even in other OS's and languages I used to work with long before I started working on PCs and VFP.
>>
>>
>>>The RTM version. Read message 971680
>>>
>>>>Could you expand on that? Do you mean the shipping version or the public Beta?
>>>>
>>>>>As long as you don't need a return value from the delegate. A critical part of BINDEVENT has been broken in VFP9.
>>>>>
>>>>>>You can BindEvent every "CurrentControl" in your grid columns.
>>>>>>
>>>>>>>Hi all
>>>>>>
>>>>>>>I am trying to capture a double-click inside a grid, right now the double click is not registered by the grid. This grid is dynamic so the columns are not in my control to program to put in the controls double-click.
>>>>>>
>>>>>>>Please advise.