Writing GDL AddPar values (e.g. material override) to Railing sub-elements (Post/Rail/Panel/etc.) —

[Mathias Jonathan]

Hi,

I'm trying to programmatically change GDL library-part parameters (e.g. bOverridePostSurface / matPost) on Railing sub-elements — Posts, Rails, Panels, etc. — identified by their own GUID (obtained via ACAPI_Element_GetMemo_ExternalHierarchical / the equivalent subelement enumeration).

Reading works fine: ACAPI_Element_GetMemo(subElemGuid, &memo, APIMemoMask_AddPars) correctly returns the full AddPar list for a sub-element (e.g. 111 parameters for a Post, including bOverridePostSurface/matPost).

Writing does not work, and I've been unable to find a supported path. What I've tried, each rejected cleanly (no crash, but no success):

1. ACAPI_LibraryPart_OpenParameters (session-based) on the sub-element — fails outright; can't get a session open for this element type.
2. ACAPI_Element_Change(&element, &mask, &memo, APIMemoMask_AddPars, true) directly on the sub-element's own guid — APIERR_BADPARS. (Tried both an empty mask and ACAPI_ELEMENT_MASK_SETFULL.)
3. ACAPI_Element_ChangeParameters(elemGuids, &element, &memo, &mask) — APIERR_BADID.
4. ACAPI_Element_ChangeExt using API_SubElement with subType = APISubElement_RailingPost, called on the owning top-level Railing element — APIERR_BADID, tried both with the sub-element's real GUID set and with the fully-populated API_Element copied into subElem, indices left at subIndex = subSubIndex = 0. Same rejection both times.
5.  

I noticed API_SubElementType defines APISubElement_RailingPost, RailingRail, etc., and API_SubElement::subIndex/subSubIndex's field docs specifically mention Railing — but API_SubElement's own class-level description only lists Window/Door/Section/Elevation/InteriorElevation/ChangeMarker/CurtainWall as the element types supported by ACAPI_Element_GetDefaultsExt/ChangeDefaultsExt/CreateExt/ChangeExt. Railing isn't mentioned there, which would explain the consistent APIERR_BADID.

I also confirmed there's no structural path through the parent: none of API_RailingPostType/API_RailingNodeType/API_RailingSegmentType/etc. carry a params/AddPar handle anywhere in the struct tree, so there's nothing to modify even via the parent Railing's own memo.

My question: is writing AddPar values to a Railing sub-element currently supported by the public API at all, through any function? If ACAPI_Element_ChangeExt is meant to support it, what are the correct semantics for subIndex/subSubIndex for APISubElement_RailingPost specifically (segment index? node index? position within a pattern?), and does subElem's GUID matter at all, or is addressing purely index-based?

Thanks!

Operating system used: Windows

[Tamas Polyak]

Hi Mathias,

I've opened a support issue about your question.

Regards,

Tamás

[Tamas Polyak]

Hi Mathias,

I've got an answer from the developer, please find it below.

Regards,

Tamás

Does this workflow work, or? If not, which point fails?

1. Obtain the editable Post/Rail/Panel sub-element GUID from the owner railing memo.

2. Call ACAPI_Element_Get using that sub-element GUID.

3. Call ACAPI_Element_GetMemo(guid, &memo, APIMemoMask_AddPars).

4. Modify memo.params

   1. bOverridePostSurface: Boolean stored in value.real

   2. matPost: Material stored in value.real

5. Call

   ACAPI_Element_Change (     &element,     nullptr,     &memo,     APIMemoMask_AddPars,     true );

6. Check the result and dispose the memo.

[Mathias Jonathan]

Thanks for the workflow. Tested it exactly as described on Archicad 29, here's precisely where it fails:

Steps 1–4 all work correctly:

1. Sub-element GUID obtained via subelement enumeration on the owner Railing — works.
2. ACAPI_Element_Get on that GUID — succeeds (returns a valid API_Element with header.typeID == API_RailingPostID).
3. ACAPI_Element_GetMemo(guid, &memo, APIMemoMask_AddPars) — succeeds, returns all 111 AddPars including bOverridePostSurface and matPost.
4. Modifying memo.params in place (setting bOverridePostSurface and matPost via their value.real/boolean fields) — no issue, values are correctly written into the handle before the change call.

Step 5 is where it fails:

ACAPI_Element_Change(&element, nullptr, &memo, APIMemoMask_AddPars, true);

Returns APIERR_BADPARS every time, regardless of the mask argument — I tested nullptr, an empty (ACAPI_ELEMENT_MASK_CLEAR) mask, and a fully-set (ACAPI_ELEMENT_MASK_SETFULL) mask, all three give the identical APIERR_BADPARS. This is the exact same error I got in my original attempt before asking on the forum, so this suggested workflow doesn't change the outcome for me on Archicad 29.

Is ACAPI_Element_Change with a memo/memoMask genuinely expected to work directly on a Railing sub-element's own GUID (bypassing the owning Railing entirely), or does writing AddPars for Railing sub-elements actually require going through the owner via ACAPI_Element_ChangeExt/API_SubElement after all — and if so, what are the correct subIndex/subSubIndex semantics for APISubElement_RailingPost specifically? That path also returned APIERR_BADID in my testing, so if the fix requires it, some detail is still missing on my end (guid vs index addressing, subElem contents, etc.).