>>>So, if the user is on an existing record, and wants to add a new record, he must click on or select a field and enter something (I'm guessing some kind of ID). How is this better than clicking on 'New' and selecting the field in code? How does the user know which field to enter / select for a new record (color, label, tool tip,...)?
>>
>>Haven't decided yet :).
>
>That says something... I suggest you reconsider your beliefs about 'New'. This shouldn't be too hard (especially for a non believer type like you), so bring back the 'New' button from the UI hell. After this, all you need is the 'Edit' button, and you'll be truly saved ;)

I'm doing no saving until I get a decent percentage above inflation, plus $5 a month just for the pleasure of it. Like I heard the other day: "Jesus saves - Krishna invests!"

>I find the UI with Save/Cancel explicit, Edit implicit, and Add somewhere in between, inconsistent.

Add is implicit. Or should be, IMO, on data entry forms, regardless of their mass.

>Also, with editing implicit, are Save/Cancel buttons enabled at all times, even if there is nothing to save or cancel? Or, do you run code for every keystroke to check if there is a change or not, and enable/disable Save/Cancel?

On any control's .lostfocus - just like VFE does.

> We have shortcut keys for all buttons. Esc cancels the adding/editing, or exits the form when not adding/editing (we use the 'Cancel' property to do this). We use the Enter (‘Default’ property) mostly in dialog forms.

We pretty much agree on this. I also keep the cmdOK.default=.t. only on small dialogs, where there are not many controls.

>>This IS better when you're doing heavy data entry - once you save, the form is ready for the next document. No need to tell it that you want another one. I was watching professional data entry gals & guys for a while, and if I may speak for them, whoever decided that Enter was supposed to mean "I'm done with this FORM" and Tab "I'm done with this field" obviously has never seen one-hand, digits-only entry. They'd use their left hand to go over a paper document, and the right hand was just fuzzy over the numeric keypad. But I digress. The fewer trips between mouse and keyboard, the better.
>
>Heavy data entry forms are special cases, and we do have very specific UI for each case.

I'm trying to be consistent, i.e. not to have different behaviors in different cases. That may be good for in-house app, where you can just stand behind users' backs for a few days until they break the app in, but for off-the-shelf, you need to have the same thing everywhere, as much as possible.

>During data entry, 'New' and 'Save' occur transparently to the user 99.99% of times. If you need to go back an edit a record entered 15 minutes ago, that is no longer ‘heavy data entry’, so you will need look-up, edit, save… buttons.

Sure there's always a way to look up previous documents - type the (partial) doc nr, or hit the history button, or a special key (used to be F5 in FPD days, now I'm thinking which'd be better), get a form with a searchable grid, select a document and there you are. Start editing and click Save or Cancel when you want.

>However, the OP did not ask about heavy data entry, specifically... If you said that “This IS better when you’re doing heavy data entry” from the beginning, you would have saved me from trying to save you. I know how much you like being saved without asking ;)

I really don't like banks.