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.

Topics - Paolo F Cantoni

Pages: 1 ... 74 75 [76] 77 78
This is nice functionality, but I couldn't see how to do it by automation.  Is it possible?


Doesn't seem possible...  (as of build 847).

Is that the case?

project.LayoutDiagramEx (string DiagramGUID, long LayoutStyle, long Iterations, long LayerSpacing, long ColumnSpacing, boolean SaveToDiagram)
only  applies to the legacy layout function - Yes?

Any ETA on it?


Automation Interface, Add-Ins and Tools / Changing the Diagram Type
« on: July 17, 2009, 05:07:42 pm »
With the UI, you can change the diagram type.  How can you do it via Automation?  The Attribute is READ-ONLY.


public void SetConnectorCustomProperty(EA.Connector connector, string propertyName, string propertyValue)
    EA.CustomProperty oCustomProperty;
    for (short iCustomerPropertyIterator = 0; iCustomerPropertyIterator < connector.CustomProperties.Count; iCustomerPropertyIterator++)
        oCustomProperty = (EA.CustomProperty)connector.CustomProperties.GetAt(iCustomerPropertyIterator);
        if (oCustomProperty.Name == propertyName)
            oCustomProperty.Value = propertyValue;

Fails when attempting to set the diagram with a (to me) spurious error:
"EA_MenuClick: Element no longer available"

Anyone know how to set Custom Properties for Connectors?


Hi All,

Am I correct in asserting that there is no Automation Interface mechanism to GetPackageByPath?

GetPackageByID and by GetPackageByGUID exist, but there is no way to find a package by its named path (for example: Model::View::Parent::Self)

Similarly, there's no equivalent get Element yes?


Before I send of a bug report to Sparx, I thought I 'd ask the automation gurus if there was any way to completely remove any trace of a newly create (by automation) diagram and then reload it to simulate a manual open/reload of the diagram?

Effectively to flush the diagram from the EA cache!

I have a strong suspicion that something is "hanging around" but I don't know enough about the AI to ensure I've eliminated the diagram.


In EA 7.5 (844) - on my machine - Repository.GetDiagramByGuid throws an exception if the diagram with that GUID doesn't exist, rather than return a null object.  Is this by design or has a bug crept in?


Automation Interface, Add-Ins and Tools / REAL Connection String
« on: May 08, 2009, 01:11:20 pm »
When accessing an EA repository, there are three scenarios1:
  • .EAP file (via File|Open)
  • .EAP file (via Connection String)[/color]
  • Server hosted database (via Connection String)
  • Server hosted database via shortcut (Connection String embedded in shortcut)
The EA API (as mentioned in a number of posts) has a Repository.ConnectionString attribute.

Repository.ConnectionString: String; Read only. The filename/connection string of the current Repository.

Unfortunately (again, as mentioned many times), there is no standard mechanism to return the actual connection string (suitable for using in an OLEDB Connection) in all these three situations.

Can anyone (hint: Sparxians) provide a best practice code to detect which scenario is being invoked and to return the actual connection string in each scenario?


1 (if there are more, let me know and I'll update this)

Those of you who have dabbled in the EA data model within the EA repository will know that stereotype information is held in two places:
The primary stereotype is held within the appropriate table for the type of item. the auxiliary stereotypes are held in the t_xref table with an GUID link back to the appropriate item in the main table.

Now, we have some repositories from a few years ago that we are trying to "bring up to date". It won't surprise you to find that we have found inconsistencies in how EA appears to have handled stereotypes over the years. ;)

We want to standardize the stereotype behaviour so that it matches what EA would now produce (v7.1 build 832).

It would seem that EA's behaviour NOW is:

1) When it creates the primary stereotype, it also puts a matching entry in t_xref.

2) Alternate stereotypes are held only in t_xref

3) Apart from the primary stereotype, the order of the auxiliaries in t_xref determines the order of the auxiliary stereotypes on the UI.

Can anyone (preferably from Sparx) confirm or deny this analysis?


One of the main reasons I chose EA over its competitors is that it is primarily database based.

While Sparx does NOT endorse (or do they :)) direct database manipulation, it's not to hard and over the years I've managed to do a lot of surgery on models in this way.  With the usual caveats of backing up etc - it's a viable way of working.

