This one was hard to catch and hard to find a reproducible way for: SetExtState sometimes creates undo-points, sometimes not. This is definitely not right, as SetExtState should never attempt to create an undo-point, as it never changes a project.
Here's how to reproduce.
Preparation:
Step 1:
Install Reaper as portable.
Step 2:
Install SWS into the portable
Step 3:
create S&M_Cyclactions.ini in the resource-folder and and add these lines into it:
Code:
[Main_Cyclactions]
; Do not tweak by hand! Use the Cycle Action editor instead
Action1="test|40016|"
Nb_Actions=1
Version=3
[MainAlt_Cyclactions]
; Do not tweak by hand! Use the Cycle Action editor instead
Nb_Actions=0
Version=3
[MediaEx_Cyclactions]
; Do not tweak by hand! Use the Cycle Action editor instead
Nb_Actions=0
Version=3
[ME_Piano_Cyclactions]
; Do not tweak by hand! Use the Cycle Action editor instead
Nb_Actions=0
Version=3
[ME_List_Cyclactions]
; Do not tweak by hand! Use the Cycle Action editor instead
Nb_Actions=0
Version=3
[ME_Inline_Cyclactions]
; Do not tweak by hand! Use the Cycle Action editor instead
Nb_Actions=0
Version=3
Step 5:
Run Reaper
Step 6:
Create a script, that holds the following line in it:
Code:
reaper.SetExtState(reaper.time_precise(), reaper.time_precise(), reaper.time_precise(), false)
Step 7:
Show Undo History.
Now, the actual reproduction of the bug:
Step 1:
Open a new project-tab
Step 2:
open SWS's Cycle Action Editor
Step 3:
change the checkstate of the checkboxes for "Consolidate undo points" AND "Prevent UI refresh".
Step 4:
run the set-ext-state script from above. If it doesn't immediately work, do step 3 and 4 again.
You will see, that SetExtState creates an undo point. However, the content of the undo-point has nothing to do with the extstate at all(as regular extstates never change projects) but include SWS-cycle-actions-changes instead:
For instance, the undo state-change information might look like this:
Code:
<EXTENSIONS
- <S&M_CYCLACTIONS
- 0 0 0 0
- >
>
If you repeat Step 3 and 4, further undo-points get created. If you repeat only step 4, the creation of undo-points will stop eventually,
as there are no more "unrecorded" project-changes to add into the undo-point.
If you do Step 3 and 4 again, undo points will be created again.
This leads to the fact, that SetExtState seems to add undo-points at random. This behavior had been noticed by numerous scripters, but it was actually very hard to find out the pattern, after which it creates undo-points, as it only happens, when project changes happen, that aren't added to an undo-point, eg SWS changes things in the <EXTENSION-statechunk, or defer-scripts do changes without creating an undo-point.
So this seems to tackle a little the issue I pointed out in the Undo Oddities-bugreport.
However, in this case, it should be easy to fix: as SetExtState doesn't need to create undo-points in the first place, removing the code that tries to add an undo-point should fix the issue.
Tested on Reaper 6.43x64 and Reaper6.44x64 plus SWS sws-2.12.1.3 on Windows 7