My plugin draws custom graphics to display some text information that changes depending on which body is selected. (This is outside of the command itself, and occurs anytime the current selection changes.)
Unfortunately, every change to custom graphics seems to register in the history. Since the graphics are redrawn when the selection changes, simply clicking around on a model quickly makes the user's history unusable:
Is there any way to temporarily disable this behavior?
Solved! Go to Solution.
Solved by BrianEkins. Go to Solution.
I did try to preserve the custom graphics object and only change the text (rather than recreating the entire custom graphics), but that still seems to register in the history:
Hi @perryK67ZX -San.
I don't know what kind of processing you are doing, but for temporary display, I think you can use the ExecutePreview event to display without polluting undo/redo.
Although it is not custom graphics text, here the custom graphics are displayed in the ExecutePreview event and the undo/redo is not polluted.
Hi San, thanks for the suggestion.
Unfortunately that fix isn't applicable to my situation, as the graphics I'm drawing are being drawn outside of the context of a running command.
(The idea is to expose the information I'm trying to display even while other commands are being run, or while the user is simply manipulating/viewing the assembly. Previously I showed it in a Palette, but I was hoping to use custom graphics for a more native look.)
Hi Mr. PerryK67ZX,
Consider:
Thanks @Anonymous , this looks like it might be what I was searching for.
Do you have any links in the documentation where I can learn more about this command? I don't see it in the API docs anywhere.
What's happening is any edit or write operation you perform using the user interface or the API is wrapped within a transaction. Transactions are visible in the UI as items you can undo. Even though custom graphics are not saved, they are still transacted so they can be undone within that session. When you run a script, every API call you make that edits or creates data will create a new transaction, which also means a new entry in the undo list.
When you use an add-in and a command, the work the add-in does within the execute event is wrapped within a single transaction so it can be undone with a single undo.
Ideally, the API would expose some low-level transaction support. The Inventor API has this so even in a simple script, you can start a transaction, make API calls, and end the transaction so everything is wrapped within a single undo. Inventor also supported combining your transaction with the previous transaction. This would result in nothing new being added to the undo list, but if the user undid the previous action, whatever happened in the transaction you combined with it would also be undone. I don't know if any of this is coming or not. Hopefully.
The use of any text commands is not supported. They're meant for internal use and primarily for testing. The suggested text command clears the undo stack, so nothing can be undone after you run that command.
Ah, bummer. Sounds like the answer to my original question is "No", then. I'm not sure I want to rely on unsupported APIs, and I certainly don't want to completely clear the undo stack. Oh well.. 😕
Can't find what you're looking for? Ask the community or share your knowledge.