How to interrupt/cancel save process

Report · Jun 15, 2011

Hello,

Here is the situation : A user is working on an InDesign document with the plugin I develop. He clicks on the save button. At this moment, I would like to "catch" the save action to display a OK/Cancel dialog box. A click on OK will effectively save, while a Cancel click cancels the save action.

I have seen the signal system, but it only allows to be informed when a save is being to be processed. I did not see anything about canceling the save process. Is it possible ?

Thanks a lot.

Report · Jun 15, 2011

First you should ask yourself if there is really any need to do this. It could be considered very annoying by the user and there is a reason this is not the default behavior.

If you still decide to go forward, you would typically use a CommandInterceptor to intercept the save command. This is done by creating an implementation of ICommandInterceptor that checks the Command ID in the InterceptProcessCommand method and then returns kCmdNotHandled to complete the save command or kCmdHandled to cancel the save command. You would also need to use a startup service to install the CommandInterceptor on the CommandProcessor.

Keep in mind that messing with CommandInterceptor can be very dangerous, especially when you choose to cancel the command via kCmdHandled. It's easy to make mistakes that mess up the document state or crashes InDesign if you are not prepared for a cancellation of a command.

Report · Jun 16, 2011

[Note : I changed my account, I am the same user as xldperigee1. Sorry for inconvenience]

Dirk Becker wrote:

Search the SDK for IDocFileHandler.

To install, your document signal handler stores a classID of your implementation within kDocBoss[IID_ICLASSIDDATA], and from within you chain-call the boss/implementation that was previously stored there.

Dirk

I can't use signals because I really need to be able to interrupt the save process. Thank you for trying helping me

MTornros wrote:
First you should ask yourself if there is really any need to do this. It could be considered very annoying by the user and there is a reason this is not the default behavior.

I do not have really the choice. I am not a decision-maker. The plugin I develop interacts with another software that must be protected when an InDesign document is saved by checking some prerequisites.

Report · Jun 17, 2011

I'm meeting a last problem : In my interceptor, how could I "filter" the commands ? Currently, I intercept every commands. I didn't see any link between a command and an actionID. I tried to use an ActionFilter, but didn't manage to make it work. Did I code with my feet, or was it not the right way to do it ?

Suggestions would be appreciated.

Regards.

Report · Jun 17, 2011

Please re-read my post.

IDocFileHandler is the bottleneck between invocation (the menu actions, or scripts, etc.) and dialogs such as "Do you really want to save ..." .

If you want to modify that behaviour (introduce another check, or cause the whole activity to abort silently) you overload the method to your own implementation.

If you find the document is not managed by your system, or you aren't interested in the specific activity, or you've ruled out all your objections against the default behaviour, you forward the call to the initial, default implementation which then fires off commands or what else is to do.

To get all of this working, you have to install the boss class of your implementation per document (so that's another place where you can check whether you're at all responsible for the document). The best place to perform that installation is during open document / new document signals.

Dirk

Report · Jun 20, 2011

Dirk's solution works for me. Thanks to you.

For anyone who could meet the same problem, here is how I did :

I created a new DocFileHandler by implementing IDocFileHandler.

In your FactoryList, put REGISTER_PMINTERFACE(MyDocFileHandler, kMyDocFileHandlerImpl)
In your ID.h, put
- DECLARE_PMID(kInterfaceIDSpace, IID_MYDOCFILEHANDLER, ...) // IID_MYDOCFILEHANDLER is the kDefaultIID of your doc file handler
- DECLARE_PMID(kImplementationIDSpace, kMyDocFileHandlerImpl, ....)
In your Ext.fr, put :
Class
    {
        kDocHandlerBoss,
        kInvalidClass,
        {
            IID_IDOCFILEHANDLER, kMyDocFileHandlerImpl,
            IID_IORIGINDOCFILEHANDLER, kDocFileHandlerImpl,
        }
    }
This is the shadowing technique.
Then implement your DocFileHandler. To call the shadowed doc file handler, try this :
InterfacePtr<IDocFileHandler> originFileHandler (this, IID_IORIGINDOCFILEHANDLER);
originFileHandler->AMethod();

Report · Jun 20, 2011

You are getting closer. Just take into account that others may be using the same trick. Therefor don't make assumptions about the previous value of the ClassID or its underlying implementation (your hard wired use of kDocFileHandlerImpl). Instead, store the previous value of the class ID (e.g. within a private IID_IMYCLASSID on kDocBoss). When you need the original implementation, ::CreateObject with that stored boss class.

Btw, I hope I did not cause too much irritation with my choice of the word "install" in the previous posts. It was just meant to describe the step of reading and storing those class IDs in order to adopt a document.

Dirk

Report · Jun 21, 2011

Dirk Becker wrote:
Btw, I hope I did not cause too much irritation with my choice of the word "install" in the previous posts. It was just meant to describe the step of reading and storing those class IDs in order to adopt a document.

Don't worry about it. You helped me enough. I understood the "install" word when I saw other similar threads

For people needing it, here is the corrected solution :

In your FactoryList, put REGISTER_PMINTERFACE(MyDocFileHandler, kMyDocFileHandlerImpl)
In your ID.h, put
- DECLARE_PMID(kInterfaceIDSpace, IID_MYDOCFILEHANDLER, ...) // IID_MYDOCFILEHANDLER is the kDefaultIID of your doc file handler
- DECLARE_PMID(kImplementationIDSpace, kMyDocFileHandlerImpl, ....)
In your Ext.fr, put :
Class
    {
        kDocHandlerBoss,
        kInvalidClass,
        {
            IID_IDOCFILEHANDLER, kMyDocFileHandlerImpl,
        }
    },

AddIn
    {
        kDocBoss,
        kInvalidClass,
        {
            IID_IORIGINDOCFILEHANDLER, kDocFileHandlerImpl,
        }
    }
This is the shadowing technique.
Then implement your DocFileHandler. To call the shadowed doc file handler, try this :
InterfacePtr<IDocFileHandler> originFileHandler (<UIDRef of the document>, IID_IORIGINDOCFILEHANDLER);
originFileHandler->AMethod();

Report · Jun 15, 2011

Search the SDK for IDocFileHandler.

To install, your document signal handler stores a classID of your implementation within kDocBoss[IID_ICLASSIDDATA], and from within you chain-call the boss/implementation that was previously stored there.

Dirk