Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - «Midnight»

Pages: 1 ... 374 375 [376] 377
Automation Interface, Add-Ins and Tools / Re: Right Click Problem
« on: March 13, 2006, 10:22:39 am »
For what it's worth...

EA seems to have occasional problems identifying which item in the project view was right-clicked. For an example, try exporting a package that has not already first been selected by (say) left-clicking it; you'll find that EA might not bring up the dialog, even though it will provide the expected context menu. [NB: This may well be a limitation imposed by how Windows handles events when drag-and-drop is involved.]

Perhaps your problem is related to this. Try forcing the selected item to the one you want to work with, and see if the expected behavior returns.

Hi Hans,

Look at section - Automation, [stuff], Reference, Element, Element.

As to the exact syntax, I remember doing something when I first solved this problem, but I cannot remember exactly what. The code base I used at the time is in an archive, but I'll look it up for you.


It's buried in the reference guide; just where it should be, but you'll go mad searching for it.

Try setting the SubType = 100 for "ActivityInitial", or 101 for "ActivityFinal."


Thanks Simon,

But just what about it is updated? Should we relink our .Net projects? And finally, are there any changes to prior interfaces we should be aware of, or are the changes more in the nature of extensions.



I tried this out with a diagram I have. Before I changed anything the Top property was set to -160. When I added 250 to it, the property returned 60. However, the element itself moved to the top of the diagram. My only idea is that the properties may be using a different coordinate system than I expected.

[Of course, with Sparx being in The Land of Aus, they might just be standing on their heads (as we northern hemisphere folks have always known) when they program this stuff.]

My suggestion is that you play around a bit, perhaps peruse the User Guide stuff on Automation and page sizes, and see what happens.

Please let me know if you get predictable results. I need to know this for an upcoming experiment where I'll need to put diagram objects in Boundary elements.


Try this:
Code: [Select]
Dim myLink as EA.Connector
myLink = Element1.Connectors.AddNew("", "Association")
myLink.SupplierID = Element2.ElementID

As before, check the EA User Guide for the allowed type strings for connectors - I've just grabbed one at random. You can also name the connection if you want.

If you don't want to have this connector show on a given diagram, look through the DiagramLinks collection of the diagram for a connector with the same ConnectorID, and delete this item from the DiagramLinks collection (versus deleting the Connector from the model).

Please explain what is going wrong when you set the Top and Left propertoes for your diagram object.


Hi again Hans,

You've done (almost) everything right to this point. [I am assuming you are calling .Update() on each thing you add to a collection via .AddNew() before anything else refers to the object in question. If you refer to a new item via its parent collecction you will also have to call .Update() on the parent collection first. Also, see the note after the list below.] If you bail out and open the EA eatest.eap file via the UI you will see:
  • The root package.
  • Inside the root package you will have:
    • My Diagram
    • Activity 1

