Undo after changing text style does not restore everything

• Apr 14, 2015 - 23:46
P0 - Critical
S3 - Major

Right now I'm working on a really, really good new Getting Started score that I'm going to post at Getting Started score—revised version . As part of this, I colored at least twenty text elements in a few different colors, depending on what type of instruction or tip they contained. Naturally, I made these changes in each one's Text Properties.

Then I made a change (of font size) to the Text Style for staff text.

Along with the size change, every color was reset to black.

That's fine, because I can undo the operation, right? Turns out, no I can't!

Undoing the change in Text Style does not reverse that property change. So, I have the tiresome task of figuring out what color each thing was and changing them all again in their individual Text Properties.

Though the obvious factor in my case was color, I suspect there are other, less noticeable errors in undoing as well.

Marc Sabatella, this is one for the hit list. Please fix before 2.0.1.


No guarantees, but I'll look. Undo bugs are often very deeply rooted in the code and hard to fix without major restructuring, and that's not likely to happen for 2.0.1. Realistically, although it's unfortunate this happened, it seems like a pretty obscure case that very likely no one else would run into before 2.1 anyhow.

BTW, instead of using individual text properties to color text items individually, this seems a perfect application custom text styles. If you've got six different colors for six different types of tips, that could be six different custom text styles.

Data loss is a bit vague, I admit, but I guess I generally don't consider cases of imperfect undo as critical or even necessarily major. Things like the bug recently fixed were you might spend hours choosing enharmonic spellings using the "J" command, then save and reload to find all that work just gone - that's more what I personally have in mind. Not something where a single element disappears after a failed operation but then you can easily add it right back.

I would say that this bug is more "major" than the bracket bug, because potentially, it's more than one text element that could lose formatting, so it could potentially be non-trivial to add it back. But it's also a quite unusual thing to be selecting a bunch of text elements with different formatting and then trying to change the text style in the first place, which is why I said I woudn't be surprised if no one else runs into this. And expected frequency also plays into it.

Others may have other criteria in mind, but overall, other than crashes and corruption, we tend pretty stingy about use of these categories. And really, I'm leaning toward not always considering corruption crtical, since it seems a lot of corruptions really aren't even that hard to fix.

Considering the whole text style mechanism was rewritten since 2015, and knowing what i do about the specifics of the changes, I'd be pretty surprised if there were a way reproduce this particular problem. but right now the Inspector seems a bit messed up, something apparently went wrong with some recent changes...

Status active closed

Well, if so then I guess this issue can be closed as obsolete. Recent problems with inspector are probably better to be tracked in separate bug reports.