Skip to main content ↑ ↓
Topic: "cancel" vs. "close" in the contents dialogue box (Read 14786 times) previous topic - next topic

"cancel" vs. "close" in the contents dialogue box

This is a small irritant, but it's still an irritant.

When making changes to the score contents, the dialogue box displays a "cancel" button, allowing you to opt out of your changes before they happen. If, however, you check how the score looks with the handy "print preview" button that is also in that box, when you close the preview window the "cancel" button has been replaced by a "close" button, which functions exactly like the "ok" button directly above it: it makes the changes and closes the dialogue box. So if you have decided, on looking at print preview, that you don't want the changes after all, you can't just cancel the task; you have to undo all the changes by hand.

I realize there is a need to make the changes temprorarily in order to send the proper output to print preview. But it seems a small thing to store the original state so that it can be returned to if the user chooses to cancel the operation after checking how it looks. Seems like it wouldn't take much more code than changing the "cancel" button to a "close" button which, in this situation, is really superfluous.

Way below other things (especially reparing the slurs) on my priorities list. Still. . . .

Cheers,

Bill

Re: "cancel" vs. "close" in the contents dialogue box

Reply #1 –
That's an interesting glitch Bill.  Were you aware that you can get back to the original contents with "undo" {ctrl}{z}? 


Re: "cancel" vs. "close" in the contents dialogue box

Reply #2 –
Yeah, I'm aware of the power of <cntrl><z>. I just think that, if a change hasn't actually been applied (that is, if the user hasn't chosen to OK it and go on to the next task) the change should still be able to be cancelled. That's the way it works in most programs, and that's the way intuition says it should work. If you haven't chosen to make the change yet, the change shouldn't take place.

I know. Picky, picky. It's not a big deal, just a minor irritant I'd like to see addressed. Someday.

Cheers,

Bill

Re: "cancel" vs. "close" in the contents dialogue box

Reply #3 –
A bit disconcerting, nothing more. This reminds me of why I hate to write User Interfaces. Is is an unending struggle between consistency and functionality.

Although it looks much the same, the Page Setup Dialog works differently than the Properties Dialog. In the Properties Dialog (staff or selection), nothing is changed until you exit the dialog. Try changing the stem length or vertical offset, the change doesn't take effect even if you move to a different tab. Less functional, but consistent.

It would seem to be possible for NWC2 to record the position of the Undo Buffer on entry to the Page Setup Dialog and roll back to this point if the user selects Cancel.

I don't see a change to this as a high priority. I am happy with the robustness of the Undo system.
IMO, highest priority needs to be given to things that are typograhically wrong or incomplete. Next would be to improve the defaults.

OTOH, the whole Print Preview subsystem needs a top to bottom rework. NWC3 perhaps?
Registered user since 1996

Re: "cancel" vs. "close" in the contents dialogue box

Reply #4 –
Quote
highest priority needs to be given to things that are typograhically wrong or incomplete.

Rick: I guess that was intentional to make the point!

Re: "cancel" vs. "close" in the contents dialogue box

Reply #5 –
Maybe Rick was just trying to match my
Quote
need to make the changes temprorarily
in the original posting....;-)

Cheers,

Bill