I am not a developer, so I won't be able to answer coding questions.
However, since ARCHICAD 23, Columns and Beam may be composed of Segments.
So I believe ColumnElement will return the total number of Columns, while ColumnSegmentElement will return the total number of Segments within all those Columns.
This probably also means that ColumnSegmentElement is always equal to or greater than ColumnElement since there is always at least 1 Segment in 1 Column.
Example: You have 1 Column with 1 Segment in it, 1 Column with 2 Segments in it, and 1 Column with 3 Segments in it. In this case ColumnElement should be 3, while ColumnSegmentElement should be 6.
I hope if I write totally wrong things here, a developer will correct me when they read this.
Get Archicad Tips at https://twitter.com/laszlonagy AMD Ryzen 1700X CPU, 48 GB RAM, Nvidia GTX 1060 6GB, 500 GB NVMe SSD 2x28" (2560x1440), WIN10 PRO ENG, AC20-AC26 Loving Archicad since 1995
Laszlo is correct. Beams and columns are now assemblies like the curtain wall or stair elements. An assembly is comprised of a parent element and any number of child component elements ("segments" for beams and columns). When you migrate a column or beam element from AC22 to AC23, it becomes 2 elements: a parent and 1 child segment.
This presents a number of complications for developers and users, particularly when there is an important distinction between the the assembly as a whole or a component in the assembly. Consider a modeless palette that interacts with selected elements. Typically the user can only select the parent assembly - but what if the user wants to interact with one of the child elements? Assemblies support an "edit" mode, where the individual parts can be selected an interacted with, but only for a single assembly. And worse, if a beam/column has only a single segment (which is typically the case) you can't enter 'edit' mode at all, and therefore it is impossible to engage with the segment through a modeless palette.
The problem is compounded by the fact that the parent and child elements have separate meta-data, e.g. ID, classification, properties etc. A beam/column migrated from AC22 to AC23 migrates the meta-data into the parent assembly but not into the child segment. So, for example, if you have a database coupling records on the basis of ID and extracting data related to materials or surfaces, this completely breaks down because the child segments with the required data haven't inherited the meta-data values of the parent. And there is no easy way for the user to inspect this because modeless interaction with the child segment isn't possible. We could work around this by assuming the selection means the child, but this will break in future if they start creating multi-segment beams/columns.
This is causing a headache for some of our largest customer and we're still working with them to devise an appropriate response. I hope your requirements prove to be much simpler!
Thank you for your response, Laszlo, Ralph. It makes sense from the user perspective, however, I somehow feel there is something wrong 'under the hood' and this code will be refactored in some way sooner or later. Looks like Ralph can confirm. Luckily, it's not a big issue for us, we just bypass the newly added elements as they seem are having no geometry representation in the scene so we can't parse them.
@Ralph: Parsing scene geometry. The final step of this process is decomposing polygons into a set of convex polygons and converting them to triangles.
To start the building process we need num of elements in the scene. For AC <=22 it was ok, because ModelerAPI::Model::GetElementCount() was returning relevant number => 1 column = 1 element.
In AC 23 however, we can rely on this num no longer.
My first approach was to select which enum values are relevant but it was the wrong way. Then my next idea was to obtain num of GetMeshBodyCount() or GetTessellatedBodyCount(). But it was also wrong because for example, ColumnElement was returning it has a Body, but the body had no polys.
My recent working solution is to get to go one step deeper meaning I'm looking if mesh body has polygons MeshBody::GetPolygonCount() -> if yes -> it's ok to build...