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 - Geert Bellekens

Pages: 1 ... 514 515 [516] 517 518 ... 531
have you tried setting the diagram.PackageID and ParentID before updating?


Code seems valid to me, the only "out of the ordinary" is the type of the diagram.
Have you tried this code with a "normal" type?

If you have the same error with a normal diagram type then the problem might have something to do with a field that hasn't been filled in yet.
The "update" statement will probably call an operation that takes some parameters. I'm guessing one of them is still at "null", which causes the error.
Try setting as much attributes of the diagram as you can before updating. (start with the parent id or package id)


PS. You are doing a bit too much refreshes I think. Refresh only updates the collections in memory. The only refresh you should do here is the Element.Diagrams (and maybe the Package.Diagrams) but only if you need those collections later on in the program.
Refresh can't hurt, but its a waist of cpu cycles if nothing has changed to that collection.

Yep, that would be your problem.
You are not allowed to create a Repository object.
You need to retrieve it from the EA.Application object.


If you send me an email I'll reply with the document containing the VBA

I've done something similar for a conversion from Rational Rose to EA using Visual Basic.
Nowadays I do my add-ins/add-ons in C# because that is the language used at my client.
I'm sure you can use Java as well, and I think you can use some other languages too, but I don't have experience with those.
I don't know about examples on the web, but I could send you a VBA example that queries a diagram and gets the objects on that diagram to create a scripted representation of the diagram.

No, the EA API can be used regardless of the database that is used.

I don't think you can modify the xmi export directly, and I believe that even if that was possible it would be a big PITA.
What you could do is write a small program to fix the layout of the diagrams after they are imported in Erwin.
What you would need to in this program do is:
  • Connect to EA
  • Loop all diagrams of the exported package
  • Get te coordinates of each object in the diagram
  • Connect to Erwin
  • Find the corresponding diagram object and set its coordinates.

This way you don't have to mess with the xmi export and your solution will keep working independant of the way the model is converted from EA to Erwin.


Automation Interface, Add-Ins and Tools / Re: Supported editions
« on: March 01, 2010, 03:20:18 pm »
Yes, I don't think there are any limitation, even on EA lite (the free read-only version) you can run you addins without a problem.



Are you trying to build a connectionstring to connecto to EA? (I didn't read that explicitly in your post)
If that is the case, I would try to figure out how the dbtype changes. You can inspect the connectionstring if you do a "save as" of a model to a eap "hyperlink" file.

I think it represents the different database types as identified by EA.
We use SQL server and here the DBType is always "1".
I've seen (in the help file) that Oracle seems to be "3".



These settings are hidden somewhere in the "magic string" fields of EA.
I used this code to set the "show parameter details" to "name only"

Code: [Select]
           EA.Diagram diagram = ((EADiagram)aDiagram.getWrappedDiagram()).getWrappedDiagram() as EA.Diagram;
            string style = diagram.ExtendedStyle;
            //the ExtendedStyle is a magic string that contains (amongst others) OpParams=<number>.
            //OpParams=3 will display only the name of the parameters in messages in sequence diagrams
            int begin = style.IndexOf("OpParams=");
            if (begin >= 0)
                string searchString = style.Substring(begin, 10);
                diagram.ExtendedStyle = style.Replace(searchString, "OpParams=3");
                Logger.log("Diagram " + diagram.Name + " updated");


Automation Interface, Add-Ins and Tools / Re: Inherit from EA classes
« on: February 26, 2010, 10:57:43 pm »
No, i missed.  :-[
I meant to point to this one: (last reply)


Automation Interface, Add-Ins and Tools / Re: Inherit from EA classes
« on: February 26, 2010, 10:49:59 pm »

Please see for my view on this subject.


Automation Interface, Add-Ins and Tools / Re: object types
« on: February 26, 2010, 06:54:13 pm »

Keep in mind that a package (except for root packages  :-/) also has a related Element.
This might be useful when recursively traversing a tree.

When I write tools on EA I never use the EA elements directly. I create wrappers that follow my own view on things (like how they inherit from each other).
This allows a lot more freedom in how to structure your design.

I've documented this as a pattern on



I don't use scripting, but in my Visual Studio
EA.ObjectType.otDiagram is a valid enumeration.


Ah, ok , i get it.
So you have some generic "messaging" classes (building blocks) that can be put together at runtime to provide the required behavior.

So in fact you are trying to generate the "behavior" part of the code (creating and connecting the right instances) rather then the "structural" part.
I'm not sure about the current state of affairs in EA, but usually behavior generation isn't really supported all that well in case tools such as EA.

I believe (without proof) that it might be faster to roll your own then to try and get EA's code generator to do the job.


Pages: 1 ... 514 515 [516] 517 518 ... 531