Thanx, thats it alright. I called MS about the issue and the tech I spoke to had never heard of it and (like me) could not find anything on it.

>This is a documented bug that bit me. See article Q193292 in MS KB.
>Bill
>
>>I just tested and it's really so. Unbelievable bug (feature:). However the workaround is still regular: shift setfocus to Form.Activate event.
>>
>>>Thanks for all the good advise. My ISP blew up and so I have been off line for the last 3 hours...
>>>
>>>Anyway, I checked one of my old apps, and found that the ENTER performed as expected:
>>> - as the TAB key when the current focus is in a field, and;
>>> - press the button when the current focus is on a button
>>>
>>>After much 'playing' I discovered what I think is a bug. In my INIT, I have a:
>>> THISFORM.BTNWHATEVER.SETFOCUS
>>>As expected when the screen is initially displayed the specified button has the 'dots' around the word that makes up its label and the button itself has a slight shadow. When I click on a field with the mouse (or use the TAB) the 'dots' go away (as anticipated) but the shadow stays (i.e. the button still has some type of focus).
>>>
>>>When I remove the SETFOCUS line in my INIT (or set the focus to a field instead of a button) the form performs as every other app on the planet. This prob only seems to occur in when the SETFOCUS is in the INIT. I hav several buttons, events... where the FOCUS is set using the same command and I do not experience any problem. I checked this situation on four of my forms and all had exactly the same result.
>>>
>>>So, I beleive that using the SETFOCUS to a button in the INIT causes VFP to be unable to transfer 'all' of the FOCUS to another object.
>>>
>>>As a work around I now have set the focus in the INIT to a field instead of a button and the world seems to be a happier place.
>>>
>>>I could not find anything on it in MSDN or MS ONLINE SUPPORT. Has anyone seen this before? Is this a bug?
>>>>>
>>>>>There must be a simple way to override the default characteristics of the ENTER key so that it functions as it did in VFP2.6 and as it does in almost every other app in the world:
>>>>> - as the TAB key when the current focus is in a field, and;
>>>>> - press the button when the current focus is on a button.
>>>>
>>>>Actually, the Windows standard is to have one button be the default button. Wherever you are on the screen, if you press the ENTER key, it acts like you clicked on this button. Usually, the OK or Save button on a dialog will be set as the default button. This means that the button's Default property is set to .T.
>>>>
>>>>If you do NOT want this behavior (and from what I'm reading, that is the case), make sure that none of the buttons on your form have their Default property set to .T. If this is so, ENTER will just move you from field to field, and will only click a button if your focus happens to be on that button.
>>>>
>>>>As far as I know, this behavior is the same in versions 3.0, 5.0, and 6.0. As I said, it is a Windows standard, and this behavior is the same in just about any Windows-standard-compliant program I've seen, be it VFP, Visual Basic, Word, Lotus Notes, or something out of left field.
>>>>
>>>>Changing your app to override this behavior will make it more like a DOS app, and less like a Windows app. Make sure that your client knows that by requiring this behavior, thier program will NOT work like oher Windows apps.
>>>>
>>>>Bill