Can we perform nested if-logic in computed fields?

[smccoy]

We are attempting to add some required functionality for our users and need to perform nested if-statements in computed fields. How do we do this?

Example that we cannot make work:

A short text field. Syntax indented/format to make the logic a bit more readable.:

(Type == "Program Requirement")

?

getFieldValue(ID, "Program Requirement Statement")

:

(

(Type == "Product Requirement")

?

getFieldValue(ID, "Product Requirement Statement")

:

getFieldValue(ID, "Synopsis")

)

It addition... I appears that computed short text field has inconsisent results when it refers to a long text field with rich content. Sometimes the <-- MKS HTML> tags are showing up and sometimes not. How do we fix this problem?

[smccoy]

Anyone? Do I need to escalate this into a case number?

[LLawton]

Regarding the first question, the syntax looks good to me, so I wonder what you mean by "we cannot make work". What results are you getting? Do your fields always have values, or you should use a few "isEmpty" in there? It seems you are getting results, since you're asking the second question, so my question is what kind of results and when?

About the second question, you might be able to clean that up with some string functions (locate, substring, etc.). I think it might be easier and faster to use a trigger though.

Personally, I would question the value of computing a short text field from a rich text field. I assume the rich text is of that type for a reason. If it has an embedded picture for instance, what would you get in short text?

I know I have more questions than answers, so yes, you may want to discuss that with PTC Support.

[smccoy]

Thank you for your reply.

In this example, we are getting blanks. We know about the short-text <-> long-text problem because we have gotten these if-checks to work in the simple cases.

We're pursuing this because this functionality (polymorphic behavior in object-oriented terms) is not available in the product. And the Out-Of-The-Box design approach for re-using fields in multiple item-types creates unacceptable problems for our process and users.

I can bring up the details with the Tech-Support staff. I thought I'd start here to see if a simple solution might be available.

[KaelLizak]

Hello Sean,

Please do open a case with Support.

With regards to copying/comparison between short and rich text fields: I examined this in 10.5, and found <!-- MKS HTML --> always showed up in the short text field that had copied the value of a rich text field. If you can find more information about when the <!-- MKS HTML --> prefix is missing, that might help us narrow down the cause of this inconsistency.