1
Bugs and Issues / Re: v16β - Shapescript for shape Label doesn't react correctly
« on: May 17, 2022, 09:15:52 pm »Hard to beat!hallelujah, hallelujah
I prefer G.F. Handel.
q.
Paolo
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.
Hard to beat!hallelujah, hallelujah
I prefer G.F. Handel.
q.
MyBad, then. Sorry!No, it works for connectors as well. (at least in v15.2.1559)Hey Modesto,What selection criterium did you use? You'll have to make sure your object flows are included in your selection.I have tried with Filter set to Connector - None, Connector - Type, or Connector - Stereotype, and Applies to set to ControlFlow or ObjectFlow depending on the type. The end result is always the same, no change.
Are you able to get the Legends working with ANY connector? I have a sneaking recollection that they don't actually work with connectors[1]. Perhaps others can correct me. I just checked our common legends and NONE apply to connectors, only shapes.
HTH,
Paolo
[1] Perhaps, another case of connectors being second class citizens?
We use that to indicate the lifecycle on our architecture diagrams for both elements as connectors.
Geert
Hey Modesto,What selection criterium did you use? You'll have to make sure your object flows are included in your selection.I have tried with Filter set to Connector - None, Connector - Type, or Connector - Stereotype, and Applies to set to ControlFlow or ObjectFlow depending on the type. The end result is always the same, no change.
I don't think I've looked at it at all since that discussion.That's, effectively, how we went. Our placeholder items are generalizations of specific items. However, we have TWO kinds of specializations: (the more common) inheritance (IS A TYPE OF) and restriction (IS WHERE). The specific items are restrictions on the placeholders. You can consider the placeholders the equivalent of a query "A Data Owner is an X where". If the specific item meets the query requirements, then it is a restriction on the placeholder.
From memory, ArchiMate is a bit weird. I believe it actually recommends modelling instances as a specialization of the type. So if you have an instance of 'Data Owner' that you want to model, you create a new Business Role with a specialization to Data Owner.
AH, its amazing what a good rant will do for you.Concistency, konsistency, consistensy! TMUffe - after Paolo
About 10 minutes after I finished the last post I realised what I had done wrong.
The _AttPkg, etc attributes are inverse from the others (i.e. 1 = hide).
All working nicely, now onto the next bugs :-)
Thanks guys :-)
According to the documentation, setting it back to -1 should work: https://sparxsystems.com/enterprise_architect_user_guide/16.0/add-ins___scripting/diagramobjects.html+1QuoteBackgroundColor
Long
Notes: The background color of the object on the diagram.
Set to -1 to re-set to the default color in the model.
So if that doesn't work it's officially a bug.
Geert
Thanks, Geert! To answer your question: We are currently in requirements capture. If relationships from other requirements diagrams appear here, it will disturb rather than help. Later in the requirements analysis, of course, all relationships must be taken into account, but in our current phase, we would like to freeze the diagram for the time being.Hi Bernhard,
Regards,
Bernhard
Sparxians,Confirm it's not been fixed. I'm surprised, to be honest as they've taken so long to release V16 I thought they would have fixed that. That bug will prevent my organisation from upgrading as we use an MDG to extend ArchiMate. What is interesting is that the extra label doesn't appear on all ArchiMate extended objects so it points to some inconsistent coding.(my emphasis)
Very disappointed this hasn't been fixed.
You said it! I thought I had given sufficient information for the problem to be tracked down and eliminated (unless, like the VCE problem, there's a fundamental design problem).
I would've thought getting inheritance correct in this area would be crucial for making EA more flexible AND CONSISTENT!
Paolo
Sporry folks, I wasn't explicit enough. I installed the 32-bit version first and then the 64 -bit. Thus there was a registered Addin in the 32-bit world (which I checked with 32-bit EA). I then copied the 32-bit entries manually to the 64-bit Registry path and an Addin showed up in the 64-bit EA. I didn't test it out.As per Sunshine's response. If you install the 64-bit version, you'll find it doesn't follow the release notes about where to place the 64bit AddIn information. If you add that info manually, it enables the Addin.Well tried installing the 64-bit version this weekend however like potterm I can't see it in Sparx EA V16 64 bit, as doesn't seem to see it.
HTH,
Paolo
What do you mean by the above comment? Looked at release notes and am not sure what you mean by adding that info manually. what info and how?
Confirm it's not been fixed. I'm surprised, to be honest as they've taken so long to release V16 I thought they would have fixed that. That bug will prevent my organisation from upgrading as we use an MDG to extend ArchiMate. What is interesting is that the extra label doesn't appear on all ArchiMate extended objects so it points to some inconsistent coding.(my emphasis)
Very disappointed this hasn't been fixed.
Thought I saw two new Office MDG on the download page. One for 32bit and the other for 64bit.As per Sunshine's response. If you install the 64-bit version, you'll find it doesn't follow the release notes about where to place the 64bit AddIn information. If you add that info manually, it enables the Addin.