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] 2 3 ... 89
You either are just more lucky than me. Or the Sparx-God(s) love(s) you more than me (that for sure, anyhow).

It's not about Sparx-God(s), but about people.

I try to remember that in the end it's actual human beings that read our bug reports and decide what to do with it.
And I am sure that these people, the ones that actually write the code of EA, and the ones doing requirements analyses and stuff. I'm sure that they all want EA to be the best tool it can be.

I try to be respectful of their work and not cynical all of the time. Not only because it might help get my bug reports processed earlier, but also because I don't like to be negative and cynical all the time. It affects my personal well-being.

Sure, there are things that can be done better, and there have been decisions in the past (and probably in the future) that I cannot comprehend, but I refuse to let that drag me down into negativity.

That's a nice sentiment to be sure, but what goes around comes around and when Sparx' representatives don't take the trouble to keep a civil tone I for one get somewhat less motivated to make excuses for shoddy design and sloppy documentation.


That functionality uses xml files, but how does it works for *.vbs files?

It doesn't. You can export scripts with the Save As button, but you can't import them that way.

Only way to get a .vbs file into a project (that I know of, and I don't know everything) is to open it in an editor, copy the text, create a new script in the EA project and paste.


Oh, no argument here.

"Why" is probably a bridge too far, but a complete and correct list of UI changes from one version to the next is not too much to ask of a competent tool supplier.

Oops, there I go making blanket statements again.  :-[

Hi Ian,

I don't have a 15.1 installation, but there's a mention on the history page under 1520, section User Interface. It only mentions user default, not model default, but it links to the Desktop Panel page which does say something about the model default.

No idea whether that's accurate or not.


Hi Jenni, and welcome to the forum.

As far as I can tell I don't think there's a way to detect diagram copying as opposed to "from-scratch" creation.

Possibly you could move your note creation to EA_OnPostOpenDiagram or EA_OnPostCloseDiagram. While diagrams need not be automatically opened upon creation, you do need to open them to add things to them, which means that any note-less diagrams should be completely empty. Perhaps that's an acceptable limitation.




If I understand you correctly, you want the document generation process to take the diagram and generate output that looks like the diagram when "View as List" is active.

I'm pretty sure there's no support for something like this, not in 15.0 anyway.
In the template, where you specify what to output from the diagram, you can specify Diagram Image, but there's no Diagram List or similar. I can't find anything in the Generate Documentation dialog either, no option to "output diagrams as list".

However, you could create a template to do it, and it doesn't have to be particularly complex.

It would look something like
    {Pkg.Name}  [if you want]
    [Place a single-row table here and make it a Header Row]
    [Place a single-row table here and insert the element fields you want in the different columns]

This template will output the elements shown in the diagram as a table, but not the diagram image.



General Board / Re: Shape script - Println types
« on: January 21, 2020, 06:25:47 pm »
Hi Ferran,

If you have a strict, repeated set of properties you could represent them as tagged values instead of attributes. Tagged values can be accessed in a shape script.

But it sounds like you're doing more source-code-like concepts, and in that case tagged values probably aren't useful; you need the freedom that attributes provide and as Q mentioned, attributes simply aren't accessible in shape scripts. Operations aren't either.


Bugs and Issues / Re: Elements appearing twice in generated documentation
« on: January 20, 2020, 06:14:10 pm »
Hi Ewout,

Not sure precisely, but I would guess the repeated items are used in two different ways in the model.

The template could list an element in one part, and then include it in another because it is connected to another element that's being documented there.

It's hard to say exactly, but you can actually look in the templates to see what they do, even the built-in ones. In the document generation dialog, click Open Template to bring it up.



General Board / Re: How to query the parent of an object of a classifier?
« on: January 17, 2020, 11:25:15 pm »
Hi Richard,

Not sure why you're working with GUIDs, the Object_ID is generally the better option.
That said, and not knowing anything about the specifics of your model structures:
  • A lifeline would be an instance of a business entity, so lifeline.Classifier would join entity.Object_ID.
  • The interaction would be the parent of the lifeline, so lifeline.ParentID would join interaction.Object_ID.

The classifier is also expressed as t_object.Classifier_guid, so that would work with what you've already got.
However, the ParentID has no GUID equivalent, you have to use the Object_ID for that.

If you haven't kept your interactions separate with one sequence diagram in each interaction, you'll probably need to go through the t_diagram/t_diagramobjects route to find what's used where.



Hi Matthias,

You missed one type there: MDG Events. :)

In terms of responding to these events there's no difference betwen them, but you have to set up your Add-In a little differently for some of them and they are handled differently by EA.
  • Add-In Events are received by all Add-Ins.
  • Broadcast Events are received by the Add-Ins that implement them. EA queries the Add-In DLL to find out which events are relevant, you don't need to do anything in code.
  • MDG Events are received by those Add-Ins which register themselves as "MDG" Add-Ins in their response to EA_Connect().
  • Workflow Events, similarly, are received by those which register as "Workflow" Add-Ins in EA_Connect().
So you have to explicitly register to receive MDG and Workflow events, you get Broadcast events because you choose to implement certain interfaces, and the Add-In events you just get.

Don't know why Sparx has chosen to use two different ways of deciding which events to send to which Add-Ins (DLL inspection on the one hand and registration on the other), but hey -- koncistensy.



PS I haven't actually investigated any of this, it's just what I've read in the API documentation which might be complete rubbish.
Wouldn't want to be accused of making blanket statements.

Ahhh, I see.

I'm afraid that EA's BPMN implementation is not built using EA's standard extension mechanisms, as I've described them above.
You'll note that changing the Type in that dialog causes other things to happen, it isn't just a selection of one of a set of possible values for one tagged value. A humble MDG Technology smith such as myself couldn't customize a dialog like that.

So this is a custom implementation of a property dialog which behaves in a non-standard way. I think your best bet is to contact Sparx support.


Hi again,

If I understand correctly, you're after the set of possible values for a tag, rather than the specific value of a tag in one element.
If so, you probably can't get that through SQL.

Tagged value type definitions can be created in-project (Configure - Reference Data - UML Types), in which case they're stored in t_propertytypes. But they can also be located in MDG Technologies, which are XML files the client reads and keeps in memory. Definitions found there are not written to any table.

All Sparx-supplied technologies (such as BPMN) are located in the install directory, eg C:\Program Files (x86)\Sparx Systems\EA, under the sub-directory MDGTechnologies. You can look in there for the tagged value definitions, the format's reasonably readable.

Note also that not all tagged value types have enumerable values. They can be free-text, or references to model elements (known as "RefGUID" tags), or any one of a couple of dozen other types.




Those are tagged values, which are stored in t_objectproperties, which you can join with t_object on Object_ID.
The name of each tagged value (activityType, taskType, ...) is stored in the Property column, and the content in Value.



General Board / Re: Length of traceability
« on: January 15, 2020, 12:28:59 am »
Hej igen,

Limiting yourself to EA's document templates only (and not using any script template fragments) I don't think it's possible.

You can get a list of all activities, and for each a sub-list of the "created" and "used" information items.
Or you can get a list of all information items, and for each a sub-list of the "creating" and "using" activities.

But EA's built-in document generator simply follows the package structure and cannot follow connector chains. When generating a (part of a) document for one element (with that element "in focus" so to speak), a template has access to the element's connectors and some details about the element at the other end, but it can't "refocus" on that element and follow its connectors.

The only way I know to do arbitrary-length connector chains is to script it, either using the DocumentGenerator API or possibly script template fragments.


Hi all,

From the documentation on ISBPIIntegrationPlugin.GetDefaultTypeMapping, it appears that external data items can only be mapped to element types, and from ISBPIIntegrationPlugin.GetDefaultFieldMapping, it appears that external data fields can only be mapped to tagged values or EA's built-in element properties (eg modified date).

Is this correct?

Or is it possible to map external items to
  • packages?
  • reference data (eg requirement types)?
and/or external fields to
  • attributes?
  • operations?


Pages: [1] 2 3 ... 89