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 - Arquesoft

Pages: [1] 2 3 ... 8
1
Bugs and Issues / Re: Unable to move Interface on a Port, on a Class
« on: June 21, 2018, 08:30:48 am »
What if you move it via the Project browser? (change the element it belongs to)

2
Bugs and Issues / Re: Saving long urls
« on: June 21, 2018, 08:29:51 am »
Use a url shortener like https://goo.gl/

3
Bugs and Issues / Re: Tag values mixing groups (ver 13.0)
« on: June 21, 2018, 08:28:58 am »

I thought yu had already done that procedure...  What you have defined is the standard process for manually redefining a metatype.  If you don't do the steps of making sure you have cleared the StereotypeEx properties (where you unmark the checkbox of the non-current stereotype) then EA doesn't recognise the metatype correctly (Ask me how I know?  ;))


The reason I hadn't do that was there were hundreds of elements with that issue. I really was looking for a script (jscript or SQL) solution, but I really had to fix it by hand, one by one. They are now all fixed. But I still look for a script that has the same effect.

4
My final solution was:

1. Create a script that change the _icon folder definitions for every stereotypes in every profile in my MDG.
2. Use a folder easy to replicate in different computers (eg: C:\EA\MDG\icons). Avoid folders related to desktop or user based locations
3. Share in another tool (version control system, dropbox, sharepoint, drive, etc), the profiles XML, the icons, MTS file, MDG file and an export of searches in XML.
4. MTS folder definitions refers to C:\EA\MDG folder
5. Search XML has to be imported in the secondary computer generating MDG.

5
Did you buy it or just have the trial version?

6
Bugs and Issues / Re: Tag values mixing groups (ver 13.0)
« on: June 06, 2018, 11:52:25 pm »

BTW: Is it reproducible?  If you put the original stereotype back, does it revert and then revert again as you put the new stereotype back?

Paolo

It worked! the solution is:
1) Apply the undesired stereotype by drag&dropping from the Toolbox pressing Ctrl over the conflicting element.
2) Uncheck the desired stereotype from the checkboxes in the Stereotype attribute of the element. At this point, the tag values are all grouped in the wrong stereotype group, but are all in the same group.
3) Apply the desired stereotype by drag&dropping from the Toolbox pressing Ctrl.
4) Uncheck the undesired stereotype from the checkboxes in the Stereotype of the element.

7
Bugs and Issues / Re: Synchronise Stereotype via API odd behaviour
« on: June 06, 2018, 07:56:21 am »
I have a more complicated case similar to this, in the following post: https://www.sparxsystems.com/forums/smf/index.php/topic,39943.0.html

8
Bugs and Issues / Tag values mixing groups (ver 13.0)
« on: June 06, 2018, 07:52:18 am »
I have a MDG containing profiles. I created a stereotype called "Application" and another one called "Platform", both extend Component metaclass. Both have the same tag values, and the tag values are organized in groups (as both extends the same metaclass, the groups definitions is in the single metaclass element).

I have made several versions of the MDG (every 3 months it happens an update), so I have different elements in different versions of the profiles. The situation about versioning is similar as described here: https://www.sparxsystems.com/forums/smf/index.php/topic,39829.msg245210.html#msg245210

Then, I changed some elements, changing their stereotypes from Platform to Application. To do so, I have a script that allows to do it for a large number of elements simultaneously, selected from a diagram.

After doing that (and experimenting some issues as described in the post of the link above), I manually "fix" the data in the stereotype, and in the t_xref table. It seems to be simple: I had to erase the reference to the Platform stereotype in the t_xref row related to "Stereotypes" and I noted that there is a row in t_xref related to "CustomProperties" containing the tag grouping definition for the element. As the two profiles has the same tags and groups, it is not required to change the t_xref CustomProperties data (there is no reference in this rows related to the profile name.

So, the issue is: after changing the stereotype of the element, the tag grouping is showing the tag values grouped in a weird way, like this:

ProfileName::Platform
-Group A
--Tag 1
--Tag 2
--Tag 3
-Group B
--Tag n
--Tag n1
--Tag n2
ProfileName::Application
--Not grouped tags

What is expected:

ProfileName::Application
-Group A
--Tag 1
--Tag 2
--Tag 3
-Group B
--Tag n
--Tag n1
--Tag n2
--Not grouped tags


The Description in the t_xref for this cases is: @STEREO;Name=Application;FQName=ProfileName::Application;@ENDSTEREO;
(previously it had two definitions of @STEREO (one for Application and one for Platform), so I fixed it manually directly in the database)

9
General Board / Re: How to set page size in RTF templates (ver 14)
« on: June 04, 2018, 12:05:40 pm »
I have just re-tested it. Version 14 build 1421. When opening a previously created template (master template, model template, cover page, or table of content template) the options are disabled as mentioned previously.

10
General Board / Re: How to set page size in RTF templates (ver 14)
« on: June 04, 2018, 10:48:13 am »
I think its under 'Edit' Ribbon, File -> Printer Setup  (or Page Layout)

But when editing a template this option is disabled! I have only enabled "Page Layout" and "Print preview". So, "Printer setup" and "Print" are disabled. I don't know why. (Page layout is just for defining margins)

Different when editing a Linked document of an element. In this case, Printer Setup is enabled and it allows to set the page to Letter.

11
General Board / How to set page size in RTF templates (ver 14)
« on: June 04, 2018, 08:20:18 am »
I'm creating Virtual Documents (master and model documents) and the default page size for all is A4. I need to set the page size as "Letter", but can not find the option in the master document template nor the model document templates. I did know how to do it in version 12, but can't find the option now. Do you know how to do it now in version 14?

12
I'm experimenting the same issue. Extending metaclasses is not working as always. Build 1421

13
@qwerty: I'm not pretending to generate the MDG "dinamically". It just have to be updated from time to time (aprox once, every 6 months). This is because we create new stereotypes we have not considered before, or add/modify tag values to old ones.

@Geert: previously I considered MDG generation as a thing created in setup time. That is why we didn't create any special way of storing the MDG, except the profile definition itself in the model. Your approach seems logical to me, so I will make the suitable changes in order to consider the MDG generation as a code compilation. Thanks.

Really I was expecting some solution as "make an environment variable and...", but the solution of Geert seems fine.

14
Hi, I would like to read your opinions about a good strategy in order to let different users to generate a profile (or MDG), having in mind the icons are defined as local file for the user is creating the profile.

The scenary and restrictions are:
  • There is a shared model in a database
  • Multple users want to update the profiles via re-generating the profile files and the MDG files
  • The profile definition exist in the same model (so, we have to generate the MDG and import the MDG in the same model)
  • It is not possible to have a shared folder to share the icons

Do you know any way to define the icon folder via a parameter or something not depending on the user creating the stereotype in the profile?

15
Bugs and Issues / Re: Synchronise Stereotype via API odd behaviour
« on: June 01, 2018, 01:32:27 am »
Sure, qwerty, but the t_xref table apparently stores an identifier of the GUID of the stereotype (or profile, or MDG, or something that is different for every publication of the new version of the profile). I suppose it could be useful if you return to a previous version of the profile, or to check if the version of the tag values of the element matches the tag values of the profile. (just guessing)

Pages: [1] 2 3 ... 8