v16.1 - <package>.Elements.GetByName() Failure!

[Paolo F Cantoni]

Hi All,
This looks like a new v16 bug (possibly related to the change in what objects are visible in the browser).   <package>.Elements.GetByName() will fail if the named item you are searching for is nested under another.

A simple script will reveal the problem.  I won't provide one since it's context-dependent.  However, in a package with multiple items, find one, then move it to be nested under another.  you will then get an "Index out of bounds" error on the  <package>.Elements.GetByName() statement.

This used to work for nearly a decade before (it's fundamental to our Neighborhood diagrammer add-in)!

This needs to be fixed ASAP!

Reported,
Paolo

[Eve]

From what I can see, the Package Elements collections has been intended to exclude the nested elements since build 851. If it was 'working' for you then I suggest that's a bug.

[Geert Bellekens]

Easy workaround:

use

Code: [Select]

Repository.GetElementSet($"select o.Object_ID from t_object where o.Package_ID = '{myPackageID}'", 2);
Geert

[Paolo F Cantoni]

From what I can see, the Package Elements collections have been intended to exclude the nested elements since build 851. If it was 'working' for you, then I suggest that's a bug.

OK, we may have recently changed certain "invisible" elements from being at the package level to being nested under their related elements.  We suspected this was the case, but with nearly 100,000 items to move, I thought we'd get official information from Sparx - especially since this little tidbit is NOT mentioned in the documentation!

We'll have a think about what to do to sort this out.

Paolo

[Paolo F Cantoni]

From what I can see, the Package Elements collections have been intended to exclude the nested elements since build 851. If it was 'working' for you, then I suggest that's a bug.

Just to clarify, are you suggesting that if it was "working" before v16, that was a bug in versions before 16 that got fixed in v16?   Not complaining; just trying to clarify what you meant.

Paolo

[Paolo F Cantoni]

Easy workaround:

use

Code: [Select]

Repository.GetElementSet($"select o.Object_ID from t_object where o.Package_ID = '{myPackageID}'", 2);
Geert

Thanks, Geert,
but I haven't used GetElementSet before, and I need it in C# rather than in a script.  As I understand GetElementSet, it returns a list of comma-separated object_IDs.
So I think you're suggesting I scan the returned set of IDs for the number of objects in the package - looking for the object with the correct name.  We may have 10,000 objects in that package!
I assume the Elements.GetByName() does some sort of indexed lookup.

We decided to nest the invisible "DiagramNote" elements under the same element as the "Neighbourhood" diagram was nested under so that they would be moved "as a unit".  Conceptually, Diagram nests into the Element, DiagramNote nests into the Diagram, ergo, DiagramNote also nests (derived by traversal) into Element - so we thought! 

Looks like EA has "snookered us".  I think that leaving (i.e. moving back) the DiagramNotes ONLY at the package level may be the "best of a bad job".

Any other ideas?

Paolo
[Edit: I just had an idea!  Since I know the base element in the nesting tree, I can convert the <package>.Elements.GetByName() to <base element>.Elements.GetByName()!  Just tested in a script and all is good!]

[Geert Bellekens]

GetElementSet gives you an EA.Collection of the elements with the objectID's returned by the specified query.

This is definitely faster than GetByName, and with the added bonus that you can decide yourself what should happen if you have multiple elements with the same name.

I never ever use GetByName because of that undefined behavior.

Geert

[Paolo F Cantoni]

GetElementSet gives you an EA.Collection of the elements with the objectIDs returned by the specified query.

This is definitely faster than GetByName, and with the added bonus that you can decide for yourself what should happen if you have multiple elements with the same name.

I never ever use GetByName because of that undefined behaviour.

Geert

Thanks for clarifying.  I'll consider it for future changes.  In this case, the names are guaranteed unique, so I'll stick with the GetByName on the elements.

Paolo