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
2 Replies 2
Tamas Polyak
Graphisoft
Graphisoft

Hi Mathias,

I've opened a support issue about your question.

 

Regards,

Tamás

Tamas Polyak
Graphisoft
Graphisoft

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.

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!