icon

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

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
19-mal heruntergeladen
Größe: 8,47 KiB

Lösung anzeigen Lösung verbergen

Zitiert von: arnaunadal
Hello,
This issue is still present. Is there any news or progress related to this?
Kind regards,

Arnau


Hi Arnau,

Please find the solution attached.
The issue is, that when you create an opening close to another one, the another one needs to be "recreated". This is invoked by ALLPLAN internally for the case of any overlapping between these two openings, which then would required to be considered. If the 3D geometry of these openings overlaps, the one with lower priority needs to be cut out.

This is why you get both openings (the new one, and the existing one) in the list of created elements, that the function CreateElements returns. You were looking into this list, and attached the attributes to all the openings, so you overridden the attributes of the "recreated" opening.

I solved it by creating a class, that keeps track of created openings. The class OpeningcreationUtil puts the UUID of the created opening in a list. When a new opening is created, it makes sure, that the attributes are attached only to this new opening and not to other, already created.

Let me know, if that helped.

Best,
Bart

Anhänge (1)

Typ: application/zip
1-mal heruntergeladen
Größe: 8,32 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
77-mal heruntergeladen
Größe: 7,42 KiB

Hello,

This issue is still present. Is there any news or progress related to this?

Kind regards,
Arnau

Zitiert von: arnaunadal
Hello,
This issue is still present. Is there any news or progress related to this?
Kind regards,

Arnau


Hi Arnau,

Please find the solution attached.
The issue is, that when you create an opening close to another one, the another one needs to be "recreated". This is invoked by ALLPLAN internally for the case of any overlapping between these two openings, which then would required to be considered. If the 3D geometry of these openings overlaps, the one with lower priority needs to be cut out.

This is why you get both openings (the new one, and the existing one) in the list of created elements, that the function CreateElements returns. You were looking into this list, and attached the attributes to all the openings, so you overridden the attributes of the "recreated" opening.

I solved it by creating a class, that keeps track of created openings. The class OpeningcreationUtil puts the UUID of the created opening in a list. When a new opening is created, it makes sure, that the attributes are attached only to this new opening and not to other, already created.

Let me know, if that helped.

Best,
Bart

Anhänge (1)

Typ: application/zip
1-mal heruntergeladen
Größe: 8,32 KiB

Hi Bart,

I've tested your proposal and there's no doubt that it's the proper solution to this problem.
I was unaware of how the creation of openings from PythonParts was working in Allplan, and I couldn't see the issue myself, so the explanation provided will surely help us in future developments.

Thank you for your answer and for the effort you made to provide us with a feasible solution.

Best,
Arnau