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 - Uffe

Pages: 1 ... 70 71 [72] 73 74 ... 80
Automation Interface, Add-Ins and Tools / Icons in package contents
« on: January 28, 2015, 09:44:50 pm »

I'm working on an MDG Technology which includes stereotype icons. These show up as expected in the project browser and the toolbox, but if a package is displayed with its contents, the metaclass icons (Activity, Class, Object, etc) are used instead.

I wouldn't call this a bug necessarily, more of an oversight. Or is there a specific reason why the metaclass icons are used in package contents?

I'm using 1112 -- can anyone confirm this behaviour in EA 12?




The help file (in 1112) says the logo is a 64x64 bitmap. You can select a larger image and EA will resize it.

But if you do a screen dump of the MDG Technologies (selection) dialog, the logo area seems more like 128x128.

So if I use a 128x128 image, is it first reduced to 64x64 and then enlarged? Or is the full 128x128 retained (meaning the help file's incorrect)?

If the 128x128 is first reduced, I might as well use a 64x64 and save some space in the file and some time in the generation.



Hi there!

Using various special attributes (_instance*) I can specify which instance types are related to a stereotyped classifier type.
I need to do this in reverse.

In other words, I want to add a stereotyped instance type (Object) to one of my toolboxes, and specify that its classifier must be an Actor (stereotyped if necessary). This would limit the selection in the Select Classifier dialog.

Without resorting to scripts or an Add-In, is there a way to achieve this?



Automation Interface, Add-Ins and Tools / Re: Unit tests for an add'in
« on: January 08, 2015, 11:04:15 pm »
Essentially, there are no constructors in the API. Instead, Collection.AddNew() is used as a factory method. The Collection class is generic and there is to my knowledge no way of checking what type of object (package, element, attribute, etc) it contains in runtime -- you simply have to know which is which.

The contents of the repository are accessed recursively. A newly created repository contains one single root-level package (default name "Model"), which you can retrieve from the Repository.Models collection.

The method I suggested requires an element Collection from a non-root package. Root level packages can only contain packages ("view" packages in the project browser), but those packages in turn can contain elements and diagrams as well as further child packages. Thus, trying AddNew() on the Elements collection of a root-level package will cause an error.

So it's a question of how much you want to create within the context of the test method. You could go as far as creating the repository itself (Repository.CreateModel()), but that can take several seconds which is probably not acceptable in a unit test so you'll most likely want to do that as part of your test initialisation.

Similarly, you could create the view-level package inside the test method. This doesn't take as anywhere near as much time but for convenience I'd push that to the initialisation as well.

So something along the following lines should do it.
Code: [Select]
public Package InitTestRepository(Repository repository, string eapFileName)
    repository.CreateModel(cmEAPFromBase, eapFileName, 0);
    Package rootPackage = repository.Models.GetAt(0);
    return rootPackage.Packages.AddNew("Test View", "Package");
During initialisation, store the result in a member or global variable, then simply pass thatVariable.Elements to test methods which create elements, thatVariable.Packages to methods which create packages, etc.

Automation Interface, Add-Ins and Tools / Re: Unit tests for an add'in
« on: January 07, 2015, 07:29:10 pm »
Nor mine. You'll have to take the collection as an argument, as in
Code: [Select]
public void TestMethod1(Collection elements)
    Element uc1 = elements.AddNew("Use Case 1", "Use Case");
    Assert.Equals(uc1, "test"); //method1 should have renamed uc1 to test
This, of course, leaves the element in the collection regardless of the success or failure of the test, so probably you'll want to take the element as an argument instead and do the creation and deletion outside.



Child elements are children of another element, not of packages, so I wouldn't expect this to work.

There are some options to manipulate the presentation of package contents in diagrams, in the Diagram - Behavior section of the options dialog. You can select whether to display linked elements (as well as contained ones) and whether to display element scope, but there's no option for stereotypes.


Automation Interface, Add-Ins and Tools / Re: AddIn on shapescript...
« on: December 12, 2014, 11:00:57 pm »
Sorry, your update came in while I was crafting my eloquent, if not loquacious, reply.  ;D

Try a plain object, rather than an object array.


Automation Interface, Add-Ins and Tools / Re: AddIn on shapescript...
« on: December 12, 2014, 10:58:58 pm »

The "AddIn" part of the argument should be the name of the Add-In. This is not the name of the main class, nor the project/solution, but the assembly name.
If you don't have the source handy you can check the menu under Extensions -- Manage Add-Ins, that should give you the correct name.

As to the method signature, strictly speaking the third argument should be an object rather than a string[] but I think it'll work either way. Still, declaring it as object and performing the cast explicitly is more robust, and robust code is the only code worth writing (sorry, that's what fifteen years in the defence industry does to you...).

A simple way to check whether the call is coming through is to add a line
Code: [Select]
repository.WriteOutput("System", "GetRelationships() called", -1);to your method. Remember to open the output tab in your test project, or call repository.EnsureOutputVisible(). Ahhh, the days of fprintf() debugging... :)

