Messages

1

General Board / Re: SysML. Show nested IBDs

« on: Today at 01:52:54 pm »

On the diagram above, you can see the "suppressed" arcs in the Set Visible Relations dialog, yes?  Now, drag the C1 item outside the B1 item and you should now see the arcs made visible.  Is that so?  Then drag it back inside, they disappear. yes?

Now in all those scenarios, the "Visible" setting was set to true in the dialog, yes?  That's why I don't use the word hidden but suppressed.

So, there's no way to achieve what you want in the current version.

You can hide the "suppressed" arcs so that they aren't visible when you unenclose the item, but you can't make them visible, while suppressed.

You may care to lodge a bug report using the links below.  Personally, I think it's a defect, that you can't make explicitly visible a suppressed arc.

Paolo

PS: there may be a cheeky way to (almost) achieve your aims.  Move the C1 item down so that the bottom edge of the C1 item is 1 pixel, below the bottom edge of the B1 item (and thus, normatively, NOT enclosed).  The arc between B1 and C1 may become visible.  I say may because the presence of ports makes things a bit more complicated.

2

General Board / Re: Tagged Value Type Format

« on: Today at 01:30:19 pm »

Thanks, Paolo for your response.

If I create the tag value checklist, can the defined options be populated from a CSV Import?

For example, in EA I add a tag type checklist named "Group Options" with the values: All, Group 1, Group 2;

In the CSV specification file, column heading = TagValue_Group Options. Values in the rows = above-mentioned options.

