Access generated composite's encapsulated objects?

[Chris Cortes]

(In follow-up to my other post about generating useable composites:
http://www.sparxsystems.com/cgi-bin/yabb/YaBB.cgi?num=1234932050)

Given API's limitations regarding composites & keeping in mind that I don't want to manually hack the repository:

What is the best way to create a composite, while also having access to it's encapsulated objects?

Is that even possible? I ask because my encapsulated object count: Package.Element.Elements.Count is always coming back: == 0.

Advanced thanks again all.
- Chris

[Eve]

... my encapsulated object count: Package.Element.Elements.Count is always coming back: == 0.

Use the Package.Elements collection instead.  For a package the Element.Elements collection will always be empty.

[Chris Cortes]

Hmm, maybe I wasn't clear. The object was added to the element using element.elements.addnew() not  the package.  I should query the package?

[Eve]

The element of a package should never have sub elements.  The elements that a package owns should belong to the packages elements collection.  So you should add your sub elements directly to the package.

I suspect that if EA allows you to add elements to the package element, it will create data integrity issues (regardless of whether the integrity checker picks it up or not.)

But saying that won't really help you.  Maybe if you described a bit more of what you're actually trying to do, I (or someone else) can offer suggestions of other ways to do it.

[Chris Cortes]

Thanks Simon, you were correct.  

This is generally what I did (from memory):

Code: [Select]

//argElement is an EA.Element that is passed into this static method

EA.Element thisElement;
thisElement = (EA.Element)argElement;

var addElement = (EA.Element)thisElement.Elements.AddNew("someName","someType");

_updateThis = addElement.Update();
thisPackage.Refresh();

So when I queried: element.elements.count, I always got 0.

Turns out that the element was added to the package, and querying package.elements.count and filtering by type is the way to go. Thanks.

So, why is the Element.Elements.Count even there?

[«Midnight»]

Hi Chris,

I suspect this is there because some elements can own others. For example, a Class may be the parent of another (child) Class.

Due to the way EA handles a Package internally, there is an Element that corresponds to each Package. This is where most of the 'core' attributes - those that are common across UML elements - of the Package 'element' are stored.

However, because a Package has a much more 'powerful' (for lack of a better word) paradigm for ownership, and due to the way EA relies on packages to structure projects, the ownership of child elements is handled by the Package element itself rather than its corresponding Element.

If you were coding against an non-package element (say a Class) then you might well want to query the Class to iterate over its child elements.

That leaves the question of whether the children of an Element (not a Package) can be found at all. The answer is yes. Note that an Element has two attributes to track this, PackageID and ParentID. In the EA help you will see how these are handled.

Note as well that the children of an parent Element (again, one that is not a Package) are included in the Elements collection of the Package that owns the parent element.

Better now?

[Eve]

Well said, and exactly right.