Allplan Forum: SelectByAreaInput node inconsistent output depending on selection method

esu

05.03.2026 - 07:22

I've noticed some weird behaviour with the SelectByAreaInput node that I wanted to flag.
When selecting objects normally via the area input, the node outputs the objects as expected, straightforward, no issues.

However, when using the "Summ Function", the node attaches something called Attribute Storage to the output. This appears to be an internal Allplan object that, in my opinion, shouldn't be part of the output at all.

The bigger problem here is inconsistent output order. Depending on how the user selects elements, the node returns objects in a different sequence. For most scripts this is a serious issue, since you're often relying on a predictable, stable order to process elements correctly.

My current workaround: I filter for my target elements before using them in the script, which ensures a consistent order regardless of how the selection was made. It works, but it feels like something that shouldn't need a workaround.

I'd consider this a unintended behaviour in the node itself. The output should be consistent no matter which selection method is used.

(Allplan 2025)

Anhänge (2)

Typ: image/png

6-mal heruntergeladen

Größe: 44,75 KiB

Typ: image/png

11-mal heruntergeladen

Größe: 51,00 KiB

nemo

05.03.2026 - 07:32

Maybe it is usefull, to use the input "ObjectFilter".
Otherwise, you just get everything that is in the raised window.
And yes, there are definitely objects without visible representation, such as the AttributeElementContainer.
Since this is a selection via representation of the objects, such objects should not actually appear!
I suspect that the sum function is not suitable for this type of selection!
Perhaps you should simply not do this if it does not work!

esu

05.03.2026 - 07:53

Zitiert von: nemo

Maybe it is usefull, to use the input "ObjectFilter".

Otherwise, you just get everything that is in the raised window.
And yes, there are definitely objects without visible representation, such as the AttributeElementContainer.

Since this is a selection via representation of the objects, such objects should not actually appear!

I suspect that the sum function is not suitable for this type of selection!

Perhaps you should simply not do this if it does not work!

I think there might be a small misunderstanding. When using the normal area selection window, the AttributeElementContainer does not appear in the output, even though "you just get everything that is in the raised window.". It only shows up when selecting elements individually using the Sum Function. So the same objects, selected two different ways, produce different output. That's what I'd consider the actual "weird behaviour" here. When it would be the other way around I would understand your point.

As for simply not using the Sum Function: depending on the script, being able to aggregate a selection that way can actually be quite useful. Ruling it out isn't really practical. For example in my current case I use it to change the height of a lot of columns, and I often only want to edit certain ones.

That said, I'm genuinely curious, is there an intended use case for the AttributeElementContainer in Visual Scripting?
And if it's intended to show up, shouldn't it always be attached to the element?

nemo

05.03.2026 - 08:20

Question: When is the sum function used? While the “SelectByAreaInput” node is active?
That's exactly what you shouldn't do, as long as it works not like expected!
You may need another generic “Select” node that supports the sum function in a better way.

The AttributeElementContainer is a freestanding object for storing attributes of the drawing file!

esu

05.03.2026 - 09:32 *

Zitiert von: nemo

Question: When is the sum function used? While the “SelectByAreaInput” node is active?

That's exactly what you shouldn't do, as long as it works not like expected!

You may need another generic “Select” node that supports the sum function in a better way.
The AttributeElementContainer is a freestanding object for storing attributes of the drawing file!

question answer: yes, I activate the Sum Function while the SelectByAreaInput node is active.

I'd genuinely like to understand your perspective better, since you clearly have much more experience with Allplan's internals than I do. Why exactly is this considered the wrong way to use it? The Sum Function is actually available and usable while this node is active, and as far as I can tell there is no way to suppress or disable it. That makes it look to me like it is intentionally supported for this type of selection, which is part of why the inconsistent output surprised me.

Regarding the AttributeElementContainer, I may well be missing something about how Allplan handles this internally. But from what I observe, each column has its own individual AttributeElementContainer attached to it. And it always appears in the output when using the Sum Function(right click before selecting), regardless of whether I draw an area or click each column individually. The only case where it does not show up is when using the normal area selection without the Sum Function. That pattern makes it feel more like the AttributeElementContainer is tied to each element rather than being truly freestanding.

I am also curious whether the AttributeElementContainer is actually useful in a script context. Is there a scenario where you would intentionally work with it, or is it something that should simply be filtered out?

I am not trying to argue the behaviour is definitely a bug, I just want to understand the reasoning so I know when and why to avoid this combination.