Does the row value check the applicable box in the defined checklist or is a CSV strictly a text format (i.e, In EA a label is created, Group Options, value = row entry.

Cheers,
Chris

It's pretty much strictly a text format.  If you searched the forum you'll see it's a while since I gave up on the Checklist.  Not that it's wrong (well, yes, there are issues with it as I noted at the time); it just didn't suit my needs.  But you should have a look in the t_objectproperties table to see what EA does with it these days.

Paolo

3

Automation Interface, Add-Ins and Tools / Re: How to stop EA "hijacking" stereotypes via API?

« on: December 14, 2018, 06:48:05 pm »

Not so fast, Batman!

It seems for our setup we haven't quite got the "ducks" in a row.  Our Composition relationship is still problematic.

But based on the last few days, I'm going to take it more slowly.

Following Simon's injunction to Check on a profile created by an EA model, we confirmed that our handcrafted MDG entry for our Composition (Composite Aggregation) arc appeared to be correct:

Code: [Select]

<Stereotype name="Cmpstn" metatype="Composition" notes="" cx="200" cy="100" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">
{Image and Icon entries removed for clarity}
         <AppliesTo>
<Apply type="Composition">
<Property name="compositionKind" value="Composite at Target"/>
<Property name="direction" value="Source -&gt; Destination"/>
<Property name="_SourceMultiplicity" value="1..*"/>
<Property name="_TargetMultiplicity" value="1"/>
<Property name="_lineStyle" value="orthogonalS"/>
</Apply>
</AppliesTo>
</Stereotype>
E.g. this stereotype Extends the Composition Metaclass (via the <Apply> entry)

Can this be confirmed, please?  That is, that this arc should behave like a normal Composition.

Tired,
Paolo

4

General Board / Re: Tagged Value Type Format

« on: December 14, 2018, 11:59:55 am »

"Warning, Warning, Will Robinson!"

When we say checklist we normally mean a "multi-option list" where one can optionally select a number of the options - from zero to all.

However, a Sparx Tag of type Checklist is truly a Checklist: a list of items, like names or tasks, for comparison, verification, or other checking purposes.  You check the items off as you go through the process.

So it can't be used for the purposes you are intending.  There also are usage issues with the type as defined, which you should be able to find with a search of the forum.

Paolo

5

General Board / Re: SysML. Show nested IBDs

« on: December 14, 2018, 11:53:58 am »

Hi, le-Chiffre,

A couple of things.  What I see on the diagrams is Visual Enclosure, not Nesting, to show composition.  Search the forum for visual enclosure or visual embedding (a previous term - now deprecated) to see the difference.

As such, you are a "victim" of arc suppression with visual embedding.  I say "victim" because what you are seeing is the intended outcome (You don't see the relationship when you visually encircle one item with another).  It's just not what you were expecting.

If you Show Visible Relationships [Ctrl+Shift+I] you should see the "missing arcs".  Unfortunately for you, they will be shown as visible (when they aren't).  There appears to be no way to make them visible again.

Let us know if that is the case, as it could be argued there's a defect in this behaviour.

Paolo

6

Automation Interface, Add-Ins and Tools / Re: EPPRofile:: ?

« on: December 14, 2018, 09:25:33 am »

OK, OK, I got lazy "once" and paid the price!    I normally use Super Finder XT.

Happy Friday, everyone! 

Paolo

7

Automation Interface, Add-Ins and Tools / Re: How to stop EA "hijacking" stereotypes via API?

« on: December 13, 2018, 07:51:54 pm »

I can confirm Simon's statement regarding StereotypeEx.
In my code, I almost never use the Stereotype Field.
After setting the StereotypeEx field I would expect the Stereotype field only to be filled in after updating and reloading the element.

Simons tip about setting the qualified metatype is even better. Should remember to apply that in my own code.

Geert

It turns out my local EA 1427 was corrupt!    Repairing the setup made my machine work consistently with others.

Even after I repaired the computer I was getting anomalous results.  However in the last half an hour, things seemed to have settled down.

BTW: in 1427, Setting SetereotypeEx also sets Stereotype, even before the update.

As to Simon's point about "Strong", I never mentioned Strong.  This code is DEEP inside a library and used for all sorts of arcs.  So we set Subtype to the value passed in, in the call.

As it happens, the behaviour was anomalous when we passed in a Type of Aggregation and a Subtype of Strong, but we think we've now tracked it down to an error in our handcrafted MDG.  We ARE trying to move to a generated MDG. 

This code is a VBScript port of code that has worked in VBA (apparently) satisfactorily for nearly a decade.  Hence my perturbation.

It seems I picked the wrong example to start with...  (typical  "Cantoni effect" - point me at a system and I'll find the one anomalous issue)  If I'd started with another arc metatype on a machine with a valid EA install, I might have tracked down the problems myself.

So, believe it or not, thanks to everyone for their help!

I still believe the search algorithm is questionable, but it shouldn't apply if the automation is correct.

Relieved,
Paolo

8

Automation Interface, Add-Ins and Tools / Re: How to stop EA "hijacking" stereotypes via API?

« on: December 13, 2018, 03:50:55 pm »

I've got it to work EVEN with an entry in the General Stereotypes for "Cmpstn".

However the following VBScript code

Code: [Select]

Set foundConnector = oEAPackage.Connectors.AddNew(gs_EMPTY_STRING, sConnectorType)
foundConnector.Subtype = sConnectorSubtype
foundConnector.ClientID = orginEAElementID
foundConnector.SupplierID = destinationEAElementID
foundConnector.StereotypeEx = "MDG::" & stereotype
foundConnector.Stereotype = stereotype
foundConnector.Name = name
Session.output "6St="&foundConnector.Stereotype&"= StEx="&foundConnector.StereotypeEx&"= FQS="&foundConnector.FQStereotype&"="
on error resume next
foundConnector.Update
Session.output "11St="&foundConnector.Stereotype&"= StEx="&foundConnector.StereotypeEx&"= FQS="&foundConnector.FQStereotype&"="

Generates the following output:
6St=Cmpstn= StEx== FQS==   
11St=Cmpstn= StEx=Cmpstn= FQS=MDG::Cmpstn=

(for all the 5 arcs in the loop)

Note the change in ordering of the setting of StereotypeEx vs Stereotype

Anybody care to explain the differences in output?

As an experiment, I then commented out the "foundConnector.StereotypeEx = "MDG::" & stereotype" line.
By now, it won't be a surprise to you that it STILL worked!

Final (and further testing - taking time out of my day job) has revealed that if the General Stereotypes entry for "Cmpstn" is NOT present, EA will create one, and (as noted in previous posts) the first will be a GUID and the rest MDG correct.  Whereas, if the General entry is present, all 5 will be correct!  That's why nos 2-5 are correct!

I await someone to tell me I'm not doing it right or that EA is making apposite decisions.

Astounded,
Paolo

9

Automation Interface, Add-Ins and Tools / Re: How to stop EA "hijacking" stereotypes via API?

« on: December 13, 2018, 01:08:48 pm »

BTW, In this repository, User Security is NOT enabled so I can't disable Configure Stereotypes.  In any case, we're talking about automation, not UI stuff.

The Help system says:
The system checks the loaded and enabled Profiles and Technologies, and the Stereotypes table, for a  stereotype with a matching name and base type. If it finds a match, it links to that stereotype and applies the effects. If it doesn't find a match, it creates a new stereotype name in the Stereotypes table and links to that - the stereotype acting as a simple label.

Therefore:

If you don't want the element's stereotype to match with an identically named stereotype located by the system, either:
     -  Disable the Technology that owns the stereotype
     -  Unload the Profile that owns the stereotype, or
     -  Delete the stereotype from the stereotypes table
If you do want the stereotype to match to a specific stereotype in a Profile or Technology, load the Profile or enable the Technology.

AFAIK, I did all these things (In spades - since the ONLY enabled Technologies was our own) and EA still got it wrong!

What is the rationale for finding a match OUTSIDE the scope of the action when there IS a match within the scope?  AND, as per my previous post, getting a different answer in the same loop!

Rita Mae Brown (apparently NOT Einstein) said:  “Insanity is doing the same thing over and over again and expecting different results.”
Sending someone else insane is “Doing the same thing over and over again and providing different results.”

Paolo

10

Automation Interface, Add-Ins and Tools / Re: How to stop EA "hijacking" stereotypes via API?

« on: December 13, 2018, 12:47:06 pm »

NO, I specifically excluded ALL but my active MDG

You prevented them from showing in the toolbox etc. That's all that option does. The other technologies are explicitly still available to ensure existing models using them still appear correct.

That's a strange use of the term "Active".  I thought unmarking the MDG list stopped the toolboxes from appearing.  Since you can ONLY set ONE of any enabled MDGs to be active I would have thought, by definition,  "All enabled MDGs are created equal, but the active MDG is more equal than others".  But in these post-truth times, I guess anything goes.

I understand (and agree) that the other technologies should be available to ensure existing models still render correctly.  BUT we're NOT talking about existing models, we're talking about new arcs!  Surely, EA should try to match the stereotype in the MDG of the diagram the arc is being created on?  If not, then we're really NOT on planet Sparx.

If you need any more proof that "She Brok"! (as my mum would say...)

We have code that creates 5 composition arcs in a loop.  Before the test, the general stereotypes are cleared of the specific MDG related uniquely named stereotype ("Cmpstn").  The test is run and "lo and behold", the first arc (by ID) creates a new general stereotype whose value is the unique name "Cmpstn" and the arc is created with a t_xref entry referencing a GUID.  Now for the REALLY BROK bit... The subsequent 4 arcs have been created with the correct MDG FQName t_xref entry!  Go figure!

What a way to build a battleship!

By definition, it should look in my (Active) MDG FIRST then if not found, look elsewhere!  What so hard about that concept?

The concept is easy. The problem is that your definition doesn't match the actual definition of that option.

Does this process ENSURE you DON'T get a general stereotype anomalously created?   That is, it will NOT (in your experience) create "MyProfile::Goal" (as we have seen).

From 1425, EA blocks creation of new stereotypes containing "::". You shouldn't see them created. The other thing I would suggest is to disable the Configure Stereotypes for all users. This will prevent extra stereotypes being defined from typos etc.

As Geert said, always use the fully qualified name. If you don't, EA will try to guess your meaning. And it will probably get it wrong.

Where is the use of the fully qualified name documented?

So I tried to do what is suggested in VBScript

Code: [Select]

foundConnector.Stereotype = stereotype
 foundConnector.StereotypeEx = "MDG::" & stereotype
Setting the breakpoint at the second statement, foundConnector.Stereotype is set to the value of the Stereotype ("Cmpstn").
After the StereotypeEx assignment, both foundConnector.Stereotype and foundConnector.StereotypeEx are set to empty string!  I'm assuming that's NOT supposed to happen.  So what, if anything am I doing wrong?

Exasperated,
Paolo

PS: the caching issue around scripts and debug vs non-debug mode aren't helping and adding to the exasperation!

11

General Board / Re: No XSD type found for: "XType" Defau is: xs:string

« on: December 13, 2018, 09:29:29 am »

Dorian,

10 years is nothing to a man with a portrait in his basement :-)

Especially on planet Sparx.

EA even provides a special theme for Dorian. 

Paolo

12

Automation Interface, Add-Ins and Tools / Re: Fix Multiplicity and Cardinality, once and for all!

« on: December 12, 2018, 08:57:17 pm »

A bet a bottle of beer against a Beetle that it won't be fixed in 5 years.

q.

Not gonna take you up on that!

I posted mainly to see if in 10 years "is still brok" (Italglish for Broken).  It's been brok for the last 10 years, I'm sure.

Paolo

13

Automation Interface, Add-Ins and Tools / Re: Multiplicity to denote (persistent) Instances?

« on: December 12, 2018, 08:56:57 pm »

To me a 1-multiplicity is a synonym for a singleton. And that I usually stereotype with <<singleton>>. I can't imagine any other multiplicity classification besides that.

q.

Yes, conceptually they are singletons, but the item already has a stereotype (to denote the metatype).  We have determined that each item will have ONLY one stereotype (denoting the metatype).  Makes life a LOT simpler!

Also singletons are normally rare (and I suspect, like objects, are really denotations for runtime items) but persistent specific instances aren't.

Paolo

14

Automation Interface, Add-Ins and Tools / Re: How to stop EA "hijacking" stereotypes via API?

« on: December 12, 2018, 02:59:50 pm »

PS: Nevertheless, it IS a bug isn't it?

Why? You've asked EA to find a Goal stereotype and assign that to the element. That's exactly what it has done.

NO, I specifically excluded ALL but my active MDG - which DOES contain a Goal stereotype and it found one in the TARDIS!  What's more, it didn't find MY (active) one and didn't give me the option of choosing which (of at least 3 possible) I might want to select.

So, if I have an ONLY Project Management MDG active and EA decides to give me a GOAL from Eriksson Penker that's fine?

By definition, it should look in my (Active) MDG FIRST then if not found, look elsewhere!  What so hard about that concept?

Paolo

15

Automation Interface, Add-Ins and Tools / Re: EPPRofile:: ?

« on: December 12, 2018, 02:46:02 pm »

The id of the technology is EP. EPProfile comes from the profile name.

Remind me NOT to use Windows Search.  It didn't show up "EPProfile " as the content of ErikssonPenker.xml.

I should have used my normal search mechanism.

Obviously, Search is harder than it looks, given the number of issues we have with it.  ("No names, no pack drill"  )

Paolo