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] 4 5 ... 9
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:,39943.0.html

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:,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:

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

What is expected:

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

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.

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.

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?

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

@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.

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?

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)

Bugs and Issues / Re: Synchronise Stereotype via API odd behaviour
« on: May 30, 2018, 08:44:13 am »
It is a known issue for me. When you have had several "version" of your MDG (profile), it is possible you have several elements, each one using a different version of the profile stereotype. When this is the case, you can note that t_xref table stores the reference to the GUID of the stereotype in which the element was created. So, it is possible to have different elements of the "same" stereotype, with different entries in the t_xref table, referencing the "same" stereotype but in different versions.

What have I done? Some of the above, but I have found it doesn't work 100% of times:
  • Delete manually the stereotype entry in the Stereotype configuration window
  • Delete the t_xref entries for the stereotype and the element (note there could be different entries in this table for the element, not concerning to the stereotype)
  • Run your script that syncronize the tag values
  • Restart the application, and if it is an shared database, make the other users restart the app.

If you use Cloud Server (it is free and very easy to install), the Cloud Server can generate periodically the points of the graph if you use the second alternative and your query strategy for postgres. If I were you, I would use the query.

Are you using legacy reverse engineering? Have you tried Database Builder?

Two approaches:

1) Avoid automatic calculation of timeseries chart (which only works when having Cloud Server), and manipulate the data of the chart via a custom script that calculates your data and stores it in the suitable tag value of the timeseries chart (the data is stored as an XML). Just a programming solution.

2) Use some query that returns as rows as the value of your current dot in the graph. For example, the following SQL returns 10 rows (change the 10, and return different number of rows). Works in SQLServer:
Code: [Select]
SELECT TOP(10) 'true'
FROM sys.columns AS a CROSS JOIN sys.columns AS b

I created a C# console app that works fine in development environment and in production environment (windows server 2008 R2 64 bits) but only when executed manually. When scheduled in Windows Task Manager it throws the following exception:

Retrieving the COM class factory for component with CLSID {67F4E0FA-46A7-4255-B084-69A9433D08C3} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).

I followed the instructions described in:

But when trying to find the EA.App component in the Component Services windows, it is not listed, as shown:

Even in my local PC (windows 10, 64 bits), the EA.App is not listed. Note the shortcut of the comexp executable:

I followed all the instructions in the previous links, even in my local PC but the EA.App is never listed in the Component Services window, so it becomes imposible to configure full launch permissions to this component.

Any ideas?

As it seems there is no way to include triggers in the template editor, you can explore the database in order to determine how your triggers are stored. Then, you can do a Document fragment to get the information of you trigger via an SQL. After that, just include your fragment into your document.

Pages: 1 2 [3] 4 5 ... 9