ACAPI_Element_GetIFCPropertyValuePrimitiveType() deleted from AC28 C++ API

[Bitwreckage]

In updating our code base to support ArchiCAD 28, it turns out that we are using ACAPI_Element_GetIFCPropertyValuePrimitiveType(GS::UniString&, API_IFCPropertyValuePrimitiveType*) in one place.
The only mention I could find in the documentation about this disappearance was on the "New API features in Archicad 28" page, saying "ACAPI_Element_GetIFCPropertyValuePrimitiveType function has been deleted."

So, on the positive side both my compiler and the documentation is in agreement.

Is there anything I can do to retrieve the same information that we previously did through this function?

--

Kind regards

Steffen Skov

dRofus

[Adam Toth · Accepted solution]

Hello

The function was discontinued, as it should not really be necessary and it's functionality was based purely on the IFC schema.

The implementation was just a switch statement though for the subtypes of IfcValue;
More specifically the IfcSimpleValue, IfcMeasureValue and IfcDerivedMeasureValue type descendants.

If you check any of them, they tell their primitive type, like "Type: REAL"
It will always be one of the simple data types seen here: https://en.wikipedia.org/wiki/EXPRESS_(data_modeling_language)#Datatypes

Hope this helps
Regards, Ádám

[Bitwreckage]

Thank you Adam for your quick reply!

I implemented our own mapping from the `GS::UniString` representation of an IFC Type to `API_IFCPropertyValuePrimitiveType` with the help of the IFC documentation.
While doing this I came across a few types, which I could not figure out how to represent as an `API_IFCPropertyValuePrimitiveType`, e.g. "IfcBinary", "IfcComplexNumber" and "IfcCompoundPlaneAngleMeasure". Can these particular IFC types be represented in Archicad, or is there generally a collection of IFC types which are not "supported"?

Also, while the IFC reference mostly said that the underlying type of an IFC type would be an integer, a string or a real, a couple of types ("IfcNumericMeasure" and "IfcCountMeasure") are documented as being of type "number". Do you have any idea how to interpret that? I am leaning toward `API_IFCPropertyAnyValueIntegerType` but I cannot be sure.

-- 
Kind regards

Steffen Skov
dRofus

[Adam Toth]

Hi

IfcBinary is as string (of 1s and 0s), but I have not seen such a value yet - looks like even the old API function didn't handle it correctly.

IfcComplexNumber and IfcCompoundPlaneAngleMeasure could contain multiple atomic values in theory.
We generally don't support them now in the IFC addon.

I think you can "skip" these two, they're the ones I know we deliberately don't handle.

The "number" type is like "real", works as a double value.
"Count" would one make quickly think, it's an integer, but you can have two and a half apples, so... 🙂

[Bitwreckage]

Hi again Ádám, 

I have been testing my implementation with an IFC property of type IfcCountMeasure, i.e. one of the "number" types as described here: https://standards.buildingsmart.org/IFC/DEV/IFC4_2/FINAL/HTML/schema/ifcmeasureresource/lexical/ifcc...

To my confusion my call to `ACAPI_Element_SetIFCProperty()` (which is still available, but deprecated) succeeded, but yet set the IFC property value to 0.

After much trial and error I finally figured that I would boldly map the "IfcCountMeasure" type to `API_IFCPropertyAnyValueIntegerType` instead of `API_IFCPropertyAnyValueRealType`, contrary to your suggestion.
Lo and behold! The value is now set correctly!

So it seems that, at least for "IfcCountMeasure", the correct type is an `API_IFCPropertyAnyValueIntegerType`.
Just a little heads-up for anyone else following this thread.

Now I should begin to think about how I can migrate from using `ACAPI_Element_SetIFCProperty()` to using `RegisterPropertyHook()`...

-- 

Kind regards

Steffen Skov
dRofus

[Adam Toth]

Hi

Thanks for the info, we'll look into it then, sounds like a bug, which may still be present somewhere.

I'll await your feedback with the hook version.

The concept is that the addon doesn't store/sync data into the element on the push of a button, we'd like to dial that down.
The addon only provides the data in a callback, every time when it's queried by the IFC UI or the IFC export.

So it's a dynamic connection, which is not limited by TW and doesn't pollute the plan with core IFC data, requires a different feature approach though.

[Bitwreckage]

I did not really think of it as a bug, but as you mentioned it, I can agree that the behavior of `ACAPI_Element_SetIFCProperty()`, when specifying a wrong data type, should probably not result in a `NoError` return value. But I guess, as this method is already deprecated, there is maybe not a huge point in fixing this detail.

W.r.t. the hook approach, thank you for outlining the concept - it aligns well with my immediate thoughts around it: we need to approach this part of our add-on in a somewhat different way.

-- 

Kind regards

Steffen Skov
dRofus