Prevent document close by close icon (X)

Report · Jun 04, 2007

Does anyone know how to prevent a document from being closed if the user clicks on the close icon ("X") on the upper right corner of the document window?

I've established a document signal responder and am receiving the "kBeforeCloseDocSignalResponderService" signal when the close icon is clicked but I've been unable to stop or cancel the close process at this point.

My plug-in manages the opening and closing of certain documents automatically for the user and I don't want the user to prematurely close a document this way. I'm able to disable the close menu item for these documents so they can't be closed that way but I haven't been able to prevent the close icon from closing them.

Any suggestions?

Report · Jun 05, 2007

Hi Bob,

What you need to do is implement your own IDocFileHandler implementation to handle the close.

A good example of this exists in the CS2 SDK here {SDKROOT}/source/sdksamples/incopyfileactions/

The example is for InCopy, but the techniques lend them self to InDesign too.

With this you should be able to achieve a slicker solution which doesn't involve disabling menus etc..

HTH

Mike.

Report · Jun 05, 2007

Thanks for the suggestion Mike. I tried it and it looks like a better solution for enabling/disabling the various file menu items (Close in my case).

But it didn't solve the problem with the Close icon (X) on the upper right corner of the document window. When this is clicked there is not a call to the IDocFileHandler.CanClose() command. It goes straight to the IDocFileHandler.Close() command. Since I implemented it using a shadow interface so I could still call the default functions when I didn't want to override them I thought I would try commenting out the Close() call for the default interface as a test. The document still closed.

Thus I am still unable to prevent the close via the Close icon (X) button.

Bob

Report · Jun 06, 2007

Hi Bob,

The bit you are missing is the following

ErrorUtils::PMSetGlobalErrorCode( kCancel );

Use this to prevent the close from happening.

Mike.

Report · Jun 08, 2007

That was the piece that I was missing. I got it working now.

Thanks for your help, Mike.

Bob

Report · Nov 16, 2009

Hi

I try to implement the thing described inthis discussion, but it doesn't work.

I implement my own DocFileHandler and my own DocUtils like in the sample incopyfileactions. But my method CanClose is never called.

In my fr-file I do the following:

...

    Class
    {
        kTabFlowDocFileHandlerBoss,
        kInvalidClass,
        {
            IID_IDOCFILEHANDLER, kTabFlowDocFileHandlerImpl,
        }

    }

    AddIn
    {
        kUtilsBoss,
        kInvalidClass,
        {
            IID_IDOCUMENTUTILS, kTabFlowDocUtilsImpl,
        }
    };

...

But the AddIn doesn't work. There is a message Plug-in conflict: 2 plug-ins installing same interface!".

What is wrong??? Any ideas?

Thanks

Hans

Report · Nov 16, 2009

As a rule of thumb, never AddIn an InDesign IID to an InDesign Boss.

Use your own IID instead of IID_IDOCUMENTUTILS.

Dirk

Report · Nov 16, 2009

Hi Dirk

Thats right, yes. I never do that usually... I saw this only in the sample....

Do you have an idea why my DocFileHandler isn't called? I know, you don't see my implementation, but maybe you have an idea...

I think the Interface for my DocFileHandler is called via QueryDocFileHandler in my implementation ofDocUtils. But this method is never called. I suppose because the method ofthe original implementation IDOCUMENTUTILS is valled of course. And I don't know how to change that. If I AddIn it with my own ID it is not called anyway. Can I replace an existing interface???

Thanks

Hans

Report · Nov 16, 2009

How do you activate your DocFileHandler?

You're supposed to do this:

In your new document responder, get the kDocBoss.

On that boss, copy the old value from IID_ICLASSIDDATA into your private IID_MY_CHAINED_CLASSIDDATA. Use an ImplementationAlias.

Then install your kTabFlowDocFileHandlerBoss into the original IID_ICLASSIDDATA. Only then your handler may be called.

In your implementation of IID_IDOCFILEHANDLER, CreateObject(originalClassID) and chain-call the previous IID_IDOCFILEHANDLER.

Finally, hope that all other plugin developers apply the same chaining, rather than CreateObject() InDesign's original handler boss.

Dirk

Report · Nov 16, 2009

Hi

install my handler in my responder in the method Respond:

...

InterfacePtr<IClassIDData> ipDocFileHandlerData(uidRefDoc, IID_ICLASSIDDATA);
   if (ipDocFileHandlerData != nil) {
     ipDocFileHandlerData->Set(kTabFlowDocFileHandlerBoss);
   }

...

But for what do I need the ImplementAlias?

Do you have a short code sample?

Thanks

Hans

Report · Nov 16, 2009

You need to store the previous handler (probably a kDocFileHandlerBoss), and call it later on so it does the actual work for you. Besides other plugins also need their chance to see and reject the same notifications.

If you still don't arrive at your handler, please verify from somewhere (menu?) later on, that nobody else has replaced your docFileHandler in that ClassIDData. Hmm, could even be the original kDocFileHandlerBoss if it also is installed by a responder ...

Forget my comment about ImplementationAlias, that ClassIDData is not persistent. It's been definitely too long that I did anything with a DocFileHandler.

Dirk

Report · Nov 17, 2009

Hi Dirk

Thanks for your answers and hints.

But I can't solve the problem, I don't see the solution actually...

What I need is to detect the closing of a document via close icon or the close menu BEFORE the message kBeforeCloseDocSignalResponderService is thrown, before the window is closed. I think this is if the Close-method of IDocumentUtils is called. But this method isn't called in my plugin. I don't know why.

I install my DocFileHandler during DocOpen, but something doesn't work correct. I will search for the solution, but actually I am confused...

Thanks again

Hans