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.

Topics - McMannus

Pages: [1] 2 3
Hi all,

as some of you guys maybe remember, I published an article on the EA community site in 2016 about easily finding out about differences in the EA API after version changes of EA (Link to article).

As in the near future, EA 14.0 is going to be released, I generated the API Diff to see the new and changed API methods. To help you guys out, I decided to upload all diffs I made so far, post them in this thread and keep it up-to-date: Using them is easy.
So, here are the links along with some highlights.

API Differences

EA9.3 -> EA10.0
EA10.0 -> EA11.0
EA11.0 -> EA12.0
EA12.0 -> EA12.1
EA12.1 -> EA13.0
EA13.0 -> EA13.5 (Generated 23 March 2018)
EA13.5 -> EA14.0 (Generated 23 March 2018)
EA13.5 -> EA14.0 (Generated 25 May 2018, Build 1421)

Highlights in 14.0
  • Update 25.05.2018: New method Repository.ImportRASAsset(), besides that only minor typo corrections and added links in docs
  • New methods in Repository to save profiles and generate MDGs programmatically
  • Repository.GetAllDiagramImagesAndMap(): Saves the image and image-map for every diagram in the model, in the specified directory location.
  • Repository.ShowAddinWindow(): Shows the docked Add-In window on the specified page. Returns True if a tab of the specified name is now displayed.
  • New methods in Project Interface to build and run executable state machines

Highlights in 13.5
  • Repository.RefreshPackage() renamed into Repository.ReloadPackage(): reload a single package in project browser and its opened diagrams
  • Element.FQName: dot-separated list of the element parent hierarchy
  • EA_OnPreNewElement order changed in the event properties

Highlights in 13.0
  • Repository.RefreshPackage(): Reloads a Package and its open child diagrams.
  • Element.GetDecisionTable(): Provides read-only access to a decision table XML string.
  • Element.Clone(): Inserts a copy of the selected element under the same parent as the selected element.
  • Connector.AssociationClass: Returns the Association Class element if the connector has one; otherwise NULL/.
  • Diagram.FilterElements: Applies a comma-separated list of object ids (from SelectedObjects) to the currently-applied diagram filter, overriding the filter. The effect persists until another filter is applied, or the diagram is closed.
  • Diagram.FindElementInDiagram(): This function activates the Diagram View and displays the diagram with the diagram object selected.
  • EA_OnPreNewElement has a new parameter FQStereotype
  • New broadcast event EA_GetRibbonCategory: Add-Ins can use EA_GetRibbonCategory events to identify the Ribbon in which the Add-In should place its menu icon.

Regards from Germany

Hi all,

due to having had now incompatibility issues on three version changes of EA (11->12, 12->13, 13->13.5), I wanted to make the knowledge explicit, how to circumvent these issues.

The affected method was the EA_OnPreNewElement broadcast event with its signature
Code: [Select]
bool EA_OnPreNewElement(IDualRepository repository, EventProperties info)The EventProperties parameter is a class that contains a list of arbitrary data that can be accessed by
Code: [Select]
EventProperties.Get(object Index)This class is used as parameter in several of EA's broadcast events.

The problem with the usage of this class is that there are two ways of accessing the data in the event properties: either by passing a zero-based index to access a certain value in the list Props.Get(3) or by using a string identifier for the content which should be retrieved Props.Get("ObjectID").

If you use the index-based access (like I did since the beginning of my add-in writing. Don't even know, if the associative access was possible back then), you have to rely on the fact that the order of contents in the event properties is not changed.
Following is a small history of the event properties content and order in EA_OnPreNewElement:
EA 11:
0 Type 1 Stereotype 2 ParentID 3 DiagramID
EA 12:
0 Type 1 Stereotype 2 ParentID 3 DiagramID --> the parent ID delivered in EA12 is not anymore the direct element the element was dragged to, but the outmost parent element in the diagram
EA 13:
0 Type 1 FQStereotype 2 Stereotype 3 ParentID 4 DiagramID --> FQStereotype inserted in the middle of the list
EA 13.5:
0 Type 1 ParentID 2 DiagramID 3 Stereotype 4 FQStereotype --> Stereotype and FQStereotype moved to the end of the list

Without commenting this observation further, only two recommendations :):
  • To add-in developers: Only use the associative access to the event properties list (Props.Get("ParentID")), as hopefully the identifiers will stay the same for coming EA versions.
  • To the Sparxians designing the add-in interface: In the future, please make sure to add new parameters to the end of the list so that you will not cause incompatibilities in newer EA versions and don't change the order if there is no good reason for it. Alternatively, deprecate the index-based getter method in the EventProperties class.