Finally, not to knock Geert's samples, but I strongly recommend that you do not allow Visual Studio to register the assembly for COM interop, but instead create an installer. Otherwise, since Studio does not automatically de-register when rebuilding (but an installer will deregister when uninstalling) you'll soon find your dev machine registry lousy with old registrations which can make debugging a far bigger PITA than it needs to be.
Ayone who's ever seen the above dialog complaining "Error - AddIn not found" knows what I'm on about.


You can achieve something like this, but you have to create a UML profile (and preferably an MDG Technology to contain it).

In a profile you create stereotypes, and a stereotype can have its own shape script, which controls how elements of that stereotype are displayed in diagrams. In a shape script, you can display an image from the image manager by using the image() method.

You'd have to create one stereotype for each image, but it should work. You can create stereotypes for boundaries as well as for classes, components, etc, so depending on how you intend to use the images that might be suitable.



There's no way to add a description to the image itself, but if you only want a very brief description you can store it as the image's name, which you can change in the image manager; I don't think that is ever used outside the image manager.

The images are stored in the table t_image, although I'm not sure about the exact representation.

Finding them in diagrams is pretty straightforward. The reference is stored as text in the database, in the t_diagramobjects.ObjectStyle. Any diagram object whose ObjectStyle contains the string "ImageID=NUMBER;", where NUMBER > 0. (The number seems to be set to 0 rather than deleted altogether from this column when the image is cleared in the diagram.)

The ImageID is a reference into t_image.ImageID, and of course the diagram and elements can be found from t_diagramobjects.Diagram_ID and t_diagramobjects.Object_ID, respectively.

Note that the ObjectStyle cannot be read from the DiagramObject class, but must be read from the database.



Hi all,

Scripts can be exported to an MDG Technology. They then land in their own script group, where they can be viewed but not modified -- although they can of course be copied / pasted into new scripts, so if you want to restrict functionality for security reasons rather than convenience, security mechanisms written into a script are trivial to bypass.

It is not possible to export project browser or diagram scripts: they end up in the same group as other scripts and do not show up in the project browser / diagram "Scripts" context menu. These context menus have no submenus; all project browser / diagram scripts are flattened into a single menu regardless of which group they might belong to.

What I usually do in this situation is write my scripts as sets of functions which take as arguments model elements of the appropriate type (package, element, etc), export them, and then in the target projects write project browser / diagram scripts which wrap these library script functions.

This way I can develop and maintain the meat of the scripts in my MDG Technology project, and only need to maintain the wrappers, which are essentially clones of each other, in the target project.



Automation Interface, Add-Ins and Tools / Re: Re-using script fragments
« on: September 02, 2014, 08:11:26 pm »
We meet again! :)

Is that the whole of Jayson.TestScript? Because you get that error if the included script starts with option explicit. In other words, you need to decide beforehand whether a script file is for execution or inclusion, and place option lines only in the former (check out Local Scripts.EAConstants-VBScript; no option lines there).

This is because the !INC statement has the same(ish) semantics as a CPP #include, rather than a Java import: a textual inclusion, not a namespace reference.

For the same reason, it looks as if there's an error in the "main" script as well. Just as you don't specify a namespace for the MsgBox() reference, you shouldn't specify one for SayHello().



Automation Interface, Add-Ins and Tools / Re: Load project to EA application
« on: September 02, 2014, 07:41:17 pm »
No problem, and thanks for taking the time to share the working solution.


Automation Interface, Add-Ins and Tools / Re: Load project to EA application
« on: September 01, 2014, 11:39:32 pm »
qwerty's response is correct, but assumes that you're working with the EA API (so that you have access to the Repository class).

If all you want to do is fire up EA and open a specific project, but not interact with it programmatically, you should be able to do that by adding the path to the project as a command-line argument to the ProcessStartInfo constructor:

Code: [Select]
ProcessStartInfo processInfo =
    new ProcessStartInfo(@"C:\Program Files\Sparx Systems\EA\EA.exe",

Of course, you shouldn't assume the EA executable is in this location; the user could have installed it somewhere else and even if it's in the default location this code won't work on a 64-bit Windows installation.

Instead, use the path stored in the registry under HKCU\Software\Sparx Systems\EA400\EA\Install Path.


Automation Interface, Add-Ins and Tools / Re: Type vs Subtype
« on: August 12, 2014, 07:59:09 pm »
What is the difference between a Type and a Subtype?
The Type is the main category of element: Class, Activity, Component, etc. The Subtype is a further subcategorization.

If you create a regular activity diagram, and create an Action, EA pops up a menu where you must select the type of Action to create. In this case, the element type is Action and the subtype is Atomic, Call Behavior, etc.

Classifier is a different thing again. It is not a categorization, but a reference to a definition. An Object normally has a Class classifier, Actions have Activity classifiers - the classifier is the reference from the instance element to the defining element.

Oh, and an element's type can be changed in the Element Properties window (not the dialog). You'll find the type displayed there, and an ellipsis button ("...") on the far right, which is normally invisible but it's there. Click that and EA opens the Select Element Type dialog.



Pages: 1 ... 70 71 [72] 73 74 ... 80