topic Re: API_IFCProperty missing deprecation mark | Alternative for AC29 in Archicad C++ API

API_IFCProperty missing deprecation mark | Alternative for AC29

Emkave — Fri, 22 Aug 2025 18:55:17 GMT

Hello guys. I was looking around the new Archicad API for AC29 and I noticed that they have removed API_IFCProperty for some reason. I checked the older API for AC28 and I found out that API_IFCProperty is not marked as deprecated or to be deleted in the future versions. Who can explain this weird discrepancy and what can I use instead of API_IFCProperty for AC29?

Re: API_IFCProperty missing deprecation mark | Alternative for AC29

Hiromichi Shinkawa — Thu, 21 Aug 2025 08:37:05 GMT

Hi, I'd like suggest you to check the following documentation for the changes. Also, you can check the example code (IFC_Test) in API29.

Archicad 29 C++ API: New API features in Archicad 29

HTH.

Re: API_IFCProperty missing deprecation mark | Alternative for AC29

petrvokoun — Wed, 22 Apr 2026 13:52:42 GMT

We tested several approaches with our bimproject.cloud plugin in past 3 months.

If I understand it correctly, the old ACAPI_Element_GetIFCxxx set of calls were refering to the only existing "IFC storage" which is internal, user's. This worked until AC28 included. The new IFCAPI if referring to new "API-created" storage, which we had to create for this purpose.

Lets say we create IFCProperty1 and IFCProperty2 with our plugin:

- both properties are not transferred with the injection tool

- if user changes value of IFCProperty1, it becomes the internal property:

-- we cannot edit it with plugin anymore

-- when user uses injection tool now, he gets only IFCProperty1 in the new element - the one he changed

so he basically has 2 different properties in his element shown, but they look similar and he cannot distinguish between them visually

Therefore we would have to tell the user: dont touch IFC properties we created by plugin + if you want them in another element instance, insert them again

This is also crippling the Undoable actions, because our own storage is isolated and not tracked

The question is - do you guys know about it? Is it a bug or a purpose? What should we tell the users, that it will be fixed or they should work differently or that IFC Properties are deprecated in API in AC29 so they must use Classifications & Properties?

Re: API_IFCProperty missing deprecation mark | Alternative for AC29

Tamas Polyak — Tue, 12 May 2026 08:14:47 GMT

Hi,

I've consulted with the developer:

"Hi

Here is a summary about how all this works here, also you can check the IFC Hooks test addon in the DevKit Archicad C++ API

With the new IFC APi you don’t “create” IFC data anymore, just set up some mapping to IFC properties from data existing somewhere else in Archicad natively - like AC properties, classifications, etc.
You can set up a mapping in the IFC translator as before, or use the API to do a more complex one from code.

If the mapping is set up from some data in general, using the injection tool or even undoable actions shall no longer be necessary for IFC, the mapping shall apply to all elements runtime (even locked/hotlinked ones), you don’t have to copy them.

Manual IFC data editing on elements is a legacy thing, which users can do to work some limitations around, but ideally won’t have to.
I’d suggest using Archicad properties for the source data, as they work with element copy and the injection tool, and can be a single source of truth.

Until Archicad27 IFC properties were an “extra storage” besides Archicad's similar features, which meant you had to maintain two different sets of properties.
Our goal here is to make sure IFC data calculation is as automated as possible with general rules, not something for the user to to manually tweak on an element level.

All this requires a different approach to IFC property handling now."

Regards,

Tamás

Re: API_IFCProperty missing deprecation mark | Alternative for AC29

petrvokoun — Wed, 13 May 2026 13:47:41 GMT

Thank you for the information, Tamas. It makes sense like described so we will review the data workflows accordingly.

BR,

Petr