we are doing multiple modifications to our diagram (programmatically), where the modifications might take a few seconds in total until completed.
We also want that all modifcations can be undone with a single undo.
Now I know it is not recommended but the first try was to start a transaction at the beginning and close it at the end and set the diagram to readOnly=true and allowSelect=false in between.
Functionally, it seems to work fine. However, if the user scrolls/pinches in the diagram, the following warning is logged in the console:
WARNING: In ToolManager.doMouseDown: UndoManager.transactionLevel is not zero
Why does the doMouseDown handler care about the transactionLevel? I am not doing any changes to the diagram at this point.
Also, do you think this approach is fine or would you suggest a different approach?
Yes, that warning is there so that developers can recognize a case where there might be mis-matched transactions resulting in an unexpectedly long transaction. I was going to tell you to set an undocumented property of the UndoManager, but it’s minified and thus inaccessible. Maybe we should export that property after all.
Scrolling shouldn’t result in that warning – it’s happening due to panning, i.e. using the PanningTool.
I think that approach is OK, but I’d make sure that the user is given a clear indication of why it’s no longer responsive, and that there’s no way that that state becomes permanent.
Oh, I just looked at the code, and that internal property that controls whether or not those warnings happen, is only set to true in the debug builds of the library. The release builds have that property set to false. So for you no change is needed, assuming you don’t use the debug build in your production environment.