>>>>>Look at how Word and Excel work. The data is always in edit mode.
>>>>>
>>>>>I don't think that's a very good analogy.
>>>>>
>>>>>Sometimes a good old-fashioned edit button still makes sense (though I agree, readonly is better than enabled, for the copy/paste situation)
>>>>
>>>>I have always felt edit buttons are of more benefit to the developer than the user. (And not even that much less work; how hard is it to set a dirty flag when a field value is modified?) Doesn't the user clearly indicate his or her intention to edit data by, well, editing it? Why should they have to click a button first, THEN edit the data? It's like having to announce you are going to open a car door before opening the door.
>>>
>>>Then how do you make sure you can lock the record first. Do you allow the user to enter data and then tell them the data cannot be accepted?
>>
>>You use optimistic row buffering and check for conflicts at update time. (I do like a Save button). VFP makes it easy to detect conflicts and present the details to the user in useful form. Then the user can choose whether to discard their mods or override those of the person they were in conflict with. Underlying this is an assumption that two users trying to update the same record at the same time is not all that likely.
>
>Our main app is for auto body repair. There is a very high chance that two people will try to work in the same repair order at the same time so locking at the star is mandatory. Different people are ordering parts, assigning work, etc. all on the day the car comes in.

For that application I agree with you, then.