>>I'm of the opinion that we need a save button, mainly for the reasons already given. However, the interface you saw does have a couple of problems.
>
>I think you're missing the point, Craig (with all due respect). It's simply moronic to have a message interrupt you to tell you that the program miraculously accomplished something that should be taken for granted.
>
>>First is the use of the WAIT WINDOW. Too easy for the user to miss. If I require the user to respond, I always use MESSAGEBOX.
>
>Good point. On a high-res display (like my 1280x1024), it's very easy to miss a WAIT WINDOW way up there in the corner.
>
>>Second, there is no reason for the user to press a key at that point. A WAIT WINDOW with a timeout of 2 seconds should be sufficient.
>
>This is a bad idea, in my opinion. Two seconds is a very long time (try saying "one elephant, two elephant"). Timeout messages belong with blinking text in the Stone Age of user interface design. And if you can click the message away, then that's what people will do, and it will be no better than a MessageBox.
>
>But the main thing is that a program shouldn't waste the user's time by requiring any action from her that doesn't further the user's goals. If it is that extraordinary that data should actually be saved, then a status line message is sufficient.
OK, Mark. this is all fine and dandy if you don't have to worry about security. However large companies out there love security within their applications. Why? Because no-one without the proper authority can save changes to a document. One of the nice reasons for the save button is for it to work just like the OK button in the dialogs I was talking about: yes, it saves the changes and also closes the form. But what you don't realize is that in those windows dialogs, when you click the OK button, it is actually calling the same code the Apply button does, then when that's done, it closes the dialog.