Plugin - refresh document state after InvokeMenuAction()

[Saniel]

Hello, I am working on plugin and I would like to change document color mode in code from RGB to CMYK.

Since

sAIDocument->SetDocumentColorModel(kDocCMYKColor);

only changes the document flag, but does not do the actual conversion, I though the easiest way to do proper conversion was to invoke the already present functionality, as if the user changed the color mode manually:

AICommandID to_cmyk_id;
sAICommandManager->GetCommandIDFromName(kDocColorCmykCommandStr, &to_cmyk_id);
sAIMenu->InvokeMenuAction(to_cmyk_id);

 This does exactly what I want, it changes the color mode to CMYK with proper conversion. It however breaks the document state inside the plugin.

For example, even the following simple call to get document fails, if the InvokeMenuAction codeblock is executed before it.

AIDocumentHandle doc = nullptr;
sAIDocument->GetDocument(&doc);

Is it possible to refresh the state inside the plugin after InvokeMenuAction()? Any help would be greatly appreciated!

[A. Patterson]

Are you using the ApplicationContext object from the SDK? If not, I'm wondering if that's all it would take to fix this. If you're not familliar with it, reply and I'll explain how to use it. 

If you are using it already, I'm not sure how to solve this. I don't know if we've ever used InvokeMenuAction() but I don't see why it would break the document state. Its funny to me that it doesn't automatically convert the colours because if you're a CMYK document and you set an RGB colour on an object, I think it automatically converts it without even informing you. I know there was some automatic conversion of some kind (its been a few years since I had my hands deep in AI development).

[Saniel]

Thanks for the reply. No, I am not using ApplicationContext object. I am still quite new to the SDK, If you could explain it that would be great.

[A. Patterson · Accepted solution]

OK, it's a bit of a funny thing to explain. Basically, the SDK can get 'de-synched', for lack of a better term, from your plugin in some situations. A good example is that we use the Qt UI library for our dialogs. If we show one of our dialogs, then attempt to call into the SDK, we'll get wierd results like what you're talking about. GetDocument() will fail when it clearly should work, etc.

The way to solve those problems is to create an application context. We have a dinky little class that basically just calls sAIContext->PushAppContext() in its constructor, and sAIContext->PopAppContext() in its destructor. So I can write code like:

void my_function()
{
   CApplicationContext context;

   sAIDocument->GetDocument();
   ...
} 

If you do that in my example with Qt above, everything works fine. I'm not 100% sure what a context is, but this  is necessary sometimes. If I every see wierd things like SDK functions telling me there's not current document when there obviously is, the first thing I try is adding a context.

It's okay to have multiple contexts at the same time, so long as they pop when they're done. That's why I use an object like the one described above -- it avoids headaches with exceptions, etc. AIContext.h is where you can find the suite and there are a couple of other neat things it provides as well (e.g. "while this context is active, treat all layers as unlocked or visible"). There's actually an AppContext class in the sample code (look in the common folder) that does something similar to what I wrote. I'm not sure why that wasn't added to their list of utilitiy classes in the illustratorapi folder, it honestly should be.

[Saniel]

This solved the issue! Thanks for taking your time to help me out

[A. Patterson]

No problem. As I said, anytime I get a wierd SDK result, I throw a app context at it first to see if that makes it go away lol