IFCAPI::PropertyAccessor::GetAttributes issue in custom add‑on

[larsr]

Hello!

Does the new IFCAPI have any prerequisites that need to be set in order to be used? The code provided below, if added to the example project IFC_Test, will print:

TestApi(): 1
TestApi(): 2
TestApi(): 3
Number of attributes: 6
Attribute Name0: GlobalId
Attribute Name0: Name
Attribute Name0: Tag
Attribute Name0: PredefinedType

However, the same code in my add‑on returns 0 attributes:

TestApi(): 1
TestApi(): 2
TestApi(): 3
Number of attributes: 0

Archicad version: 29.2.0 (5003)
SDK version: WIN.29.3100

Test function:

void TestApi()
{
	GS::Array<API_Neig> aSelection;
	API_SelectionInfo rSelectionInfo = {};
	ACAPI_Selection_Get(&rSelectionInfo, &aSelection, false);
	for (auto& rNeig : aSelection)
	{
		API_Elem_Head head{};
		head.guid = rNeig.guid;
		auto objectID = IFCAPI::GetObjectAccessor().CreateElementObjectID(head);
		//
		DBPrintf("TestApi(): 1\n");
		if (objectID.IsErr())
		{
			ACAPI_WriteReport("TestApi(): CreateElementObjectID failed for element ", true);
			return;
		}
		//
		IFCAPI::PropertyAccessor propertyAccessor = IFCAPI::PropertyAccessor(objectID.Unwrap());
		auto properties = propertyAccessor.GetAttributes();
		if (properties.IsErr())
		{
			ACAPI_WriteReport("TestApi(): GetAttributes failed for element", true);
			return;
		}
		DBPrintf("TestApi(): 2\n");
		//
		auto oIfcAttributes = properties.Unwrap();
		DBPrintf("TestApi(): 3\n");
		DBPrintf("Number of attributes: %zu\n", oIfcAttributes.size());
		//
		for (auto& rIfcAttribute : oIfcAttributes)
		{
			if (rIfcAttribute.GetName().IsEmpty()) continue;
			//
			if (!rIfcAttribute.GetValue().has_value()) continue;
			//
			DBPrintf("Attribute Name0: %s\n", rIfcAttribute.GetName().ToCStr().Get());
		}
	}
}

Operating system used: Windows 11 25H2

[Tamas Polyak]

Hi,

I've asked the developer for support.

Regards,

Tamás

[Tamas Polyak]

Hi,

Here below is the answer from the developer.

Best regards,

Tamás

Based on the APIDevKit 29 sample and headers, the IFCAPI does not appear to require any special explicit initialization in the add-on before use. The IFC_Test example only uses normal add-on registration/initialization, then calls IFCAPI directly.

The main documented prerequisite is that the IFC In-Out module must be available, in which case missing support should normally come back as an error such as APIERR_MODULNOTINSTALLED, not as a separate init failure. Since CreateElementObjectID succeeds in the user’s case, this looks less like a missing IFC module and more like either a context/build difference between IFC_Test and the user’s add-on, or rather a difference in the selected element / active database at the time of the call.

I would suggest checking:

1. Whether the add-on is built and linked the same way as IFC_Test, including IFC-related module libraries.

2. Whether the code is executed from the same kind of context as the sample, for example: same view, same selection, same form of menu commands.

3. The exact results of GetIFCType and GetGlobalId for the same ObjectID, and the exact error/status of GetAttributes if available.

So at this point I would not expect a hidden “enable IFCAPI first” step, but rather a runtime context or project setup difference between the sample add-on and the custom add-on.