Just my two cents on the topic

Hi guys,

in model-based engineering, a core means for complexity reduction is to use multiple views (EA diagrams) for the same component (EA element) for depicting certain development aspects. For instance in the embedded system domain, there are architectural perspectives containing data flow views or dependency views. For the same component, there also exist quality perspectives such as the failure propagation through the component, which is related to the quality safety.

A typical model structure for this setting is illustrated in the image at the following link: Example

The example contains the architectural component "MyComponent" having 3 views, where the first one contains full details and the other two contain only certain aspects (in this case a subset of the interface). The "FailureModel MyComponent" is a separate element having 3 views, too.

To indicate that the failure propagation model is targeting "MyComponent", EA connectors can be used to formally relate both elements with each other. However, the aspects, which are solely existent through the notion of diagrams, don't offer the possibility for formal relation, although this would be very beneficial for automated consistency validation, i.e. if I add a port to e.g. aspect 1, I only want it to be shown in aspect 1 of the failure view as well, but not in aspect 2.

Is there a way in EA to formally relate or link two diagrams with each other, so that uambiguous programmatical navigation from a diagram of one element to a diagram of another element gets possible? (blue double arrows in the image)

As I'm quite fit in writing add-ins for EA, I know there is always the possibility to keep a custom programmatical map between the diagrams somewhere in the add-in. However, this would not be my first choice, as it means manual maintenance of consistency, when the user deletes or changes diagrams. I'm rather thriving to a native EA solution to the problem and hope I just overlooked a feature in the past 10 years of using EA :-)

Many thanks for your help.


Hi all,

I'm currently having a customer from Japan using the Japanese edition of EA. I wonder, if the different language and in particular the different characters might brake something in our add-ins. I mainly think about plain SQL query interpretation going through Rep.SQLQuery() and Rep.Execute().

Did someone of you guys experience problems with that?

Many thanks!

Hi guys,

I'm modeling and analyzing component architectures with a custom profile + add-in. The syntax and semantics are pretty close to SysML and therefore I'd like to have an arbitrary number of diagrams (like Internal Block Diagrams) per component. As far as I understand, EA's SysML extension derives the association of a diagram to a block only through the implicit containment in the project browser, i.e. when I move the diagram somewhere different in the model, the "formal" relation gets lost.

This is exactly the problem I'm trying to solve. The possibilities I thought about are:
1. Introduce a reference list tagged value to the component that is manually maintained in the add-in.
2. If a list of associated diagrams should be retrieved, search through the diagram elements of existing diagrams and take the ones, where the component is used largest element containing its realization.

In the past, we used Option 1 in similar use cases, but it proved to be a pain in the ass to maintain tagged value lists of GUIDs manually during deletion and creation. In addition, reuse model parts in different projects is pretty hard, because the GUIDs get outdated quickly in that case.
Option 2 is again implicit and not very robust.

Does anyone of you have a better idea, how this could be solved? The ideal solution would be a connector between an element and a diagram, but that is not possible as far as i know.

Thanks for any insight!

Hi guys,

I have defined several relation stereotypes in our profiles that serve for traceability and containment. The containment relations aim at specifying a containment structure being independent from the implicit containment existent through the project browser. The driver for this decision was EA's automatic model movement of elements to other parents based on diagram movement.

When elements are created from the toolbox or programmatically, the relations are automatically created. As we know, a connector is shown by default, if both source and target element appear together in a diagram. This clutters diagrams a lot for my specific use case, therefore I'd like to hide these connectors by default. My approach for doing so was to hide the diagram links in code directly after I put the elements and the connector in the diagram programmatically.

The problem is that the hiding doesn't have any effect, because the diagram link is apparently not created immediately, when the elements (connected already in the model) are put in the diagram.

I wonder if it's possible to hide certain stereotyped connectors through the profile definition directly.

I didn't find anything in the docs w.r.t such a feature. If this is not possible, I have to solve that programmatically somehow.

In this case: Did someone face a similar issue in the past that diagram links only appear delayed in t_diagramlinks and probably has a solution for this issue?

Another option, we used for similar things in the past was to use refGUID tagged values referencing the related elements. However, I remember, they had to be maintained manually (i.e. potential inconsistencies because of deletions of referenced elements) and therefore we discarded this approach back then.

