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

Pages: 1 [2] 3 4
The problem is related to the Style attribute after creating the diagram object.  After creation of the diagram object, the Style is set to its default of "".  My port placement scripts were retrieving the Style attribute and setting the OX, OY and ROT to fixed values.  The CX and CY values were intended to be unaltered.  My logic for parsing the Style to extract CX and CY and did not take into account that Style may not be populated; Style is always populated when elements are manually added to the diagram. Since no CX or CY values exist in the Style, the parsing would result in NaN (not a number). The value written to Style would then have CX and CY as NaN.

I have scripts that I use to position component ports and corresponding labels on diagrams; one script places the labels inside the component boundary next to the port and one script places the labels outside the component boundary next to the port.

On diagrams that I create manually (drag component onto diagram, enable ports of interest, etc), these scripts properly move the ports and their labels as expected. I can move these ports and labels around, run the scripts and the ports and labels are moved back to their position. Nothing unusual here.

I created a script that creates a diagram, adds components and their ports to the diagram.  Running my port/label placement scripts results in the ports being moved to their expected positions on the component boundaries.  The labels however appear to at their default position (outside the component, slightly below the port and extending away from the component).  If I move the port manually, the label remains that the same positional offset from the port.  I can manually move the label on the diagram.  When I run my scripts, the port is moved back into position but the label does not move where I expect; the label remains at the same positional offset from the port after I had manually moved them.

If I hide the ports for a given component on that diagram (select component, right-click, Structural Elements, None) and then show the ports (select component, right-click, Structural Elements, All), the ports and labels go to the positions that would occur if I manually dragged the component onto the diagram.  When I run my scripts, these ports and labels get moved into proper position; the labels for ports on other components continue to remain in their default positions.

Is there an attribute for these diagram objects that needs to be set to allow the labels to be moved?

Thanks Geert. 

I have prototyped a similar "work-around" using SQLQuery but don't like the fact that the APIs provided don't support very large models and don't provide feedback that the Collection can not hold the number or elements returned. I would like to see the old Collection class and APIs superceded or at least updated to provide user feedback regarding error; new APIs / classes should be created to support large complex models. 

If the Count field is going to be declared as a short, return count as -1 to indicate the number of results is too great and can not be contained in a container; otherwise, why use a short to begin with?  Returning -1 would at least allow the automation to detect the condition and operate in a predictable manner (generate an error if count if <0 to indicate the tools must be updated to use SQLQuery or new APIs/Container classes).

With the ever increasing sizes of models and information stored in these models (associations), the likelihood of having more than 32767 elements returned by a query (using GetElementSet) is almost certain.  Upon reaching this point, the automation tools used would need heavy re-work to address this limitation.  Mechanisms would need to be put in place to detect this condition and alert the users that the automation tools will not function.

To avoid this (and maintain backward compatibility), can new classes and APIs be defined that do not limit the count values to shorts (eg. GetElementSetExtended that returns and an EA.CollectionExt class which contains Count as an unsigned int). Changes to the automation tools would be done through search and replace in the majority of cases. Detection of this overflow condition could be done by comparing the count values returned in the two different collection classes. 

Bugs and Issues / DAO.QueryDef[3219] Invalid operation
« on: March 15, 2017, 03:20:23 am »
I have seen the DAO.QueryDef[3219] error being generated in EA 12.1 when the number elements returned by GetElementSet is "too big".  This same issue has been reported by others on the forum.  The specific size where this occurs is not clear. 9443 elements fails;  8119 elements passed.

This error does not get generated with a DBMS repository.  It appear to occur with a stand-alone JET 3.5 database.  I have been informed by a counter-part the EA 13 appears to not generate this error.  I have also observed that setting the "Use JET 4.0..." option results in the error no longer appearing even though the database itself is still a JET 3.5 database.

The issue is caused by the size limitation on a collection and with Collection.Count being a Short.  94002 is what is returned by the SQL scratchpad; truncation of 94002 (0x16F32) to a short yields 28466 (0x6F32).  In my case, my query is greater than 32767 so the count is no longer valid (either reported as negative value or a bogus positive value).

Sorry for the delay in responding.  In the picture shown by q below, when I click on "a" in the tagged values window, the sub-pane shows the notes that were populated in my MDG.  I like this.

If there were notes captured in the MDG for that attribute "a", the sub-pane just shows the name of the tagged value.  I am OK with this since there were no notes in the MDG.

For the parent class, the sub-pane always re-iterates the profile::stereotype (name). In the MDG, I have notes captured for these stereotypes that I would like to be shown in the sub-pane.  The behaviour applied to the tagged values within a stereotype should be extended to the stereotype itself.

