Bug: Renaming highlighting styles results in data loss
NB: Don't try to reproduce this with highlighting styles you actually use *POSSIBLE DATA LOSS*
To reproduce:
1. Open the highlighting panel and create a new palette and styles, and highlight some text.
2. From the style dropdown click edit, and rename a style to something else:
The result: all highlights in this style are lost and default back to "highlight with note colour":
If you rename the style back to what it was, the highlights are not recovered:
Note that styles can also be renamed directly from the drop-down menu, rather than the edit screen:
When renaming in this way, the result depends on whether a note is in the palette-specific note file, or another file. In this screenshot one of the purple highlights is, and one isn't:
Renaming from the dropdown menu, the one in the palette-specific note file is retained, the other is lost:
Now if I rename it again from the edit screen, the one in the palette-specific note file is also lost:
Comments
-
I'm having some trouble reproducing this issue. What version of the program are you running?
0 -
I'm running 5.0b beta 1, I tried it again just now; and first it seemed like it was fixed but then I repeated the renaming step a few times and it reproduced what you see above. Maybe 1 in every 2 or 3 renames will lose all the highlights in the process.
0 -
I am able to reproduce the issue if I have the note document for that pallet open at the time. I will report this to Development.
0 -
Ah, that explains the variability [:)]
0 -
Brisa,
it seems someone caught this bug in real life - at least the description reads very similar. Can you do something for his data here: http://community.logos.com/forums/t/64250.aspx ?
Mick
Have joy in the Lord!
0 -
Just so I understand, as I am facing this very bug real-world; only a note which is open and has the markups will be affected? Other note files, which are closed, but which also use that palette, are not affected?
0 -
This bug was fixed in RC 1.
0