Thanks for your help, guys :-)


Bugs and Issues / Model Root Package API inconsistency
« on: August 18, 2016, 11:37:04 pm »
Hi guys,

I'm currently developing with EA 12.1 Build 1229.

The repository context item getter methods are somehow inconsistent for model root packages as can be seen in the following pictures.

For the "Model" root package:

For the "Bugs" normal package:

As can be seen, the context item types differ in the first case.

The million-dollar question: Is this a bug or a feature with a well-thought reason behind?

Thanks for enlightenment!

Hi guys,

because not everybody is reading the community resources plus we have a neat search in this forum, I'd like to link my article about diffing release changes here as well:


Hi guys,

today I played around with the EA13 beta and found the new Diagram.FilterElements property interesting from its advertisement in the API docs.
However, I don't quite understand the effect of this feature.

What I thought, this feature is doing: I'm currently applying a diagram filter to a diagram, where everything is greyed out. By adding a comma-separated list of element IDs to the property, exactly these elements are not greyed out anymore.
Could of course also be vice versa, but nothing happened in my case :-(

May someone bring light in the dark?


General Board / Memo tagged values in shapescripts
« on: September 09, 2015, 09:28:47 pm »
Hi guys,

is there any way to display memo tagged values correctly within element shapescripts?

Code: [Select]
unfortunately only prints "<memo>" and there is no way to access the tag's notes by using shapescript attributes.

Performing an add-in call to get the notes is incredibly slow for a medium number of elements per diagram, so this is also not an option.

Any ideas?

General Board / Pure black as background color of stereotypes
« on: September 17, 2015, 06:17:25 pm »
Hi guys,

I just tried in vain to set the background color of a stereotype extending the "Provided Interface" meta-class to pure black RGB=(0,0,0).
I tried both the default appearance approach as well as using the following Shapescript with no success.

Code: [Select]

Interestingly, the stereotype in the output profile has the bgcolor attribute set to -2 instead of 0.

I solved the problem by using RGB=(1,1,1) which is of course still dark enough but it's not the proper solution, why I believe this was not intended by Sparx  :)

General Board / Synchronize secondary stereotypes
« on: August 29, 2013, 09:29:54 pm »
Version 7.0 - Released (Build 813) - Extended Synch Tagged Values and Constraints command to synchronize secondary stereotypes.

The situation: I have some stereotypes in a toolbox which can be dragged in a diagram. Optionally, more stereotypes existing in my profile (but not in the toolbox) are added to the diagram elements later. If those optional stereotypes change in the profile, I don't see any way to synchronize them in my existing projects. Since they aren't available in the toolbox, the approach right-klick>Synchronize Stereotype doesn't work.

I think it would work if I programmatically delete and reassign the stereotypes, but the quoted release note seems to me like there is a built in solution for that task, because the optional stereotypes are in my opinion exactly these secondary stereotypes.

Thanks for help!

General Board / Multiplicity on Tagged Values
« on: August 12, 2013, 09:05:14 pm »
Hi all,

I have just added an attribute to a stereotype:
+ result : double [0..*]
As I found in the help, this is treated internally as tagged value. Additionally, I understand this attribute as an array of doubles. When it comes to fill in this attribute (by hand or by addin) I just don't know how to perform the task of adding values to it.
Actually the ordinary approach through the TaggedValue.Value field is not appropriate since it is a string.
So this boils down to the questions:

1) Does EA in any sense care about the datatype that is assigned to the tagged value (maybe by assigning the doubles in a particular way, e.g. a semicolon separated list) or is it up to me to organize the TaggedValue string in a way fitting to my needs?

2) Which consequences does it have to set the multiplicity field for tagged values?

General Board / Dependent Tagged Values
« on: August 08, 2013, 08:59:13 am »
Hi all,

I have the following problem: Stereotype A has a tagged value, which is an enumeration with three entries. Based on the user selection of this tagged value additional stereotypes should be assigned to the element so that there will be more detailed tagged value fields to fill out dependent on the first selection.

Is this possible in EA and if yes, how can I react on the selection within an addin?

Thanks in advance!

General Board / Hide { from <packagename>} label
« on: July 24, 2013, 06:59:48 pm »
Hi all,

I've been searching the EA help for a couple of hours now and I unfortunately did not find the right information.
The question is as easy as this:

How can I hide the { from <packagename>} label when I put a link to a package in another package?

Thanks in advance!

Pages: [1] 2 3