I did a little debugging and found that the default property *was* being set to .T. -- but by VFP, not by me. I didn't bother to figure out when and where exactly this occurred, but it was set to .F. in the form designer, and there was definitely no code changing it. This form has other bizarre qualities, like the table disappearing from the data environment when I save the form in the Form Designer -- this happenned at least 8 or 9 times! I tried packing the .SCX but it made no difference. Not to mention that when I *intentionally* set the default property to .T. for a button on the other form in the set, it's ignored! I guess I've just stumbled upon some obscure VFP bug triggered by a unique set of circumstances. Maybe it'll disappear when I upgrade to 6.0. -- or maybe it's a feature, not a bug!


>Good it's solved Chris. (Now I'm stumped. How could a button that has focus in init could keep focus, after focus moves to another control, w/o default = .t. ). Anyway I think I misread your original posting.
>Cetin
>>John, thanks for taking the time to figure this out! And I certainly have no problem with the idea of the find dialog initially popping up -- it's a good one.
>>
>>I owe you one. :D
>>
>>-- Chris
>>
>>
>>>The problem stems from the cmdFind.SetFocus() in the Form.Init. Once I
>>>removed that, the Find button remained normal. However, I realize that
>>>you want the default button to be Find....so...I substituted a
>>>cmdFind.Click() and the Find form pops up on entry.....once you cancel
>>>or OK out of that form, the data entry form operates
>>>normally......so....your two options are to discard the SetFocus or
>>>replace it with a click()....which is not a bad thing: Most of my data
>>>entry forms fire a find dialog when you first go in.