CS4 Crashes when attempting to change color of characters in story

Hi Dirk,

That seems to fit with what I'm seeing and it's a fair comment that protective shutdown is obviously something which InDesign traps and reacts to.

that might be okay from the point of view of an InDesign application developer.

From the point of view of a plugin developer, it doesn't make an awful lot of difference.

If I try to get into the Debugger it crashes anyway, so it's all the same.

A message along the lines of "Protective Shutdown - Executing command with outstanding error condition"

would be a lot more helpful. I seem to remember seeing something like that in CS2.

Is that the only reason for a protective shutdown?

Is there an easy way of tracing calls to set PMGlobalErrorCode?

Seems to me that it would make a lot of sense to use a version of CmdUtils::ProcessCommand which checks for the global error code before the command is executed? that would save an awful lot of pain.

Thanks for the comments, it's shown a good way to go.

Caerwyn

Hi Rick,

I am facing a similar problem, while added color to Underline Options in Character style.

Using following code to access color swatch:

InterfacePtr<ISwatchList> swatchList(iWorkspace, UseDefaultIID());

ASSERT_BREAK(swatchList == nil, "INDCDocUtils::ResolveRGBColorSwatch swatchList is nil");

PMString name("C=0 M=100 Y=0 K=0");

UIDRef magentaUIDRef = swatchList->FindSwatch(name);

if (magentaUIDRef != nil)

{

ALERT(name);

colorUID = magentaUIDRef.GetUID();

break;

}

InterfacePtr<ITextAttrUID> textAttrUnderlineColor(::CreateObject2<ITextAttrUID>(kTextAttrCharUnderlineColorBoss));

ASSERT_BREAK(textAttrUnderlineColor == nil, "INDCDocUtils::ApplyHilightAsLocalOverride textAttrUnderlineColor is nil");

textAttrUnderlineColor->SetUIDData(colorUID);

I am able to apply above text attribute successfully. BUT InDesign Crashes when closing the document.

Please help!!

Hi Rick,

I've just been chasing a crash in the Debug version of CS4 InDsign which was asserting with Protective shutdown.

Like you the manifestation was on a call to ProcessCommand.

I don't know if it's the same, but on the off chance I'll detail what I discovered.

I traced back the cause of the crash to an earlier call through our ASB-CSB using the function template and macros, Process and make_functor.

The function template Process which is in the SelectionASBTemplates.tpp sets up a abortable command sequence on the stack.

If the result from the CSB function wasn't kSuccess then the sequence was aborted.

Unfortunately in our CS2 version of the ASB/CSB's we were rather naughtily using the return to pass  a value and not an ErrorCode.

the result was that our call was forcing an abort everytime.

I've duplicated and renamed the Process function at the top of our ASB code and missed out the command sequence and it works fine.

This isn't really the best solution and I'll have to investigate further but at least it solves the crash.

Below is the new version of Process. I hope it helps you (or someone else out).

All the best

Caerwyn  Pearce

#if (CREATIVE_SUITE_VERSION == CS2)
// Use standard function template from SelectionASBTemplates.tpp for CS2.
// It doesn't seem to cause problems, and I'd prefer not to fix it if it's working.
#define ATLASB_Process        Process
#else
//________________________________________________________________________________________________
//    DESCR:        Call each CSB suite to process the request, wrapping the entire call in a sequence.
//                Compare this with the one in SelectionASBTemplates.tpp.   
//                Essentially I've removed the command sequence, and the possibility of an abort.
//                For some reason this was causing a Protective shutdown in CS4.
//                Also note the abort takes place if the return value from Process is not kSuccess(aka 0).
//                For GetSelection we are returning ATLCSB::SelectionType which has a value of -1, -2 or -3
//                which is most definitely not kSuccess and which was provoking an abort.
//                However that's not the end of the problem, and the line ErrorUtils::PMSetGlobalErrorCode
//                seems to be causing problems else where outside of the Process function template.
//                It may be that our code is not resilient to aborting command sequences.
//
//    NOTE:        Most definitely doesn't abort the sequence regardless of errors.
//   
//    RETURNS:    Error Code.
//________________________________________________________________________________________________
template <typename Functor>
typename Functor::result_type ATLASB_Process (Functor& f, typename Functor::argument_type object, PMIID iid)
{
    InterfacePtr<const IIntegratorTarget>                     iIntegratorTarget (object, UseDefaultIID ());
    std::auto_ptr<IIntegratorTarget::TargetSuiteCollection> selectionSuites (iIntegratorTarget->GetTarget (iid));
    ErrorCode                                                errorCode = kSuccess;

    if (!selectionSuites->empty())
    {
        for (int32 i = selectionSuites->size () - 1; i >= 0 && errorCode == kSuccess; i--)
        {
            typename Functor::argument_type        iUnknown = static_cast<typename Functor::argument_type>(static_cast<IPMUnknown*>((*selectionSuites) ));
            errorCode = f(iUnknown);
        }
    }

    return (errorCode);
}

template <typename Functor>
typename Functor::result_type ATLASB_Process (Functor& f, typename Functor::argument_type object)
{
    return (ATLASB_Process (f, object, GetDefaultIID (object)));
}
#endif