8.0/E APPLY button behavior - G

[robmorfin]

The APPLY button doesn't not behave as any other apply buttons in other programs, Revit's button is not the windows standard, I see it as user unfriendly.

Here is what happens:

-If you are in a dialog box, make any changes and press the apply button, changes are applied (as it should).
-If after applying changes you decide to cancel whatever changes you made, as usually you have done it for years in other programs, you click on the cancel button.
-The applied changes were not canceled, so either you undo the previous step or you repeat the dialog box and change back what was applied even when you canceled.
-The biggest disadvantage is that sometimes this can happen to you thinking that those changes were canceled, and you don't notice it until you print the project or hours after, then you have to find out what changes you made to be able to reverse them.

The apply button per windows standards is supposed to apply the changes you make in the dialog box as a preview only, if OK button is pressed afterward, changes remain, if CANCEL button is pressed, changes are not accepted and the preview is discarded.

Most companies knew and tried Archicad years ago, most companies didn't like it because it has alot of non windows standards like this, there is no time for us to remember for each program what reaction you are going to get from the most standard buttons from the dialog boxes (since windows 3.1).

[LRaiz]

I think your statements are not correct. What do you base them on?
Can you point out a page in the official Microsoft book "The Windows Interface Guidelines for Software Design: An Application Design Guide" that prescribes that pressing Cancel after Apply would undo effects of Apply? Alternatively, please provide an example in Windows where dialogs behave like you describe.

Without searching through the book I made a few experiments with Windows XP and confirmed that Windows itself exhibits behavior of Apply and Cancel buttons similar to Revit's. For example, open properties of one of your printers and make modifications followed by Apply/Cancel. Then open printer properties dialog again and observe that Apply made changes persistent. I can name other examples and I do think that as a matter of fact behavior of Apply and Cancel in Revit is consistent with Windows standards.

[robmorfin]

My mistake.

Yes, I was talking to support and we made the test with Internet explorer and under internet options after making a change it did not undo the applied changes.

[robmorfin]

I would like this post to be considered a wishlist item, I did not do the right research before posting it, therefore I gave wrong information and I apologize for that.

But I think it would make more sense to be able to cancel the applied changes before exiting the dialog box, if not, what sense does the apply button has if it does the same as the OK button before getting out of the dialog box without graying out the cancel button?, now, this is the logic the apply button is using:

apply changes immediately, you still have the chance to press the cancel button, but of course it doesn't matter that you press it because nothing will be canceled, and remember it so you don't accidentally think that you canceled what was applied when you pressed the cancel button.

[LRaiz]

So now you are asking that Revit would knowingly violate Windows UI standards and confuse people who expect Revit to behave consistently with other Windows applications?

[robmorfin]

I am also contacting windows support to let them know of this programming contradiction behavior in the logic they are using on their apply button, and I already said it is a wish for the wishlist of Revit.

"cancel but don't cancel if the apply button was pressed", you don't see that on any programming book.

[Steve_Stafford]

I'll move it to the wishlist forum if you like, but I agree with Leonid. Not only would it be contrary to how most other applications behave it would be inconsistent with the purpose for the apply button.

Apply buttons started showing up in applications to let the user see the results of their changes and keep the dialog open to kcontinue to make iterative changes.

I for one would be opposed to such a change...

[BWG]

I would like this post to be considered a wishlist item, I did not do the right research before posting it, therefore I gave wrong information and I apologize for that.

But I think it would make more sense to be able to cancel the applied changes before exiting the dialog box, if not, what sense does the apply button has if it does the same as the OK button before getting out of the dialog box without graying out the cancel button?, now, this is the logic the apply button is using:

apply changes immediately, you still have the chance to press the cancel button,, but of course it doesn't matter that you press it because nothing will be cancel, and remember it so you don't accidentally think that you canceled what was applied when you pressed the cancel button.

The point of the apply button is so you can see what happens and then make more changes as needed to get the result you want without having to leave the dialog box. The OK button is for one time changes - you know exactly what you want and what you have to do to get there. Once you hit apply, the cancel button will just exit the dialog box. You will have to use the undo button to reset to previous. If you want to discard previous changes, then there should be another button like "Discard" or something like that. I am very used to hitting apply, seeing it works fine and hitting either OK or Cancel to exit. Depending on which button my mouse cursor is closer to.

[bclarch]

Do not change the behavior of the apply button. If anything, then add a "preview" button. Canceling out could be made to undo "previewed" changes but not "applied" changes. Even then I don't see much need for this. Spend development time on other issues.

[robmorfin]

I Googled it and found a lot of discussions about the apply button behavior, this is the conclusion most of them had:


OK ==> Apply the changes and close the dialog box.
Apply ==> Apply the changes and leave the dialog box open.

Any other behaviour is either a bug or just bad programming - no
exceptions.

I think this closes the case, the apply button is fine (although the cancel button should change to "close" in my opinion after "applying").

Steve, please cancel the poll.