cancel
Showing results for 
Search instead for 
Did you mean: 
EN
cancel
Showing results for 
Search instead for 
Did you mean: 

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

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

Archicad 27 - GDL - PYTHON
0 Replies 0

Didn't find the answer?

Check other topics in this Forum

Back to Forum

Read the latest accepted solutions!

Accepted Solutions

Start a new conversation!