v15.2 - bgcolor and bordercolor NOT being generated in profile.

[Paolo F Cantoni]

In our handcrafted MDG, we define (for a specific item) the

Code: [Select]

bgcolor="15658671" fontcolor="16711680" bordercolor="10766755" borderwidth="2" We get the rendering that we want.

It was my understanding (and in the past, it seemed to work, the last time I did it via MDG Generation - years, and versions, ago) that you create the appearance you want in the profile diagram, make the appropriate checkboxes in the profile export and voila!

Instead, although the rendering is as desired in the diagram, and the underlying DB has the correct values:

Code: [Select]

Backcolor Fontcolor Bordercolor BorderWidth
15658671 16711680 10766755 2
We get:

Code: [Select]

bgcolor="-1" fontcolor="16711680" bordercolor="-1" borderwidth="2" in the output profile!  This is the same for ALL the exported stereotypes.

I presume we are doing something wrong - perish the thought there's a bug in the process.  Any ideas?

TIA,
Paolo

[Geert Bellekens]

Have you tried to set the default appearance (F4)?

Geert

[Paolo F Cantoni]

Have you tried to set the default appearance (F4)?

Geert

Yes, that's exactly what I did and I confirmed the right values ended up in the repository (when they didn't end up in the MDG).

Since I first posted, SOME (but not all) of the changes are coming through.  Not sure what I'm changing...

Paolo
[Edit: They've gone again!  It seems to be related to the background generalization tree we use (in order to maintain a high level of consistency in the generated MDG)  I'll investigate further, but there's another issue more pressing in the Generated MDG which I'll post separately - missing <AppliesTo>]

[Geert Bellekens]

Yes, I've noticed that too, the MDG generation looses colors when executed via automation.
Not sure if I reported it as a bug yet.

Geert

[Takeshi K]

From the UI, if we generate a Profile from a Package (i.e. select target Package in the Browser), elements' color (i.e. F4) is used for the Profile. If generate from a Diagram, diagram objects' color is used.

Shoule be the same in Automation. If we use Repository.SavePackageAsUMLProfile, elements' color should be used, and SaveDiagramAsUMLProfile should use diagram objects' color.
(I have not checked actual behaviour yet.)

[Paolo F Cantoni]

From the UI, if we generate a Profile from a Package (i.e. select target Package in the Browser), elements' color (i.e. F4) is used for the Profile. If generate from a Diagram, diagram objects' color is used.

Should be the same in Automation. If we use Repository.SavePackageAsUMLProfile, elements' color should be used, and SaveDiagramAsUMLProfile should use diagram objects' color.
(I have not checked actual behaviour yet.)

I am not using automation scripts, I am using the UI.  The colour attributes seem to have returned. It would seem to be IS related to the loss of <AppliesTo> sections.  Why, is an EAUI defect (In our view).  There would appear to be NO functional dependency. I may formally put in a Defect Report.

Paolo

