Error handling for unclassified elements

[Bruce]

Is there a way to test for an unclassified element in a Property Expression, and return an empty string instead of a #hashtag?  A similar Excel formula would be "=ISNA()"

E.g. we are concatenating our wall label from multiple properties to have one label that has (for example), the wall type, the fire rating, the acoustic rating etc.  One of these is "Wall Core", which is only available for the "Solid Wall" classification.  However, we also have labels attached to walls that are classified as "Partition Wall", which result in a #hashtag error.

As far as I can tell, if the Property isn't available, then the expression doesn't even run.

[runxel]

The solution is in your last sentence already.

You don't need to explicitly test for some classification. If the expression can't be evaluated (e.g. because one element does not have this property), it will be skipped. But please bear in mind: you can add as many expressions as wanted. AC will take the first applicable one. In this example if some element does not have "some property", it will just get a static "foo" applied. Cool, huh?

[Bruce]

Thanks runxel,

Although this would work for one, maybe two combined properties, we have five or six, with either an "N/A", or the value.  The end result would look something like:

WT1 | CRC1 | 30/30/30 | RW45 | R3.2

Where if any of those values were "N/A", they wouldn't appear in the final concatenated property.  It's a long CONCAT statement, with heaps of nested IF statements, e.g. IF(CORE TYPE = "N/A", "", (CONCAT CORE TYPE, "|")).

We could get around it with a proxy property to test, but this introduces new properties, and all properties create processing overhead which has significant impact on larger projects.

[runxel]

Okay I can see that this produces some overhead for larger concatenated properties.

I have the same thing going on for fire safety properties. But since I might need the parts for themself anyway I have them seperate. I really don't care, I was not able to see any performance drops so far with having a few more properties.

So a workaround for you would be to split your one big property into its constituting parts and having a "fallback". Could be e.g. a special character, which you then use to test for (instead of your "N/A").

[Bruce]

Yes, we do have our properties split out, as you've described.  "N/A" is our 'special' character...but if the property isn't in the classification, it can't produce even the special character to test for.  This is the problem we're running into.

This would be solved if we could test for a null value. e.g. ISNULL.

[Barry Kelly]

Have you tried empty quotes "".

This is a null string.

Barry.

[Bruce]

Good idea Barry.  Unfortunately, no, that didn't work.

[runxel]

Yeah you're right Bruce, sorry.

My suggestion doesn't help when the whole property is not available.

The other workaround still works. But I see it is cumbersome to generate all versions, especially when every one of the parts could be missing. This would like 5! (=120) versions? 😅

So yeah, valid wish.