>>There's a save button, sure. But editing is enabled by default. And depending on the type of the form, a new record or editing an old record depends on what the user enters in the first field etc. There's no Edit button, no New button. The user is always presented with a blank, editable record, and a way to get to an old record.
>>
>>If a form is read-only, there's a reason for that - it may be a view form, or a lookup form or whatever. A data entry form is not read only by default.
>
>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 :). In frameworks which had this, the user would have to either cancel or save (so to decide the destiny of the record being currently edited), or press a predefined key (and it was the Home key last time, which annoyed me and the author of the code as well, but too late - users got used to it, which is why they are called so). I still prefer the Save/Cancel (accompanied with Enter/Esc for hotkeys, or even better nothing and Esc).

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.