>>if nKeycode=13
>>nodefault
>>this.LostFocus
>>endif
>>
>>This worked for not toggling the checkbox state
>>however the control didn't lose focus. If I set
>>the focus to the next control it works fine. It would
>>be nice to have a more universal method of setting
>>focus to the next control. Maybe keyboard {TAB}...
>>
>>Gary
>
>Now I'm having this situation for enth time - the supposed method for a
>control passing focus to the next control in the TabIndex order is not
>to .lostFocus the current control, but to .setFocus to the next control,
>and there's no .nextControl property (at least not in the base control
>classes).
>
>My form class has an array of relative indexes into form.controls,
>ordered by TabIndex (only for controls which have TabStop=.t.), so I
>have a way to know which control is the next. Though, in the days of
>FPD, a simple _curobj=_curobj+1 would have done the trick. Hey, it said
>"_curobj - index of the current OBJECT" :). So FPD, which had Foundation
>Read and Read Modal and other obsolete contraptions, did have array of
>objects, lined up in the order their gets were issued, and in VFP, which
>is fully OOP and BlahBlah and what not, your object must know the next
>object's name (who said encapsulation and independence of
>objects?).
>
>Just like the FPD days - if you don't know how to do something from a
>program, simulate it via Keyb command. If someone answers one's own
>message, it's called recursion; if my program has to talk to itself via
>Keyb, that's solipsism.
>
>So, FoxWish: any object in the form should have .NextControl and
>..PrevControl properties. Votes?

Thanks Dragan...my KEYBOARD '{TAB}' worked. However your indexing of
controls intrigues me. Many users that have intense data entry don't
like the user interface in windows and prefer a host of KB shortcuts.
Any goodies you have would be appreciated.

Thanks...enjoying the sun in So Calif.

Gary