Sparx Systems Forum

Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on May 16, 2010, 06:16:51 pm

Title: QuickLinker - allowing Unstereotyped definitions
Post by: Paolo F Cantoni on May 16, 2010, 06:16:51 pm

EA Help for QuickLinker says:
Exclusive to ST Filter +
No inherit from Metatype
 If set to TRUE, indicates that elements of type Source Element Type with the stereotype Source Stereotype Filter do not display the Quick Linker definitions of the equivalent unstereotyped element.
However, it doesn't say how to GET both this and the unstereotyped element to display.

I tried both "FALSE" and blank but to no avail.

The only way to get the unstereotyped definitions to appear was to disable the MDGT.

Can anyone give me the "secret sauce"?

TIA,
Paolo

Title: Re: QuickLinker - allowing Unstereotyped definitio
Post by: Paolo F Cantoni on May 17, 2010, 05:47:28 pm

Thanks to Sparx Support for the solution:

The values have to be either "TRUE" or blank.  In the case of blank, they ALL have to be blank:
If your quicklinker definition has just one matching line with ExclusiveToStereo=TRUE it won't run the second pass to display the non-stereotyped matching rows.  If you want the non-stereotyped matching rows you need to make sure that every stereotyped matching row has ExclusiveToStereo left blank.

(I had a couple of "critters" hidin' under a log...).

However, as I pointed out to Sparx in my thanks:
If I have multiple QuickLinker Defintions active, should ANY denial of the inherit in ANY definition override grant (as in standard permissions patterns)?

Thoughts?
Paolo

Title: Re: QuickLinker - allowing Unstereotyped definitio
Post by: «Midnight» on May 17, 2010, 08:06:29 pm

Hey Paolo,

I ran into this a while back. More by accident than intent I ran into the solution, though I've not been sure of that until reading Sparx' response.

So far so good, but...

Your point about multiple definitions is interesting. The design as Sparx explains it seems fragile. It is almost as if the current behavior, whichever way it works, is due to side effects. It feels like the design makes sense for a single QL instance, but 'just works that way' when there are multiple instances.

IMHO this could be a bug, or a bug waiting to happen, depending on your preferred answer to Paolo's observation to Sparx and how the product behaves.

David