Copy link to clipboard
Copied
I am trying to create Indesign(indd) file programtically. This has lot of graphics, after writting some vector graphics I am getting following warnning always for each next processing
Warning: object 'kCommandProcessorBoss' has a really high ref count
Is there any way to reset this ref count?
OR any other option to get rid of this warning
Thanks
Chetan
Copy link to clipboard
Copied
Read about the basics of reference counters, difference of AddRef/Release, Get* vs. Query* methods.
Then examine your code where it accesses that boss, it is likely using a pointer variable where it should use an InterfacePtr.
Copy link to clipboard
Copied
You are leaking object reference in most probability. Follow Dirk's advice, also it would be beneficial to use debug version of InDesign it gives a report on the memory leaks in terms of interface and boss leaks that helps in debugging such issues.
-Manan
Copy link to clipboard
Copied
Hmm, that error message, mentioning a boss class, already sounds like an assert from the debug build.
Copy link to clipboard
Copied
Thanks Dirk, Manan
Here is part of code where I am using command, there are other places also where I call ProcessCommand but most of the code is similar, can you please tell me if anything wrong I am doing here
ErrorCode MyClass::ApplySplineAttributes()
{
ErrorCode status = kFailure;
do {
ASSERT(fIApplyMultAttributesCmdData);
if (!fIApplyMultAttributesCmdData) {
break;
}
InterfacePtr<ICommand> gfxApplyMultAttributesCmd(fIApplyMultAttributesCmdData, UseDefaultIID());
ASSERT(gfxApplyMultAttributesCmd);
if (!gfxApplyMultAttributesCmd) {
break;
}
gfxApplyMultAttributesCmd->SetItemList( UIDList(fSplineUIDRef));
status = CmdUtils::ProcessCommand(gfxApplyMultAttributesCmd);
ASSERT_MSG(status == kSuccess, "kGfxApplyMultAttributesCmdBoss failed");
if (status != kSuccess) {
break;
}
} while(false);
fIApplyMultAttributesCmdData.reset(nil);
return status;
}
Copy link to clipboard
Copied
This does not show how you initialize your fIApplyMultAttributesCmdData InterfacePtr. I'd usually keep CreateCommand and ProcessCommand in one method, but in some scenarios (multiple attribute changes in one command combined) it actually makes sense.
Assuming (as in: I don't know without further look) that the cmd boss holds a reference to kCommandProcessorBoss somewhere in the base implementation. Otherwise, kCommandProcessorBoss is a different beast.
Before you dive in too deeply, make sure you have ITK symbols installed and watch out from within the assert, maybe you can identify the overflowing counter from the debugger and set a watchpoint.
Copy link to clipboard
Copied
To me this method looks fine. I suspect fIApplyMultAttributesCmdData, the way it is being created should hold the key to this problem. My guess would be that it's ref count is being increased somewhere in the code which might not be very obvious hence causing the leak
-Manan
Copy link to clipboard
Copied
Thanks Manan,
This is the function of same class where I am creating fIApplyMultAttributesCmdData
void MyClass::AddAnAttribute(IPMUnknown* attribute)
{
do {
if (fIApplyMultAttributesCmdData == nil) {
// Create a command that can change graphic attributes.
InterfacePtr<ICommand> gfxApplyMultAttributesCmd(CmdUtils::CreateCommand(kGfxApplyMultAttributesCmdBoss));
ASSERT(gfxApplyMultAttributesCmd);
if (!gfxApplyMultAttributesCmd) {
break;
}
InterfacePtr<IApplyMultAttributesCmdData> applyMultAttributesCmdData(gfxApplyMultAttributesCmd, UseDefaultIID());
ASSERT(applyMultAttributesCmdData);
if (!applyMultAttributesCmdData) {
break;
}
fIApplyMultAttributesCmdData = applyMultAttributesCmdData;
}
fIApplyMultAttributesCmdData->AddAnAttribute(attribute);
} while(false);
}
Copy link to clipboard
Copied
This also looks ok. But then, it is not directly dealing with a kCommandProcessorBoss.
Do you maybe have any unbalanced command sequences around? IMO this pseudo-goto error handling style of the SDK samples (the do-break-while-false loops) is asking for such trouble, even more than a honest goto, that must be among the most controverse code style policies at Adobe. In my code they would not even see the first compile. But then, we're still poking around in the dark so it could be anything else including a different plug-in.
As mentioned above I'd pursue this from a debugger. Maybe start from the assert, locate the counter variable using ITK symbols or wild guess from assembly code voodoo, watchpoint on it and see where the references pile up.
Copy link to clipboard
Copied
I see this code is almost the same as the SDK sample it is referring to. Assuming that the SDK sample does not have any issues, I suggest focussing on the part that you have changed from the SDK. That should hold the key and be faster in terms of getting near the code that is the culprit. All that Dirk mentioned is very sound advice, add that to what I suggested, and you should have a plan of action.
-Manan