So when a long editDocument() is proceeding, and the user clicks the Stop button, what happens exactly, and how could we detect this instead of just crashing?
All I see in my plugin is the edits made to the scenegraph start failing out of the blue with exceptions.
This seems like a very poor UX.
So how could a plugin detect a cancellation and do something intelligent?
Hi there!
Any updates about this? I also have the same problem and did not found anything in official documentation about this. Nothing about how to handle this or detect inside editDocument callback that user canceled the execution.
I would be thankful for any advice from you, AdobeXD team.
Thanks.
See if this maybe helps How to handle the 'Stop' button event when 'plugin is working...'? - #6 by mightyalex.
@mightyalex Hi there. Yep it looks like the only way is to implement your own dialog which is a pity. It would be much better to have either static boolean flag available somewhere to check if user did an Undo operation or at least an event on which we can subscribe and implement our own flag. But anyway thanks for help.
Unfortunately, for a panel-based plugin, there’s no way to provide our own “stop” mechanism – the user is clicking the one in the “working” dialog that XD puts up.
Any ideas, @kerrishotts?
If XD’s default “working” dialog is insufficient, the only other option is to show your own. The benefit here is that you can now control the experience, including giving the user better information about what might be going on. For example, if your plugin is download a lot of images, you could include that information in the dialog.
Dialogs can be created from panels – and you can use a Promise to hold the editDocument session open until the dialog is dismissed (either automatically or by the user).
Be sure when you use your own dialog that you appropriately batch your long-running computations or other blocking work. Otherwise the UI remains clickable, but your plugin won’t have a chance to respond. setTimeout or setInterval are your friends here.
I had to redo part of my plugin because of a long process (see Vectorize plugin vectorizing the document). It wasn’t as difficult as I thought.
I used a pseudo sleep() method to give my loop time to breath and time to allow user interaction. Without user interaction the UI would lock up until the loop was finished.
Because editDocument modifications have to occur within a click event you can’t do some actions. So sleep() won’t work for everything. You would have to present a dialog and add a cancel button to it.
Maybe UXP could dispatch a stop event or have a stop callback method for when the automatic dialog appears? Then, @cpryland can handle for that bc sleep won’t work inside editDocument panel event.