And it can be blindingly fast...  For example, we've mentioned analysing XMI import/export bugs.  We've built a tool to functionally compare two large models.  If we were to use the baseline compare process (which is actually not appropriate in this context)  we'd have to run it overnight.  Our process takes less than 75 secs from "go to whoa".  Admittedly, we're not checking as much as the baseline compare but certainly enough to diagnose the issues.

In performing surgery we do have a problem in that some db fields are serializations of internal data in the form:


An example is:

Thus for example, to (in this case) change the diagram properties to explicitly show non-navigable AssociationEnds requires changing: TExplicitNavigability=0; to TExplicitNavigability=1;

Managing this kind of change using pure SQL is problematic.

We done some experimenting and it would appear (no surprise given the way the rest of EA seems to work) that there are a number of inconsistencies...  I won't go into the details here but suffice to say that the parsing (or deserializing) of the strings varies depending upon the table and column involved.

Now we want it clearly understood that we aren't asking Sparx to endorse Database direct manipulation.  We are merely asking that EA be consistent in how it processes these columns.   ;D

We propose that deserialization not be dependent on any particular order of name/value pairs; that it progresses from right to left and that if a name/value pair occurs more than once, the rightmost one takes precedence.  Thus in the following example:

TExplicitNavigability=0; is the outcome (the 0 replacing the previous 1).

This would ensure consistency in processing these serialization columns.

Thoughts? Votes?

[size=0]2007 Paolo Cantoni & Darren Sampson, Ripple Systems[/size]

You don't have to post twice...

Your original post will be read and answered if possible.

This is a very active forum.

I would recommend removing this posting and, if you want, enhancing your original post.

If there is no responsed after two days, try rephrasing your question - it may not have been well understood...


Automation Interface, Add-Ins and Tools / Code parser
« on: September 21, 2005, 08:15:19 pm »

A number of us have complained about EA's inability to reverse engineer any method body into the Initial Code Property of the Behaviour tab of the Operation Dialog.

Since this isn't going to happen anytime soon (is it Sparxians?), does anybody know of a good code parser that I could use to parser some code and grab the body of the methods?

I initially need C# but if it was multi-language that would even be better.

(Before anyone criticises me for being inconsistent - "The concept of round-trip-engineering from model to and from pure code is fundamentally flawed".  I only intend to do this once (well, maybe a small number of times;D) )  Thereafter I will be refactoring the code out of the model...


Can anyone confirm what I'm seeing?

In my Emitter Add-On, I can't create local instances of any EA Classes (such as new EA.PackageClass();).

I get EA.PackageClass() is inaccessible due to its protection level.

I can only create instances within the context of the EA collections via AddNew.


Automation Interface, Add-Ins and Tools / Debugging XSD and XML
« on: August 21, 2005, 06:57:44 am »

I've created a (what I think is a) large XSD specification (57Kb).  It represents the UML metamodel which I am emitting from EA.  I've created it with XMLSpy and I'm trying to use it with CodeSmith. I can create a CodeSmith template and reference structures within the XSD in the template.

I have checked the validity of the XSD specification both with XMLSpy and XSD.exe.  Both agree there isn't anything wrong.

However, when I try to access an XML file supposedly built to the specification (which I've emitted from EA), CodeSmith says it can't reflect the topmost type (UMLPlus), because there was an error reflecting the topmost element (Project).

XMLSpy says the the XML file is OK.

However, I have noticed that XMLSpy (v4.4) is not as rigorous as XSD in it's self checking of the XSD.  So it's quite possible there's an internal error in the (quite) complicated XSD that's stopping CodeSmith from unravelling the XML.

Can anyone suggest another mechanism for trying to determine where the problem might be?  I don't think its in CodeSmith, I think there's a problem in the XSD, but I'm not getting enough information from CodeSmith to figure out where the problem is.

BTW, A previous version of the XSD was 55Kb  and was able to be processed by CodeSmith, together with the associated XML file.  I've made quite a few changes and added support for recursive packages ( the Model, View and Package types).


Automation Interface, Add-Ins and Tools / File types - Can they be changed?
« on: September 02, 2005, 12:31:12 am »
The file types in the Files tab of the Classifier dialog...

Are they hard coded?

Or can we change them in some way?


Pages: 1 ... 74 75 [76] 77 78