Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: canderson on March 05, 2008, 01:21:56 am
-
Hi,
I'm trying to iterate through a package documenting the contents in a way specific to my company.
I know I could use the RTF or HTML reports but to achieve the desired output I've chosen to use a combination of EA and Word automation.
In our project hierarchy we typically have a folder called 'use case view' with 3 sub folders - actors, use cases and diagrams.
(It should be pretty self explanatory what we put in each).
My question concerns Composite Elements/Diagrams.
If you make a Use Case a composite element in a diagram EA creates a new diagram for you. In the project browser this diagram is nested beneath the use case. Seeing as this doesn't fit with our project layout we simply move that diagram to the diagrams folder.
Despite having moved it, the link still works, so if you double-click the use case on a diagram you will automatically open it's associated diagram.
My question is, how can I get to the child diagram via EA's object model?
I know that an element has a diagrams collection, however, that seems to work along the lines of the diagrams collection that belongs to a package, ie - it is a representation of what's in the project tree.
I say this having tested it, if you put nest a diagram below a use case then the element's diagrams.count is > 0 and if you take it away again the count returns to 0.
The use case and it's child diagram must be linked somewhere, as the double-click to open still works.
Sorry for the long winded description, all help would be really appreciated.
Many thanks.
CA.
-
I remember this from a while back. Actually from a long while back, so the memory is only partial.
I think diagrams keep a link back to their element, as well as their package. In the latter case this link is updated whenever you move a diagram. In the former it might not be.
The link might not be a field itself, but buried in a piece of text. Check the diagram table for a diagram under an element. Then move the element and check again.
One more thing: I am not sure - either way - if this applies only to composite-type diagrams or diagrams you create via the Add menu.
David
Something like this was discussed in the forum around two years or more ago. I don't remember if they got into the details of how the diagrams were linked up.
-
Have you tried Diagram.ParentID? It's supposed to be
Read/Write. An optional ID of an element that 'owns' this diagram; eg. a Sequence diagram owned by a Use Case.
Of course this would be less comfortable. You'd have to iterate through the diagrams in your diagrams folder and return the one with the desired ParentID.
-
Thanks Frank,
You are, or course quite correct.
That should work fine; it seems that was the linkage I was trying to remember. For some reason I thought that was the parent package but that has its own field.
The ParentID field - note that unlike the Package_ID field there is no underscore in the field name - is optional. If it is present it points to the element that 'owns' the diagram.
You could use a SQL search to get the diagrams associated with an element. Perhaps there is also a 'canned' search you could run. Either can be done with automation.
David
-
Have you tried Diagram.ParentID? It's supposed to be
Read/Write. An optional ID of an element that 'owns' this diagram; eg. a Sequence diagram owned by a Use Case.
Of course this would be less comfortable. You'd have to iterate through the diagrams in your diagrams folder and return the one with the desired ParentID.
Before iterating through all the diagrams, first check the value of Element.Subtype. For most elements, including use cases, this will be 8 if there is a linked diagram, 0 otherwise.
-
Thanks to all who replied.
I've got lots to go on there and probably enough to get the job done! :)
Thanks again.
CA.
-
Before iterating through all the diagrams, first check the value of Element.Subtype. For most elements, including use cases, this will be 8 if there is a linked diagram, 0 otherwise.
Good idea Neil.
But we need to have the SDK amended to better reflect this.
But this is only subtly alluded to in the documentation. We are told that for Activity elements Subtype 8 means StructuredActivity. You can infer the linked diagram from that. The Subtype documentation does not mention this value (8) elsewhere, nor does the documentation indicate that it is providing examples. The reader (at least this reader) can get the impression that the subtypes presented comprise the entire list available.
David
-
Before iterating through all the diagrams, first check the value of Element.Subtype. For most elements, including use cases, this will be 8 if there is a linked diagram, 0 otherwise.
Good idea Neil.
But we need to have the SDK amended to better reflect this.
But this is only subtly alluded to in the documentation. We are told that for Activity elements Subtype 8 means StructuredActivity. You can infer the linked diagram from that. The Subtype documentation does not mention this value (8) elsewhere, nor does the documentation indicate that it is providing examples. The reader (at least this reader) can get the impression that the subtypes presented comprise the entire list available.
David
OK, I'll have a word with Roy...
-
Thanks Neil,
That will solve the problem for sure.
David