Modifying the Document with a Transaction before the built-in Print command

[Anonymous]

I am working on an add-in that improves the default settings for the built-in print command, based on the active view - the filename, the paper size, etc. 

Right now I have it working as I want it to, however, it is hooked up to the ViewActivated event. It parses the activated view's properties and creates a Transaction to modify the PrintSetting and call PrintSetup.Save to apply those changes. I would like to optimize this so that on ViewActivated, the information is only collected, and then applied and saved in a Transaction only just before the actual Print command is executed. The performance hit might be negligible (though I'd like to improve it as a matter of principle), but more annoyingly the Transactions create undoable history steps for every view change, which I would like to prevent.

Hooking my code up to BeforeExecuted for the built-in Print command fails with an error about document modification not being allowed, and I gather from online documentation that the BeforeExecuted Event is indeed read-only.

So, the approaches I'm considering:

1. Override the actual Executed event for the built-in Print command - I would only do this if I can somehow easly re-conjure up the regular Print command after doing my own business. Is there a way to do this? Reposting a Command from within the overwritten execution of itself seems like a bad idea.
2. Is there a way to Commit a Transaction without an entry in the user transaction history so it doesn't fill up? Seems like really bad practice, but it would be a hacky way to improve the experience.
3. Hooking up to something else? I looked into the UIControlledApplication.DialogBoxShowing Event, but it seems like the print options window isn't considered a Dialog Box in that sense. Any other ideas?

Thanks!

[jeremytammik]

Dear Harri,

Thank you for your interesting query.

That sounds like a challenging task you have set yourself, and good progress you have made already.

Regarding your suggestion 1., you can indeed redefine the behaviour of a built-in command. However, I think that you then lose access to the original implementation, and only have access to your own overriding behaviour, cf. replacing built-in commands and obtaining their ids:

https://thebuildingcoder.typepad.com/blog/2012/06/replacing-built-in-commands-and-their-ids.html

Ad 2. I am not aware of any way to Commit a Transaction without an entry in the user transaction history, except enclosing it in a transaction group. However, I see no way to include an existing built-in command (e.g., Print) with its own transaction handling inside a transaction group that you control.

Ad 3. You can of course use the Windows API to hook up with any dialogue you please and execute any code you please. I show how in my discussion on dismissing a dialogue using Windows API:

http://thebuildingcoder.typepad.com/blog/2009/10/dismiss-dialogue-using-windows-api.html

However, I don't see how you would gain access to a valid Revit API context in that scenario.

I hope this helps.

Best regards,

Jeremy