Sounds crazy, but I would more than likely not come across this if it weren't for the recent progress bars. It gave a slight jump back to the beginning of the score for some reason for a brief moment after they were implemented, so I thought they were doing something. After checking, it was showing that they would Show then Hide two times in a row when pressing spacebar during lyric editing if you were currently on an empty lyric. And the only reason why I checked lyrics was because some dude on the forum mentioned he was having a hard time seeing the cursor, so I just kind of lazily paid attention to the cursor during lyric-editing.
Turns out there's a sneaky second layout that occurs. Actually it's the first layout that's the sneaky culprit, because the command state removes the first empty text so that it's not part of any undo-state. Makes sense, but the damned thing triggers a layout when doing this because it inevitably hits an endCmd() when ending the text edit, which does the update, and the cmdState didn't have an up-to-date start tick, hence a layout starting at 0/1.
Watch the wait time (this is 3.7-Evolution with like a 200 page score):
Took me way too long to figure this out. I thought at first maybe it was because of the recent change to the adjustCanvasPosition when editing a text, since that was the only thing recently that had anything to do with TextBase elements... The funny thing is this was a bug that existed already, and whatever I was doing ended up "uncovering" it. Plus I had to use a "special method" of updating the ticks because the way the setTick() normally works: it was disregarding my attempt at setting the first tick. Forgot I had this situation before and implemented a direct set for start and end ticks disregarding any "figuring out which tick to set to which" thing that the original code does
Sounds crazy, but I would more than likely not come across this if it weren't for the recent progress bars. It gave a slight jump back to the beginning of the score for some reason for a brief moment after they were implemented, so I thought they were doing something. After checking, it was showing that they would Show then Hide two times in a row when pressing spacebar during lyric editing if you were currently on an empty lyric. And the only reason why I checked lyrics was because some dude on the forum mentioned he was having a hard time seeing the cursor, so I just kind of lazily paid attention to the cursor during lyric-editing.
Turns out there's a sneaky second layout that occurs. Actually it's the first layout that's the sneaky culprit, because the command state removes the first empty text so that it's not part of any undo-state. Makes sense, but the damned thing triggers a layout when doing this because it inevitably hits an endCmd() when ending the text edit, which does the update, and the cmdState didn't have an up-to-date start tick, hence a layout starting at 0/1.
Watch the wait time (this is 3.7-Evolution with like a 200 page score):
Took me way too long to figure this out. I thought at first maybe it was because of the recent change to the adjustCanvasPosition when editing a text, since that was the only thing recently that had anything to do with TextBase elements... The funny thing is this was a bug that existed already, and whatever I was doing ended up "uncovering" it. Plus I had to use a "special method" of updating the ticks because the way the setTick() normally works: it was disregarding my attempt at setting the first tick. Forgot I had this situation before and implemented a direct set for start and end ticks disregarding any "figuring out which tick to set to which" thing that the original code does