>>>OK, last try: Pressing Enter is extra. New would not need it, it will nicely move to the field you actually need to start.
>>
>>Why would it not be needed? Is it that in your scenario, for new record:
>>- click new
>>- doc number field is skipped, focus lands on the next control
>>For any older record:
>>- click search
>>- type the doc nr you want, click Go
>>- if the record is found, it's displayed; if multiple records are found, there's a selector control (combo, grid?) where the user has to navigate, select,click OK
>>- click Edit
>>
>>In my scenario, instead of moving the hand off the keyboard to get the mouse to click New, the user just presses enter, which is just under the pinky finger. Instead of moving the hand off the keyboard to get the mouse to click Search, the user enters the search term straight into the same textbox, and presses enter. The rest is the same - except there's no Edit button.
>>
>
>This is the last try, after the last one ;)

Once you see 12th farewell concert of the same band, you get the hang of it :).

>For new record:
>- click new - or shortcut key, could be the Enter key so that you could see there is no difference.

If Enter is a shortcut for New, then what do you do with the form which creates a new record after every textbox? :) Or if you're relying on a certain commandbutton having .default=.t. during the "saved, waiting for next action" phase, then yours is more complicated, IMO.

>- doc number field is skipped, focus lands on the next control
>The difference is that you don't need the user manual.

I don't. Users, too, don't.

>Where "move your hand from the keyboard" is significant we use custom data entry forms.

Which are different - how?

>BTW, how do your users get the tooltip without moving the hand off the keyboard?

They try to use the mouse the first time :). Or they just press enter, see that they got a new number, and understand what's going on.

>For editing existing records:
>I don't find typing a doc nr in an empty text box very user friendly. We have multiple ways to locate or search for a record, typing the doc id is one, but we use a standard look-up form with one or more text boxes and some info/search choices for the user. Your edit design limits the search to using a doc id. What if the user doesn't know the id, and must use another criteria? The magic text box won't do...

For that there's the history button which pulls up the relevant columns in a popup grid, sorted by date, located at eof(). That's where they can really search. In most cases they've found an error in a printed document, with number on it, so having to go through search to find the number they already have isn't as handy as being able to type that number directly.

For non-documents (i.e. lookups), they can type a part of the name, and if it's found there, the usual popup grid shows up.

>IAC, I see that we think very much the same: "How can he not see how much better is my design?", so I feel that we could/should leave it here...
>

Frankly, most of this is not my design - it's my last boss's (you may remember the guy, he used to be a regular here), but I learned to agree with most of it, well, almost. There's a long list of where we didn't agree. This "thou shalt not have a New button nor an Edit button" is where we were on the same side. Which means, if I ever get to make something usable out of my forever-in-the-works framework, it won't have those buttons.

>>>>Right :)
>>>>
>>>Left!
>>
>>Over there!... too late. It ran away.
>
>:)
>
>Have a nice weekend!

You too!