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.
Thank you for the reply! Yes it is shown during panning.
While I understand that it might help in certain situations, it is also a bit irritating during development to see warnings in the console even though it is okay what I am doing.
Hmmm. Normal panning when using the debug build does not result in any error or warning messages. So the warnings must be because your long-running transaction is ongoing at the time that the user does a mouse-down in the background. I guess that’s OK, but if you allow the user to perform a normal transaction like a move or a delete, those changes will be melded into your long-running transaction. That’s why I suggested that you make it clear that the user shouldn’t do anything. Or you could make the Diagram.isReadOnly.
from the user perspective it should be fine. I am setting the diagram to readOnly and also indicating visually that the user cannot interact.
I was just concerned with the developer experience. The developer now has to ignore console warnings during development, which might lead to other, more important warnings being missed.
OK, you have made sure that regular modifications cannot be performed by the user, so we are still left with not understanding what changes are happening during panning. Have you tried setting a breakpoint in a Changed listener to find out what might be causing those changes?
The changes are initialized by us programmatically.
Basically the user presses some button and we start a long running transaction (usually 2-15 seconds).
Until the transaction is finished, we set the diagram to readOnly.
From a user perspective, this works fine.
From a developer perspective, we get a warning in the console when panning during this transaction. This is a bit confusing as we need to check each time if this is a warning we can ignore or if it is a warning we should handle.
Maybe it is possible to show this warning only if the diagram is not readonly?
In 3.1.8 we’ll not minify the undocumented and unexported UndoManager.checksTransactionLevel property, which defaults to false in the release build and true in the debug build. You can set it to false when you want.