Sparx Systems Forum
Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: djdejong on November 10, 2016, 04:39:05 am
-
Hey,
I'm running a script from a diagram inside a package to create a virtual doc. The script defines the model doc with a package as source. My package structure in Project Browser looks like this:
Package 1
Package 2
Package 3
My Diagram
Package 4
The script is run from My Diagram. I want to use Package 2 and Package 4 as sources for specific model docs. I currently understand how Package 3 can be used, but I'm unsure how to get the others.
Thanks!
Dana
-
Hi Dana,
Well if there's no hierarchical relationship between the two, and no connector to follow, you'll have to hard-code it.
Find the GUID or integer ID of the package in the GUI, and use Repository.GetpackageByGuid() and Repository.GetPackageByID() to retrieve the package in the script.
HTH,
/Uffe
-
Thanks. There is a hierarchical relationship, specically what I depicted there. But I ended up just asking the user with those same procedures. It would be cool if there was a way to climb the hierarchy just in the code without having to ask the user to locate the next highest package, though. Right now I only know that diagram.PackageID, where diagram is the current diagram, will get me diagram's parent package (Package 3) but I'm unsure how to climb higher. In the case of Package 4 I do agree that I'd have to ask, however.
-
Iterate Package.Packages until you find the matching Package.Name. Then repeat with that until you are through with the path.
q.
-
Right now I only know that diagram.PackageID, where diagram is the current diagram, will get me diagram's parent package (Package 3) but I'm unsure how to climb higher.
Package.ParentID will give you the PackageID of the package higher up the tree. If Package.ParentID = 0 then you are at the root.
Use Repository.GetPackageByID() to get the package based on its ID.
Geert
-
Package4, however, will still need to be hard-coded. You could, as qwerty suggested, loop over the packages from the root node and find the one with the correct name. This only works if you can guarantee that that package name will not be used again at the same level.
Using the package ID or GUID you're safe from name changes, but it won't work if someone (for some reason) decides to replace Package4 with a new package. If you want a robust, long-term solution, you'll need to introduce a relationship from Package3 to Package4 which the script can follow.
Whether that's worth the effort is, of course, your call.
/Uffe
-
Also: if you want to traverse your model from the top, Repository.Models contains all the project's root nodes.
/U