>>No, I didn't miss the point at all.
>
>Sorry, Craig, I didn't mean to sound confrontational. Your message simply offered ways to implement what I felt was a useless and annoying dialog. You didn't say whether or why you thought such dialogs were good or bad so I assumed the worst. :)
>

No problem. Meaning is often hard to interpret in written messages.

>>>The fact is, I give my users a choice to a number of things in the Options dialog. For example, one option is "See save messages"<<
>
>That is of course the very best approach. What do you default it to? Do you find that most users are comfortable using Options to change things? I'd ask those users, too, why they chose to see that message. Is there something else about the application that makes them think that changes might not be saved after they click Save?

I default to no message. Nothing really about the application that would cause them to think that. It's what I call a "warm fuzzy" that's offered to the users if they want it.

>
>>>Another is "Prompt to Save". This applies when the user edits the record then moves to the next or closes the form. If the user chooses not to see these dialogs, then I force a save when the record pointer moves or the form closes. But, I leave it up to the user....much better solution than forcing one way or the other on them.<<
>
>Not necessarily. :) See below.
>
>>The timeout on the wait window does not force the user to click. They can continue on and keep working.
>
>You're quite right, of course. Do users know this? Or do they have to learn it? If so, how?

It's a training issue. How they are trained differs with each client.

>
>>As for the Save button, it is there on my forms...users have gotten use to a save button. Not just my applications, but all apps.
>
>That is one of Cooper's main points. Just because users have grown accustomed to being beaten doesn't mean we should continue to beat them. :) His ideas are revolutionary, and it's not good enough simply to say "that's what they're used to." Eventually, some brave soul will implement his ideas, and then users will be able to see if they like it. And remember that most users (over the course of time) are new users. They don't necessarily have the mental model of the file system in their heads, and they think the concept of saving is ridiculous: "I just spent three hours working on this letter. Of _course_ I want to save it, you moron!" :)
>

That's true. At some point, my users click another button. I have an "auto add" feature. Click New, add the record, click New again. The first record is saved and the form displays a blank record for entry. No need to press Save then New again. But, this is an option. The user can also set an option to ask them to save. Default is Don't Ask. The same thing happens if the user does a Query (I use QBF Builder from Classy Components, which, IMO, is a tool we should all use), moves to another record or closes the form. If they are in Add or Edit mode, and changes have been made, the data is saved.

>>>For example, I often fire up Word to crank out a quick letter, etc. I have no intention of saving it. How is Word supposed to know this? I would find it MUCH more annoying for Word to save everything I wrote, and then I have to delete it if I don't want to save it.<<
>
>Depends how easy it was to do. We're so used to the file system that when we think of this, we imagine having to go out to Explorer afterwards, finding the file, and deleting it. It doesn't occur to us that Word could simply have a Don't Save menu item, that would do this work for us.
>
>In the big, broad user community, what is more common: to write a document and save it, or throw it away? Cooper urges us not to confuse the possible with the probable. He says we shouldn't bother the user with obvious questions, but just to make sure that the unlikely choice is still possible. But make the most likely choice the easiest.
>
>I agree with you that I don't agree with everything Cooper says (his statements about online help are ludicrous). But in this case, I think he has a point (though I'm not sure it applies to database, especially in a multiuser context).

It's been some time since I read Cooper's book. However, there are some things to be said for familiarity. That's why I try to implement Windows standards in my applications. My applications work like others. It helps the user. You are correct, we don't need a save button, but it is another "Warm fuzzy".