>>FoxWish: Default Command Buttons should receive the Enter key only if the command group (any of the buttons) has the focus, or at least there should be a property IsDefaultToForm, which I'd be happy to set to .f.
>>
>>Anyway, even if the problem of nav buttons catching enter whenever they want gets solved, still another one remains - the button groups (and grids likewise) don't have a way we can add our own class as their contained objects.

>Dragan,
>Can you work with the form Keypress event to trap the Enter key BEFORE it goes to the SAVE button? Approach this from the Button end instead of the OptionGroup end. Even if the form Keypress doesn't trap the 'Default' setting on your SAVE button, you can write a form/button class that has the correct behavior.

That was the next thing to try, but it was a hard day's night at 2AM and my shades fell shut down. Today I've added this to the form's keypress:
case nKeyCode=13 and HasActiveControl_ll
if inlist(ActCtrl_lo.BaseClass, "Optionbutton")
keyb chr(32) plain
nodefault
endif
Pressing space on an optionbutton fires optiongroup's .valid, which has this:
retu this.buttoncount-this.value+1
actually skipping to the next control (who said it's imposible to SetFocus inside Valid :), so it finally behaves as it used to and as I want it to, but it's a kludge.

Anyway, it's just a workaround - it will take care just of the keypress event, but the generall problem will remain. Anytime I want the optionbuttons (and the like) to behave the way I want, I'll have to play with lots of SetAll in the optiongroup/pageframe/commandgroup/grid etc, which of course can't handle setting common methods for those - I'll have to go clicking down the 25 buttons and paste a call to .parent's custom method anytime I need some common behavior for the buttons, instead of just using my class of buttons. Seems to be this part of VFP never got really worked through. Has Microsoft confirmed this to be a problem in the products listed above?

>The problem with radio buttons is identical to adding custom columns in a grid or pages in a pageframe. I've never seen any way out of it except having n columns/opt.buttons/pages where n is greater than you'll need. (25?)
>
>Sorry,
>Barbara

Exactly what I was afraid of. Phew. If that gets repeated in Tahoe...

Real solution would be that these base classes should have a DefaultButtonClass property, which should contain a reference to the class which will be used to populate it with new members, whenever its buttoncount/pagecount increases.