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

Pages: [1] 2
Bugs and Issues / Re: Removal of Connector leads to error
« on: August 21, 2021, 06:12:38 am »
You should contact Sparx support in order to lock down that issue.


Yes, we're going to raise a ticket. Thanks for the help.

Bugs and Issues / Re: Removal of Connector leads to error
« on: August 20, 2021, 11:30:14 pm »
True, but if I "manually" save the diagram and reload it, the connector is gone. And actually, if I remove the connector and then click on it in the diagram, I get an error message, suggesting that the connector was in fact removed from the repository, but that it's just the diagram changes that were not saved.

Bugs and Issues / Re: Removal of Connector leads to error
« on: August 20, 2021, 09:51:39 pm »
So, I got EA 15.0 uninstalled, and 15.2 installed. That should solve any driver issues, right?
Nope. After the clean install of 15.2, after deleting a connector I still need to save the diagram and reload it to avoid the connector remaining in the diagram and throwing an error when selected.

Bugs and Issues / Re: Removal of Connector leads to error
« on: August 13, 2021, 12:08:11 am »
Correct. We're using a repository in a SQL Server database.
We're using centrally managed computers, so it would be weird that my computer has these very specific issues, and others not.

Bugs and Issues / Re: Removal of Connector leads to error
« on: August 12, 2021, 06:12:43 pm »
Weird. This happens for all types of diagrams, but .... only for me. My colleagues do not experience this. Could this be a specific installation issue? Would a reinstall be the solution? And we're still working with 15.0.

Bugs and Issues / Re: Removal of Connector leads to error
« on: August 12, 2021, 06:18:21 am »
Run a consistecy check and see whther that helps.


I did. Removed two objects. Behavior in diagram didn't change.

Bugs and Issues / Removal of Connector leads to error
« on: August 11, 2021, 11:48:53 pm »
Since some time, when I remove a connector from a diagram, after acknowledging that the connector should be removed from the model, the connector remains in the diagram.
  • If I then close the diagram and reopen it, the connector is gone
  • If I try to remove the connector again, I get an error message "Either BOF or EOF is True, or the current record has been deleted" (which is, of course, correct)
It would seem that the diagram is not updated correctly after removal of a connector.
Any thoughts?

EDIT: Selecting the connector a second time leads to multiple instances of the error message. However, the contents of the connector is still available after clicking away the messages.

Isn't the root of the issue the fact that models hardly tend to be purely hierarchical, whereas the publish mechanism in EA is?
IMHO the only solution would be for EA to offer the possibility of "defining" publications, containing elements from multiple packages that do not necessarily share the same root-package, and to reuse that publish definition?

General Board / Re: EAP vs EAPX
« on: February 28, 2021, 11:57:21 pm »
You'll have to do a model transfer from a .eap file to a .eapx file.


Would that be exporting to XMI, creating a new project (in 15.2) and the importing the XMI again?

You have to make your own profile.

You can create a profile package from the context menu Add Model Using Wizard | MDG Technology Builder | Basic Template

All of that is documented in


Am I correct in assuming that the result of this will need to be applied to each and every EA installation that will be working on the same repository? This is not something that you could apply once to a meta model in the repository, and then automatically have everybody use that. I see a governance nightmare ahead.


Here's an example of how the UML profile should look like

You then need to
- export the profile to xml
- include the profile in an MDG
- Import that profile in a model (or use one of the other ways to reference an MD)
- Set the profile to be the Active profile.

Now for every ArchiMate3::ArchiMate ApplicationComponent you will get a [yourProfile]::ArchiMate ApplicationComponent instead, with the added tagged values.


Hi Geert,

Thanks. One of my issues is how do I get to the relevant profile in the first place.The EA user guide may tell me I need to do that, it doesn't tell me how to get there.

I'm seeking to add a few custom tagged value types to an existing (Archimate Capability in this specific case) stereotype, so that when I add a new element to the repository it automatically has the tagged value types (to avoid having to add them to each new element based on that stereotype).
The EA help/user guides are not really any help (as they tell you what you can do, but not how to do it).
Can anyone give me some directions as how to achieve this (so not just what to do, but also how to do that)?


Rik van der Schalie

Bugs and Issues / Boundaries and Default Image: label visibility
« on: September 23, 2020, 06:24:41 pm »

when I assign an image to a boundary (by using "Select a Default image..." or "Select an Alternate Image..."(by the way, what is the difference?)), the name of the boundary is no longer displayed.
Is there a way to overcome this (other than to put a Text Element on the boundary)?

Automation Interface, Add-Ins and Tools / Connector label visibility
« on: September 03, 2020, 05:18:40 pm »
Hi All,

I'm having an issue with connector label visibility, in that only Source and Target Bottom labels are shown, even though, in the label visibility dialogue, all labels are marked as visible. I haven't found a global setting for this, but in another post it was suggested that default label visibility might depend on the connector class it was based on (UML 2.1, vs. IDEF1X, etc.).
Does anyone have any experience with this?

I now have a working solution. By the way, for simple rectangles the StyleEx attribute is empty. You will need to get the dimensions of the boundary from the DiagramObject itself.

Pages: [1] 2