Support Forum

[PythonParts] Attaching attribute to wall openings not behaving as expected

Schlagworte:
  • PythonParts
  • Walls
  • Openings
  • Attributes

Hello,

I'm creating openings to some walls with a PythonPart. I get the BaseElementAdapter for each wall and I then create the opening element with AllplanArchElements.GeneralOpeningElement(...). To create such an element in Allplan, I call the following function AllplanBaseElements.CreateElements:

CreateElements(doc:NemAll_Python_IFW_ElementAdapter.DocumentAdapter, insertionMat:NemAll_Python_Geometry.Matrix3D, modelEleList:list, modelUuidList:list, assoRefObj:object, appendReinfPosNr:bool=True, createUndoStep:bool=True) -> NemAll_Python_IFW_ElementAdapter.BaseElementAdapterList

I tried to attach attributes to the GeneralOpeningElement, but as it happens in the issue [Question][PythonParts]How do I attach custom attributes to a Wall?, I cannot attach attributes directly to the ArchElement.

Following the response to the aforementioned issue, from the BaseElementAdapterList returned by AllplanBaseElements.CreateElements() I get the niche's BaseElementAdapter and attach the attributes like this:

        attr_list = BuildingElementAttributeList()
        attr_list.add_attribute(1083, "HOLE")
        
        AllplanBaseElements.ElementsAttributeService.ChangeAttributes(
            attr_list.get_attributes_list_as_tuples(),
            niche_adapters)

This is the way that it currently works to attach attributes to openings. However, when creating a new opening, if this is in contact with some other openings previously created, the attributes of the last created opening are transferred to the other openings, making these lose their attributes. If the openings are not really in contact, but from the Plan view they are, it also applies the issue.

I have attached an image with an example where this happens: 2nd replaces 1st's attributes, 3rd replaces 2nd's attributes and 4th replaces 2nd's and 3rd's attributes.

Can someone help me?

Thank you.

Anhänge (1)

Typ: image/png
17-mal heruntergeladen
Größe: 8,47 KiB

Hello,

I couldn't really reproduce the problem, but I also don't have your script. What I tried it I created two openings, that overlap in the ground view (but not in 3d) and used the example InteractorExamples/GeneralModificiation/ChangeAttributes to attach an attribute to the first one, and then another value of the same attribute to the other opening. But both received the attributes correctly, without any issues.

First, please make sure you attach the attributes to NicheTier_TypeUUID and not Niche_TypeUUID. The latter has no attributes but still the assignment might work because of some internal routines redirecting the attributes to the tier, which may not work perfectly.

Second what I can advice not knowing the script is to have a look at the routine and not rely on the order of the elements in the BaseElementAdapterList. It might be a little confusing, but this type of list is not really ordered. The order in this list is determined on how the elements are ordered in array of elements of currently opened drawing file. And this order changes after each transaction. Assigning attributes to existing elements is also a transaction. If you are calling ChangeAttributes mutliple times, but always with the same BaseElementAdapterList, this may cause the issue. A solution would be to work with ModelElementUUID and always get BaseElementAdapter with FromGUID(). UUID does not change.

Feel free to share the script here, that is causing the problems.

Best regards,
Bart

Hello Bart,

Thanks for your time.

For this:

First, please make sure you attach the attributes to NicheTier_TypeUUID and not Niche_TypeUUID. The latter has no attributes but still the assignment might work because of some internal routines redirecting the attributes to the tier, which may not work perfectly.

I checked what you mentioned, and I already have it like this.

However, for this:

If you are calling ChangeAttributes mutliple times, but always with the same BaseElementAdapterList, this may cause the issue. A solution would be to work with ModelElementUUID and always get BaseElementAdapter with FromGUID(). UUID does not change.

I think it has no sense in my use case since the BaseElementAdapterList I'm working with is created and returned by AllplanBaseElements.CreateElements() for every new Niche element.

For you to do further analysis, I generated a simplified script that maintains the same problem. The main creation procedure is done in the on_cancel_function() function. To make it work, just select a positional point after execution and close the palette.
In case you need it, my Allplan version is 2025-0-5, dated 12.03.2025.

Don't hesitate to contact me if you find any problem with executing the script.

Kind regards,
Arnau

Anhänge (1)

Typ: application/zip
0-mal heruntergeladen
Größe: 7,42 KiB