[Edit: I spoke too soon. It just seems to be random!!!!]
[2nd Edit: I was right the first time!  If you have removed the «metaclass» item from the profile diagram the colours will not be emitted.  I can understand stereotype (metatype) not on diagram, don't emit it, but having to add the «metaclass» item as well, since the definition of the metatype is incomplete without it is EAUI!  And why it affects the emission of 2 of the five properties is just nonsensical!]
[3rd Edit: As an example of Sparxian generated frustration, I found the problem to be still, random!  After a WHOLE day of debugging, I think I have now got to the bottom of what is happening!.  From my experience, on my setups^[1], the profile generation problem in v15.2 (1554) is FUNDAMENTALLY BROKEN!!! It needs to be fixed ASAP as the correct generation of MDG files depends on this functionality working.  I will post more details in the next post and related Defect reports.]

^[1] I put in that caveat, but my analysis is that she is just "BROK".

[Paolo F Cantoni]

I thought I had it sorted with v14, but that's not the case, from generation to next generation of the profile, the colours are either there or not.  I haven't been able to find any rhyme or reason (each time I get an "aha" moment, sometime down the track, that also gets "clobbered")

I tried to create a profile from a package, but that didn't work either (probably my inexperience)  it just created an empty profile.

Can anyone help me to create a profile under a package?  I just want to create a profile with stereotypes in it - the <stereotypes/> section of the MDG.

What I did was just create a profile package and then place the diagram under it.  I suspect I needed to place the items in the diagram and any associated items (such as metaclasses etc.).  What I need is the simplest structure to emit the <stereotypes/> section of the MDG.

Grateful thanks in Advance...

(A very haggard!) Paolo

[Geert Bellekens]

Hi Paolo,

If you put all stereotypes (and metatypes, and enumerations) in your package it should generate the profile from the package.

I do have a couple of profile that I generate from diagrams (the main reason is that there was a bug that disabled generating a profile from a package in the corporate edition)
In none of them I have this problem with the colors. When I do it manually it works just fine. Only when generating from a script it doesn't work.
You do make sure the diagram is open when generating right?

(come to think of it, what would happen if I open the diagram before exporting the profile in my script? Something to try next week... )

Geert

[Guillaume]

Hi Paolo,

I'm using Build 1554 as well and the stereotypes custom colors are applied properly.
I use the publish the Package as UML Profile menu and make sure Color and Appearance + Element Size options an enabled.

Have you got these options enabled?

[Paolo F Cantoni]

Hi Paolo,

I'm using Build 1554 as well and the stereotypes custom colors are applied properly.
I use the publish the Package as UML Profile menu and make sure Color and Appearance + Element Size options an enabled.

Have you got these options enabled?

Yes, I do, thanks, Guillaume.  Thanks also to Geert.  Our MDG is HIGHLY structured with generalizations and extensions all over the place.  When it works, "it's MAGIC!", but...

Part of the problem is that there appear to be problems with generalizations - more later.  I suspect that no one has tried the generation with anything NEAR as complex as what we are doing! Given some of the defects were finding (in trying to solve the issues), it's pretty obvious the functionality is broken.

Paolo

[Paolo F Cantoni]

OK, I got the sample generation from a package working and it DOES seem to use the Default Appearance rendering from t_object as Takeshi-san said.

However, it ONLY does it for stereotypes that are directly under the package not for those that we have nested under nested packages.  Can anyone confirm that it will not traverse any package nesting (which we use to group our MDG stereotypes and metaclasses)?  In the diagram generation, the nesting of the packages is NOT a problem.

The other good news is that this is working under b1554.

TIA,
Paolo

[Uffe]

Hey Paolo,


I've run a few very simple tests on 15.1.1528. I hope they can be of some use to you, or to Sparx when and if they get to fixing this.

Setup:
    Root
        View
            «profile» MyProfile            {Package; version 1.0}
                MyProfile                  {Class diagram; version 1.0}
                «metaclass» Class
                «stereotype» MyStereotype
                    FlagTag: Boolean

MyStereotype has an Extension to Class, and the diagram contains both elements and the connector.
There are nothing in any Notes fields, and there are no shape scripts or appearances set. Straight from the box.


Publication method differences

If you publish this profile from the GUI, you get the following:

<?xml version="1.0" encoding="windows-1252"?>
<UMLProfile profiletype="uml2">
    <Documentation id="1CA78D9B-7" name="MyProfile" version="" notes="MyProfile"/>       <-- Diagram version
    <Documentation id="6453A0AE-1" name="MyProfile" version="1.0" notes="MyProfile"/>    <-- Package version
    <Content>
        <Stereotypes>
            <Stereotype name="MyStereotype" notes="" cx="96" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">    <-- Diagram version
            <Stereotype name="MyStereotype" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">      <-- Package version
                <AppliesTo>
                    <Apply type="Class">
                        <Property name="isActive" value=""/>
                    </Apply>
                </AppliesTo>
                <TaggedValues>
                    <Tag name="FlagTag" type="Boolean" description="" unit="" values="True,False" default=""/>
                </TaggedValues>
            </Stereotype>
        </Stereotypes>
        <TaggedValueTypes/>
        <ViewDefinitions/>
        <Metamodel/>
    </Content>
</UMLProfile>


The id attributes in the <Documentation> elements are taken from the GUIDs of the diagram/package, so they won't be the same if you recreate this. But the other differences are things that EA decides to do differently. When publishing from the diagram, EA does not pick up the diagram version and suggest it in the Save UML Profile dialog (although you can of course enter one yourself), and when publishing from the package, it sets cx and cy to 0.


Element location

If you publish from the diagram, element location doesn't matter. The result is the same whether the metaclass and stereotype are both in, both out, or one in and one out, of the package where the diagram resides.

If you publish from the package, things are different.

• If just the metaclass is in a different package, the result is the same as if everything is in the profile package.
• If just the stereotype is in a different package, the result is an empty <Stereotypes/> element.
• If both the metaclass and the stereotype are in a different package, the profile publication fails with the error
  Syntax error (missing operator) in query expression 'Start_Object_ID in () or End_Object_ID in ()'.

Stereotype appearance (F4)

If you change the stereotype's appearance to something rather hideous, you get the following change in the published profile:

    <Stereotype name="MyStereotype" notes="" cx="96" cy="70" bgcolor="16748574" fontcolor="65535" bordercolor="2263842" borderwidth="2" hideicon="0">    <-- Diagram version
    <Stereotype name="MyStereotype" notes="" cx="0" cy="0" bgcolor="16748574" fontcolor="65535" bordercolor="2263842" borderwidth="2" hideicon="0">      <-- Package version

If you then reset the stereotype's appearance, it doesn't reset properly in the diagram: the border width is still thick, even though the Default Appearance dialog reports it as 1 (which is the default) and shows it as thin in its preview.
Generating from this now somewhat broken model yields:

    <Stereotype name="MyStereotype" notes="" cx="96" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="2" hideicon="0">    <-- Diagram version
    <Stereotype name="MyStereotype" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="1" hideicon="0">      <-- Package version

Note the difference in borderwidth.

So the presentation of the stereotype element in the diagram has not been properly reset. The diagram version of the profile has the old border width (which is still shown in the diagram), while the package version has a border width of 1, which is what the Default Appearance dialog claims it is, but which is not what gets published for a stereotype that has the actual default border width (defaults are -1).

The Default Appearance does not allow you to change the border width to -1, and changing it to anything else has no effect: whether that's because it only allows a single change ever, or whether it gets stuck after resetting to defaults I can't say.


/Uffe

[Paolo F Cantoni]

Thanks, Uffe,

Good to see it's not just my setup.  I came across all the issues you've mentioned.  PLUS and it's a BIG plus if you start to have non-default colouring (both background and line) things get more complicated.  If I just wanted bgcolor=-1 or bordercolor=-1 I wouldn't have seen the issues!!!

It's quite clear that resetting the appearance - DOESN'T!   The line width is NOT reset!
It's also the case that if there the Diagram rendering is the same as the Default rendering, then the settings are -1 (which is fine!). The problem is that the profile generation for diagrams should not just emit the -1 but emit the default value!      Naturally, with EAUI consistency, it does it properly for the fontcolor and the borderwidth, but NOT the bgcolor and bordercolor!  Interestingly, if I "jam" the t_diagramobject with the correct values for the properties, the generation still emits the -1.  I suspect that as it reads the diagram, EA notes that the Default and the diagram are the same and resets the in-memory value to -1 - which it then emits! 

I don't know who tested this at Sparx, but...

Paolo

[Paolo F Cantoni]

Hi All,

I've just tried to find the automation method to emit an MDG profile, to no avail.  It's very early in the morning and I have a headache from the last few days of debugging.  Can some kind soul point me at the relevant help sections (or just provide the method name so I can look it up)?
[Edit: Found it after a cup of coffee.  Looking for the wrong text.  MDG Profile instead of UML Profile. SavePackageAsUMLProfile (string PackageGUID, string Filename)]

Another question.  We have 4 basic groupings of stereotypes which I would like to retain as separate packages.  I propose to emit each separately via automation and then "combine" them in the MTS file to generate a single XML.  Is that viable?
[Edit2:  I tried it manually and it seemed to work.  Can anyone confirm there are no downstream issues?]

[Edit3:  Found one downstream issue:  I need to name each emitted profile as <My Profile Name>.  However, when EA aggregates them, it generates a duplicate Name error (because the Profile ID is taken from the Package GUID).  I can fix this with a bit of post-processing.]

TIA,
Paolo

[Eve]

            <Stereotype name="MyStereotype" notes="" cx="96" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">    <-- Diagram version
            <Stereotype name="MyStereotype" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="-1" hideicon="0">      <-- Package version

... when publishing from the package, it sets cx and cy to 0.

This is what I would expect. It can't use the size the stereotypes appear in the diagram when you're exporting the package. Personally, I think the size the stereotype is rendered in the profile diagram is almost always tangential to the size the instances of those stereotypes should be rendered to anyway.

Element location

In either case it exports the stereotypes found in the export location. Yes, there is a bug where no stereotypes exist but that's a meaningless result even if it worked.

Stereotype appearance (F4)

It's going to export with the style available at the level of the export. Which means if you have defined a style at the diagram level it isn't going to change the package export. If you set the default appearance that can be overridden in the diagram export.

If you then reset the stereotype's appearance, it doesn't reset properly in the diagram: the border width is still thick, even though the Default Appearance dialog reports it as 1 (which is the default) and shows it as thin in its preview.
Generating from this now somewhat broken model yields:

    <Stereotype name="MyStereotype" notes="" cx="96" cy="70" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="2" hideicon="0">    <-- Diagram version
    <Stereotype name="MyStereotype" notes="" cx="0" cy="0" bgcolor="-1" fontcolor="-1" bordercolor="-1" borderwidth="1" hideicon="0">      <-- Package version

Note the difference in borderwidth.

Looks like the element still had a border width of 2 set at the diagram level, which will change the rendering but not impact the default appearance dialog (which is a level below where it has been set) or the package generation. Nothing broken here except possibly whatever set the diagram level border width.