I have created an MDG with numerous stereotypes.  These stereotypes have various attributes.  Notes have been populated for the attributes and the stereotypes.  When I create elements of these stereotypes, the notes from the attributes in the MDG show up in the TaggedValues window when I have selected a specific tagged value.

The notes for the stereotype itself do not show up.  The split pane is in the TaggedValues window is empty. If I click on the element type in the TaggedValue window, the split pane shows the same information; Class (XYZ) is shown in the pane for an XYZ class.  When clicking on tagged values, the notes that were defined in the MDG show up in the split pane.

I would like a way to display the notes associated with the stereotype in the MDG to be displayed.  These note provide references regarding where the stereotype is defined, how it is used, etc...

Thanks Q.  Will submit a feature request.

General Board / Displaying notes associated with a stereotype from MDG
« on: March 03, 2017, 11:46:36 pm »
I have created an MDG with numerous stereotypes.  These stereotypes have various attributes.  Notes have been populated for the attributes and the stereotypes.  When I create elements of these stereotypes, the notes from the attributes in the MDG show up in the TaggedValues window when I have selected a specific tagged value.

The question is "Is there a way to display the notes from the stereotype itself?  Is there a window where the notes from the stereotype would be displayed or an option?"  If I click on the element at the top of the Tagged Values window, the notes area just displays the same information, it does not display the notes from the corresponding stereotype.

I am using 12.1


Bugs and Issues / Re: Default(?) Relationship Matrix Issue
« on: January 05, 2017, 04:54:23 am »
This works. I found that opening another project and setting Type to something never used (eg Screen) would allow me to get past the issue but I was concerned about other team members, new projects, etc..  My work instructions can be updated to indicate the Relationship Matrix should be opened via the ProjectBrowser instead of the Tools menu to avoid the scenario where Type is set to <All>.  Thanks!

Bugs and Issues / Default(?) Relationship Matrix Issue
« on: January 04, 2017, 03:47:06 am »
When opening the Relationship Matrix, EA hangs (or at least I give up waiting) because the profile (default?) is attempting to show all elements within the Model node.  My current model has over 100k elements.  How can I either clear the current matrix so that it does not attempt to display anything when I open the Relationship Matrix?

Automation Interface, Add-Ins and Tools / Re: Parallel script execution
« on: November 23, 2016, 05:40:07 am »
The problem is related to xmi files that are being imported.  Connections between elements in these xmi files are captured as qualified paths.  So after importing these xmi files, connections need to be established between various elements so that if an element is later moved, the relationship is still captured (the textual relationship could be updated based on the connection between two elements.

The script is expected to look for these tagged values and see if the referenced element exists.  If so, a connection between the elements is created.  Otherwise, a warning is logged to indicate the referenced element does not exist.

I will look into C# but had heard that performing various processes outside EA generally took longer than doing these from internal scripts. In this case, the ability to run multiple concurrent jobs might be beneficial.

Automation Interface, Add-Ins and Tools / Re: Parallel script execution
« on: November 17, 2016, 06:12:52 am »
Some additional info.  I have split one of these scripts into multiple smaller and run them from multiple instances successfully with a significant performance improvment (all 8 cores on my computer working hard instead of just 1). 

A background on the problem.  I have a significant number of classes that contain references (full qualified path) to other classes as tagged values. The script should use these tagged values to create connections between the source element and the referenced element.  One of the problems has to do with duplicate classes and non-unique element names. For example, if 2 components have a common interface (one provides and one requires), both components may define the same interface. The tagged value for one component would point to its interface definition within its package structure. An SQL query on all interfaces having a specific name would return multiple results.  A check of the fully qualified path would be needed to ensure the correct element is being connected.

I would like to make my script(s) work smarter and reduce the results from the SQL queries.  One thought is to use the Alias field to hold the full qualified path of all my elements. Doing so would allow me to do an SQL with the full qualified path instead of just the element name, stereotype, etc.. Is there any issue with using Alias for this purpose? Does EA use this for anything specifically?

Automation Interface, Add-Ins and Tools / Parallel script execution
« on: November 07, 2016, 11:28:51 pm »
With a DBMS repository, it appears possible to run multiple scripts simultaneously. I believe I could run multiple instances of EA and run a different script in each instance or alternatively multiple users could each run a different script from their machine. Currently, I have some scripts that significant amount of time to execute (eg. 16 hrs). Some of these scripts could be split up and executed in parallel (eg. each script operating on specific stereotypes).

Has anybody had any experience with running multiple scripts in parallel and seen a reduction in overall execution time?

Pages: 1 [2] 3 4