[You might not actually get this result. I cannot remember if you can create a diagram or element as a direct child of the root. You might have to add a package in between. You'll have no trouble though, based on your code so far.]

However, if you open the diagram you will find it blank. What you want to accomplish is the equivalent of dragging Activity 1 onto My Diagram via automation. Here's how [I speak VB.Net more than VB 6, so please forgive any minor typos]:
Code: [Select]
Dim MyDiagramObject as EA.DiagramObject
MyDiagramObject = activityDiagram.DiagramObjects.AddNew("", "DiagramObject")
MyDiagramObject.ElementID = activityObjectDef.ElementID

At this point you can exit and open eatest.eap by hand and view the diagram again. You should now see Activity 1. You could get and set the .top and .left properties as well, and this would be reflected.


There are several things going on here. AFAICS:
  • The above code will get the element into the model, but not onto a diagram (via automation that is, you could always do this manually).
  • EA creates two identifiers when it creates the new elememt: the ElementID Integer which is used as the primary key for the t_object table, and the ElementGUID string that is available as a UID for replication and other purposes (including our own).
  • Because the ElementID is the PK in a repository table, it can not be manipulated by us, and is read only.
  • You
    can change the ElementGUID. First, take careful note of how it is formatted (it seems to be a 38 character string in a 40 character repository field but that should not be an issue; just do it the same way EA does). Before or immediately after you create your element, obtain your own GUID, perhaps with something like myGuid = GUID.NewGuid.ToString() (in .Net). Then set your element's ElementGUID property to your new GUID. You must do this before you call .Update() on the new element. You now have set the ElementGUID. After this point you cannot change the ElementGUID, lest you break the silver thread and trash your model...
  • The next issue you have - the coordinates of an element - requires you to work at another level of abstraction. The element you have added to the model is just (and only) that, an element. Before you think about coordinates you will have to create a diagram, and copy (a reference to) the element onto it.
  • Create the diagram via a code sequence similar to t-kouno's code. Get the acceptable "type" strings from the EA User Guide.
  • Add a DiagramObject to the diagram, again using the same type of code sequence. You can use a blank name string here, and the type string can simply be "DiagramObject" since you are not creating an actual element in the model. Set the diagram object's ElementID to the ElementID of your (model) element. Now call the .Update() method of the diagram object. (You could do the next step before this, but for now pleaase bear with me.)
  • You can now set the .left and .top properties of the diagram object to achieve what you want. You can also (I believe) size the element via the .bottom and .right properties.


Automation Interface, Add-Ins and Tools / Re: How to create repository?
« on: February 21, 2006, 07:33:17 am »
I was looking at the wording:
...add a diagram hidden without opening the project visible for the user.

I suppose you could add a diagram through SQL, but if you've got the API going anyway, why not just create the diagram that way?

Automation Interface, Add-Ins and Tools / Re: How to create repository?
« on: February 21, 2006, 06:56:15 am »
I don't see any problem there.

Copy a template repository to your work location, if you need to.
Open the repository through the automation interface; the EA application will not be visible by default.
Locate the package you want to create the diagram in, and get a reference to it - say myPackage.
Create the diagram with:
  • myDiagram = myPackage.Diagrams.AddNew("My Diagram", "Logical")
  • myDiagram.Update()
  • <If you need to reference the diagram through the package> myPackage.Diagrams.Refresh()

I have used a class diagram by default (the "Logical" keyword). Check the documentation or help file to find the correct keywords for the rest of the diagram types; capitalization seems to count.

You're likely stuck with this for good. The limitation is not in EA, but build right into UML.

UML allows a hierarchy of packages. Within each may be elements and packages. With named elements (classes, packages and so forth) these are generally uniquely named (or otherwise identified) within the containing package. The problem is that I can have a class with a given, say "foo" in my "outer" pagkage. The "outer" package may also contain a package, say "inner." The "inner" package may also have a class named "foo." Not only that, but the package containing the "outer" package may have other packages, say "sibling1," "sibling2" etc. Each of these may have its own "foo" class.

That's why you have to traverse the tree, looking for the package you want - remembering that the same duplication of names also holds true for packages - before looking up the element.

EA's .GetBeName() function works for such elements, but only within the context of a given package (or namespace of some kind), which is correct considering the above UML structural issues.

The problem of course is that elements within different namespaces may have identical names. Add to that the problem of anonymous elements and things get really dicey.

Some time ago I bit the bullet and wrote a simple recursive routine to traverse the qualified name of an element (i.e. the full path). Worked better than I thought it would, once I thought it through.

Of course, I immediately changed how I referenced elements, therefore making the routine obsolete. Since then I have no idea where I acrhived the code.

Take a look at the Project interface emumeration functions, grab an adequate XML library, and take a whack. Once you get the hang of it - which shoudl be quickly - it will fall into place.


Automation Interface, Add-Ins and Tools / Re: ExportPackageXMI
« on: February 21, 2006, 03:05:51 am »
Makes sense. I think that the .Update() call actually stores the record in the table(s). Like you I expect to get the GUID from .Net, or perhaps from a SQL Server database UniqueIdentifier field.

Automation Interface, Add-Ins and Tools / Re: ExportPackageXMI
« on: February 20, 2006, 03:52:04 pm »
Good going Jeff!

Just to be sure, what you are doing is creating an element (or package or whatever), then setting the GUID to something you created.

As I understand it this is possible via the API as well - with the caveat that you must set the GUID and call .Update() before you do anything that would reference the element.

I have a possible use for this sequence of events - versus having EA generate the GUID for me - but have not taken the plunge as yet. Knowing about the {}s will certainly save some of scant hair when the time comes.


Automation Interface, Add-Ins and Tools / Re: ExportPackageXMI
« on: February 20, 2006, 03:54:47 am »
Sorry, I assumed you were going through the API. The .Update() method is required by the API to actually save a new entity within a collection (and pretty much anything in EA is in a collection, even the models themselves). You create the thing in question, set any immediately important properties, then call .Update(). You also call .Update() after changing any properties. The .Refresh() method is called on the parent collection. You only really need to .Refresh() before you reference any of the 'collected' entities, so don't have to do this every time.

I've not tried adding new entities via SQL, since this could easily involve having to tie in other tables. I have often created a second channel to the underlying database to set various properties via SQL where no EA capability exists. The latter approach is simpler as long as I don't manipulate any fields that are tied to other tables - the links - and thus the side effects - are undocumented.

The big question here is whether there is some other table that you need to tweak before EA fully recognized the Package. My guess is that you should look at t_object. All packages have an underlying Element entity that contains the element-like attributes of the package. Thus, all packages also must have a record in the t_object table. Create a very small model via the EA UI, close it, and look at the two tables. That should give you the hints you need.

Please let me know how it comes out, once again. This is beginning to sound interesting.


Pages: 1 ... 374 375 [376] 377