Book a Demo

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

Pages: [1] 2 3 ... 541
1
I'll be honest. Everything I said was based off my memory and I didn't try to create an aggregations. I'm not going to comment on how they are created.

There are also special cases for Aggregation connectors because they date back to before UML 2.0. If you want to be strictly UML conformant just use Associations instead.

You should definitely ignore the SourceIsNavigable and DestIsNavigable columns on t_connector. They are boolean values and we want to store non-boolean values for navigability. The result is that they aren't used.

2
In UML 2.5.1 the navigability of an end is determined by whether it is contained in the navigableOwnedEnd. But there are 3 different notations that are relevant. "Navigable", "Non-Navigable", and "Unspecified".

For legacy reasons EA has two different ways to set this information and when you change one, the other will be updated.

The direction "Source -> Destination" corresponds to the Destination being navigable and the Source not being navigable (but it could still be notated with unspecified). "Destination -> Source" is the opposite. This works in the GUI because you can only change one at a time.

In the API it isn't quite as clear-cut, but the first update call is performing the same validation as the GUI

Code: [Select]
  oConnector.Direction = "Source -> Destination"
' ...
  oSourceEnd.Navigable = "Navigable"
  oTargetEnd.Navigable = "Unspecified"
  oSourceEnd.Update
  oTargetEnd.Update
  oConnector.Update
The oSourceEnd.Update updates the connector direction because it's incompatible with the value for Navigable that is being saved.

The answer is to only include one method for setting the navigability in your spreadsheet.


4
I believe Geert has cut to the core of the issue.

The Browser is not relevant for this function at all.

It gets more complicated than that though:
  • It is possible to drag a tab from the main window out and dock it elsewhere. In that case it becomes the last of the visible main window views that you interacted with.
  • There may not be an active diagram at all. In particular if you're running from a script editor or console, that will be the active window so the current diagram will be null.


5
- I have learned/understand that the x axis needs to be negative.
y axis, not x.

- I have learned/understand that if anything goes "wonky" that the object is restored to some default location at the top left.
If any code puts an element into a position it can't possibly be displayed, it gets fixed.

You've already identified everything you need to do what you want except for Sequence. The good news and bad news is that you don't get anything for free. If you change the position of one DiagramObject it won't change the position of any others.

The documentation is at https://sparxsystems.com/enterprise_architect_user_guide/17.1/add-ins___scripting/diagramobjects.html

That's everything EA offers you for the layout of objects.

What you're about to discover is that laying out a graph in general is a hard problem and you can't solve all the problems using a single algorithm because the different goals of a layout are mutually exclusive. Adding nesting/denesting of nodes adds to the list of problems that you'll encounter.

6
Unfortunately, I am getting the error which says that I "Can't assign to read-only property".
Yep, it's marked as read-only in the documentation.

Attribute Class

I have found threads that say to just update the ParentID of the element to the new parent and refresh both the old and new parent.
It would appear that those threads either had people guessing, or they weren't about attributes. That process would work for child elements.

7
Bugs and Issues / Re: GUIDs are case sensitive!
« on: March 20, 2026, 08:42:50 am »
When I programmatically create a connector between two operations, the referenced GUIDs are written in all uppercase in the StyleEx field of the t_connector table.
Then create them the way that EA creates them. This is a bug in your code regardless of what your opinion of how EA should behave.

8
PCS General Board / Re: OSLC PCS SynchProfile method ?
« on: March 18, 2026, 08:39:03 am »
EA Interop API provides a method to synchronize the MDG's stereotypes i.e. matching what one can do in EA via a right click on a stereotype in the toolbox  > Synchronize Stereotype
Example:    Repository.CustomCommand("Repository", "SynchProfile", "Profile=myProfile;Stereotype=test;");
Use the supported function instead on the EA side.

Repository.SynchProfile ("myProfile", "test");

is there a way to run this Synchronize command so that all tagged values matching the profile definition are created ?
No.

9
PCS General Board / Re: Project Transfert via the PCS OSLC API
« on: March 18, 2026, 08:32:51 am »
Is it likely to be supported in the future or a decision not to expose this feature via the PCS API ?
Currently PCS only offers the OSLC access to data and not any of the functionality that EA itself offers. I'm not aware of any plans to change that.

10
Yes

11
I think the only option is to override each allowed relationship.

12
1. element.Stereotype = "ArchiMate3::DataObject";
Attempts to assign a stereotype with the name "ArchiMate3::DataObject" to the object. If it is not already defined it will attempt to define it as a global stereotype. It's less bad if you don't include a profile. As an example, if you specified ArchiMate_DataObject it may assign ArchiMate2::ArchiMate_DataObject or ArchiMate3::ArchiMate_DataObject. Think of it as "I don't care where the stereotype comes from, as long as it has this name".

2. element.StereotypeEx = "ArchiMate3::DataObject";
Attempts to assign the stereotype "DataObject" from the profile "ArchiMate3" to the object. As Geert said, this won't be found because no such stereotype exists in that profile. If you replace it with "ArchiMate3::ArchiMate_DataObject" It will still fail if the element is not a Class.

3. element.MetaType = "ArchiMate3::DataObject";
Does literally nothing.

4. Repository.AdviseElementChange(element.ElementID);
Effectively updates any places in the UI that have that object.

13
The .Value is apparently needed here

Info is an EventProperties, all of the members are instances of EventProperty. So, yes if you don't add the .Value you are passing a dispatch object back into a function that expects an integer.

I did try both proposals and they both give the same error while providing a correct result.

I would trace the value and type of the elementId and its type and double check that you have reloaded that add-in after making a change.

Code: [Select]
elementId = Info.Get("ElementID").Value;
Repository.WriteOutput("System", typeof elementId + " - " + elementId, 0);
newElement = Repository.GetElementByID(elementId);

To ensure the add-in is reloaded, turn it off in the add-ins window and back on or reload the model.

14
  • Tool-Specific Features: In tools such as Sparx Enterprise Architect, a “Composite Diagram” is a child diagram nested beneath a parent element.  For example, if you double-click a Class and it opens a sub-diagram, that sub-diagram is called a “composite diagram,” regardless of whether it is a state machine, activity, or structure diagram.

Even the fact that Gemini is using the phrase "Sparx Enterprise Architect" is enough to say that it's pulling from sources that shouldn't be trusted. It's equivalent to "International Business Rhapsody". It may not be hallucinating, but drawing from unreliable sources is just as bad.

Unless this is a hallucination, then a UML Composite Structure Diagram is an EA Composite Diagram; but not vice-versa!

Another problem is that EA sometimes conflates Composition with Nesting (I’ve spoken about the difference many times in the past).  You’ll see Gemini did not make that conflation.  What EA calls a Composite diagram is, in fact, a Nested diagram.
I disagree with both the Gemini interpretation of what a Composite diagram is as well as your assertion that it is actually a Nested Diagram.

The UML Composite Structure Diagram is a particular type of diagram that shows the internal structure of a particular namespace. EA generalizes that to include Composite behavior and allows new types of Composite diagrams to be defined in a profile. Neither requires actually being nested within in the Namespace it is documenting. EA defaults to that behavior but allows the diagram to be in another namespace, while UML doesn't have anything to say on it.

And yes, Gemini did conflate the two terms and you used that conflation to argue your point.

15
What is the exact code you're using?

Pages: [1] 2 3 ... 541