topic Re: ACAPI_Element_Change with libInd swap on IFC-imported door — does element GUID survive? in Archicad C++ API

ACAPI_Element_Change with libInd swap on IFC-imported door — does element GUID survive?

CritZer0 — Tue, 16 Jun 2026 19:20:46 GMT

We're working on an add-on that converts IFC-imported door and window elements into native parametric ArchiCAD library objects programmatically. I've been able to do this manually by setting up a door in the door tool that matches the correct size of the door, then injecting the properties into the neutral IFC door object that was merged into the PLN.

Our approach: call ACAPI_Element_Change on an IFC-imported door element, masking openingBase.libInd to a valid native library part index, then writing openingBase.width and openingBase.height. This appears to be what the UI's "Inject Element Settings" (Opt+Cmd+Click) does internally.

Three questions:

1. Does ACAPI_Element_Change with a libInd swap on an IFC-imported element preserve the element's ArchiCAD GUID — and therefore any attached custom properties?

2. Is this the correct programmatic equivalent of "Inject Element Settings," or is there a dedicated API path for this operation?

3. Are there known restrictions or side effects when calling ACAPI_Element_Change on IFC-imported elements specifically, versus native elements?

Further update with precise findings:

After `SwapLibraryPart` via `ACAPI_Element_Change`:

- The wall opening (wallhole polygon) retains original IFC dimensions and is not recut

- `ACAPI_Element_GetGDLParameters` fails entirely on the element

- The element appears to be in an intermediate state — geometry correct, but locked

The UI `Opt+Cmd+Click` "Inject Element Settings" resolves all three issues simultaneously.

Questions:

1. What is the programmatic equivalent of "Inject Element Settings" — specifically the call that switches an IFC-imported door from IFC-driven to GDL-driven mode?

2. Does this involve `ACAPI_Element_Change` with `API_DoorType` + `openingBase` mask, or a separate IFC detach call?

3. After the mode switch, does ArchiCAD automatically recalculate IFC attributes (`OverallWidth`/`OverallHeight`) from GDL parameters on export?

AC29, DevKit 29.3100. Thanks in advance.

Operating system used: Mac Apple Silicon Tahoe 26.5.1

Re: ACAPI_Element_Change with libInd swap on IFC-imported door — does element GUID survive?

CritZer0 — Tue, 16 Jun 2026 19:20:57 GMT

Final update — root cause identified:

IFC-imported doors have `ParameterTakesPrecedence = FALSE` and `Sizeable = FALSE` as IFC boolean attributes. These prevent GDL parameters from controlling dimensions or the wall opening.

Is there a C++ API call to set these two IFC boolean attributes programmatically on an imported door element?

Is it `ACAPI_Element_SetIFCAttribute` or part of the IFC Properties API?

Re: ACAPI_Element_Change with libInd swap on IFC-imported door — does element GUID survive?

Tamas Polyak — Thu, 18 Jun 2026 15:21:55 GMT

Hi,

I've entered it as a support issue, and asked a developer to look into it.

Regards,

Tamás

Re: ACAPI_Element_Change with libInd swap on IFC-imported door — does element GUID survive?

Tamas Polyak — Thu, 02 Jul 2026 15:12:55 GMT

Hi,

Here's the answer from the developer:

Does ACAPI_Element_Change with a libInd swap on an IFC-imported element preserve the element's ArchiCAD GUID — and therefore any attached custom properties?

In-place element change operations are expected to keep the element GUID, so GUID-bound data can remain attached.
However, GUID preservation alone does not guarantee a fully valid converted door/window state after a libInd-only swap on IFC-imported elements.

Is this the correct programmatic equivalent of "Inject Element Settings," or is there a dedicated API path for this operation?

No public one-call equivalent of Inject Element Settings is exposed in the DevKit.
There is no public API documented as "Inject Element Settings" for such a complex IFC-imported door/window conversion.
Practically, a libInd/openingBase-only update is not sufficient to reproduce the full UI result in all cases.

Are there known restrictions or side effects when calling ACAPI_Element_Change on IFC-imported elements specifically, versus native elements?

Yes. IFC-imported elements carry IFC-related state that is handled through IFC modules.
Public IFC APIs for element-side data are read/query oriented (ObjectAccessor, PropertyAccessor), while hook APIs are export-time augmentation.
Therefore, field-level model edits alone can leave IFC-imported elements in a partial state compared to native elements.

What is the programmatic equivalent of "Inject Element Settings" — specifically the call that switches an IFC-imported door from IFC-driven to GDL-driven mode?

There is no public API call that explicitly performs this mode switch.
Publicly supported workaround: - based on what the Inject Element Settings command actually does - is a complete element replacement workflow:
1. Snapshot IFC data from the imported element (ObjectAccessor + PropertyAccessor). - Example IFC_Test AddOn modification attached.
2. Replace with a native element using normal element APIs.
3. Preserve traceability and IFC data using export hooks where needed.

Does this involve ACAPI_Element_Change with API_DoorType + openingBase mask, or a separate IFC detach call?

Not a public separate IFC detach call.
Also not reliably solved by API_DoorType/openingBase mask alone for IFC-imported conversion semantics.

After the mode switch, does ArchiCAD automatically recalculate IFC attributes (OverallWidth/OverallHeight) from GDL parameters on export?

Export is derived from the resulting current element state and translator logic.
If conversion is complete and the native element state is consistent, exported dimensions are expected to follow that state.
If conversion leaves an intermediate state, exported IFC values may not match expectations.

Follow-up to your questions:

Is there a C++ API call to set these two IFC boolean attributes programmatically on an imported door element?

No public API in the DevKit provides direct in-model writing of these imported IFC runtime attributes.

Is it ACAPI_Element_SetIFCAttribute or part of the IFC Properties API?

ACAPI_Element_SetIFCAttribute is not a public DevKit API.
IFC Properties API in IFCInOutAPI is not a generic in-model setter for imported runtime IFC attributes.
Public IFCInOutAPI surface is mainly:
- read/query: ObjectAccessor, PropertyAccessor
- export-time hooks/builders: HookManager, PropertyBuilder

Practical recommendation (public-only)

Use a replacement-based workflow, not in-place IFC-runtime attribute toggling.
I've attached an IFC_Test example modification zip, which contains a public-API sketch function of the snapshot of the IFC data from the built element in Src\IFCAPI_Test.cpp:
- SketchPublicIfcReplacementWorkflow()
- It snapshots ObjectID/GlobalId/ExternalGlobalId, local attributes, local properties, and local classifications to JSON.
- I hope this helps during the first phase of such a production converter

Best regards,

Tamás

Re: ACAPI_Element_Change with libInd swap on IFC-imported door — does element GUID survive?

CritZer0 — Thu, 16 Jul 2026 17:54:52 GMT

Thank you, Tamás. This direction looks like it might help create a reliable workflow.

I don't see the ZIP file you mentioned. Where can I download that file?
Christopher