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

Pages: 1 [2] 3 4 5
When a tag grouping is changed in an MDG the Synchronized Stereotype function does not update the grouping on existing elements.

(almost a) work around: Move existing elements to a diagram.
However when there are hundreds of elements than Sparx freezes when dragging the elements on the diagram. Equivalent to Sparx CRASHING.

This bug makes Sparx EA look like a toy. Users are very disappointed.

This is our third request since 2016 for a descent work around (program, script.. whatever).

Suggestions and Requests / Re: Suggestion: Tooltips
« on: December 19, 2017, 03:32:47 am »
We need this feature!

Bugs and Issues / Re: Virtual Connectors do not execute Shape Scripts
« on: December 13, 2017, 09:46:59 pm »
OK. Let's say it is an incomplete implementation and as a result, virtual connectors are useless when MDGs are used.

I wonder what is the percentage of users that do not use MDGs?

Bugs and Issues / Virtual Connectors do not execute Shape Scripts
« on: December 13, 2017, 03:28:10 am »
When we create a virtual connector, only the original item is displayed as requested by the shape script.

The ghost is ill-mannered as it simply ignores the shape script. I mean the ghost doesn't bother and it shows as a UML element.

Is there a trick for taming the ghost in the shape script or is it simply a bug?

If it is a bug (ghosts can also have bugs), will this be fixed for version 14?


Users very often have to maintain several diagrams that share common elements including their layout.

When we drag a source diagram 1 into target diagrams 2 and 3, one additional option (besides "diagram frame" etc...) would be to
- drop the laid out source diagram objects from diagram 1 into the target diagrams 2 and 3 (not a picture)
- keep the target diagram layout synchronized with the source diagram layout
That way, in each target diagram 2 and 3 we can re-use the layout of the source diagram 1 and add specific elements and connectors.

In other words, in each specific target diagram, we should be able to re-use a source diagram as a "dynamic layer of connectable diagram objects".

Example 1:
- Shared/Common part of the diagram:  Business Function Landscape
- Specific diagrams: Information owned by functions, Organizations performing functions, Applications supporting functions, Domain architect in charge of function, functional heat map, roles that belong to functions...

Example 2:
- Shared/Common part of the diagram:  Organization structure
- Specific diagrams: Organization Managers, Organization Locations, Organization-owned Applications

OK Simon :)  Indeed it could be fixed only by improving and simplifying the UI and the configuration features (though I still believe it would be simpler to have UML, BPMN or whatever language defined altogether from scratch).

At the end of the day, users of our MDGs would be happy if they had...

a) A single list of properties (not tag) which are editable either in shapes, in property windows or in catalog sheets.

b) Automatic validation of connectors based on the metamodel, and of properties based on properties validation rules

c) Quick links which are transparently derived from the metamodel (without these extra quick links that we cannot get rid of).


(a) would require some filter defining which properties and tags need to be visible, in what sequence and for which role
The catalog sheet (like a spreadsheet) would require some sort of element lists which are dynamic and editable. Dynamic legends could also be applied for creating catalog heat maps.

(b) and C) can be implemented either using a metamodel or a language metamodel. For example, we implemented the second option in this language metamodel:

The advantage of a language metamodel is that it can be more easily used for language documentation as it is easily understandable by modelers.


Sparx shines thanks to its UML implementation. But the focus on UML and low levels abstractions is also an impediment.

We should be able to create languages without any UML profile.
The user experience, the architecture and the implementation of Sparx might be simplified if languages could be defined independently of UML.

We should be able to create elements, connectors, properties, shapes, metamodels and other consistency rules from scratch.

The language author would create
- Element and connector types (no stereotype)
- Properties (not tag)
- User-defined shapes (not derived from any UML type)
- Properties validation rules (including but not limited to enumerations)
- A metamodel (defining possible combinations of elements and connectors)

The end user of the language would enjoy a simplified user experience user i.e.
- Element and connectors types (no stereotype)
- Properties (not tag) which are editable either in shapes, in property windows and or in catalog sheets (result sets)
- Automatic validation of connectors based on the metamodel, and of properties based on properties validation rules

UML (and legacy UML profiles) would be languages as any other.

When we lock a package, and the locking gets propagated into the elements in the package, other individuals or groups shouldn’t be able to change or delete connectors connecting elements in the locked package.

In other word, when an element is locked, its connectors should be implicitly locked as well.

Note that this could also be an option, in which case you need different types of locking.
So this is for you an opportunity to use the field LockType in the table t_seclocks.
Today this field is always empty.


Automation Interface, Add-Ins and Tools / Paste diagram objects by code
« on: September 18, 2017, 07:46:57 pm »
Selecting diagram objects seems to be OK: The Diagram class has a collection property called SelectedObjects that we can read and write to.

But I can't find a way to paste the selected data objects into another diagram (by code).

Any idea?

Thank you all for your useful answers

When we mix different types of element... in some cases (it seems random), we are no longer able to move SOME elements (not all of them) up and down by using CTRL-Up or CTRL-DOWN or by using the menu option "Move up" or "Move down" on the element.
In addition, the option 'Content / Reset Sort Order" does not sort these elements.

Any idea how to resolve this?

Thank you in advance,

Automation Interface, Add-Ins and Tools / Protecting some MDG
« on: March 09, 2017, 08:47:32 pm »
If we want to make a product out of an MDG, what is the best way to protect it from reverse engineering?
- MDG as part of the database?
- MDG as part of an add-on?
- ...?
Thank you in advance

Thank you. That sounds like a good idea. We will give it a try.

Is there any way to update elements programmatically even when they are locked?
This is needed when a language gets migrated (Stereotype, tag name changes...).

As an alternative, how could we
- Save the locks to a file
- Release all locks
- Reload the locks from the file

Is there any option to define the lookup package for each tagged value type of type RefGUID or RefGUIDList?
The syntax for defining tagged value type is: Type=RefGUID; Values=Activity;Sterotypes=MyStereotype

We are looking for something like an extra tagged value type specification like "Catalogue={some refGUID of a package}"
Type=RefGUID; Values=Activity;Sterotypes=MyStereotype; Catalogue={some refGUID of a package}

PROBLEM when using multiple Tagged Value Types of type RefGUID or RefGUIDList :
When the value of a RefGUID or RefGUIDList tagged value is not set, The lookup always starts from the last accessed package location for all tags.
This makes the option of using RefGUID and RefGUIDList unacceptable for our end users.

Pages: 1 [2] 3 4 5