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

Pages: 1 ... 25 26 [27] 28 29
Automation Interface, Add-Ins and Tools / Re: Windows DEV NOOB
« on: February 20, 2010, 07:28:43 am »
To add to Geert's comments:

I did forget the bit about adding the registry entry that EA needs to find the add-in. Here's a sample .reg file showing where in the registry you would need to place the entry for your add-in:

Code: [Select]
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Sparx Systems\EAAddins\Specifyx]
In the sample case, the name of the add-in is "Specifyx", and the name of the add-in assembly is "Specifyx.Connector". This would be the assembly name of the .dll for the COM-visible class created to "wire up" your add-in to EA.

Fred W

Automation Interface, Add-Ins and Tools / Re: Windows DEV NOOB
« on: February 19, 2010, 01:44:11 pm »
I've done several add-in projects for EA using Visual Studio (several versions) and C#, and the process is really straightforward. I usually start with a "Connector" class that is registered for COM interoperability (a project properties option; just a checkbox, in fact, so no special coding is required) and event handlers for the various EA events along with methods for connecting, providing the menu interface with EA, etc. I then dish out work to supporting classes, including GUI elements, based on EA events handled by the Connector class. All of it is laid out well in the EA SDK help, BTW.

The beauty of writing add-ins for EA using the .NET framework is that you don't need to get involved in the complicated mess that is COM and ActiveX - the .NET COM interoperability layer takes care of that for you.

Fred W

Automation Interface, Add-Ins and Tools / Re: Undocumented features - AI
« on: February 12, 2010, 12:00:53 pm »

Depending on the version of EA you have, you

1. Pick a package in your model hierarchy in the Project Browser where you want to import the AI, then
2. Right-click on the desired package, then click on "Code Engineering->Import Binary Module..." , then
3. Navigate to the directory where EA.exe lives (usually C:\Program Files\Sparx Systems\EA or C:\Program Files (x86)\Sparx Systems\EA) and select Interop.EA.dll as the file to import.
4. Click "Import" and EA will import all the interfaces and classes in the AI into your model. It will even lay out the diagram with the entire AI for you.

Good luck,
Fred W

Automation Interface, Add-Ins and Tools / Undocumented features - AI
« on: February 12, 2010, 09:34:37 am »
As a result of responses to forum posts and some poking around in the object model (importing the EA AI into EA is truly a wonderful thing...), I've run across a few undocumented features, to wit:

    CustomCommand(String, String, String) : String (I already know this can be used to sync stererotypes... thanks Neil!)
    Execute(String) : Void
    CreateModelWatcher() : ModelWatcher (the ModelWatcher is described in the help, but the factory method isn't described)
    SuppressSecurityDialog : Boolean
    EnableEventFlags : Boolean

    GetCodeProject(string*, string*) : Void
    SetCodeProject(string, string) : Void
    GetClassCodeObjects(String) : CodeObject
    GetCodeObject(string) : CodeObject
    ShallowGetClassCodeObjects(String) : CodeObject
    GenerateSourceCode() : Void

There may be more...

Would Sparx be so kind as to indicate which of these methods may be used without risking model implosion, how they are used, and, eventually, document these things in Help?

Fred W

Automation Interface, Add-Ins and Tools / Re: Regasm does not work
« on: February 05, 2010, 03:42:04 am »

This (copying the .dll to the EA directory) is the approach I take since this appears to eliminate the "missing" dll issue. It would be interesting to find out how to get things working reliably regardless of where the dll is installed.

BTW, and totally off topic - does anyone besides me think that "regasm" is an... errrrrr, "unfortunate" name for a utility?


Automation Interface, Add-Ins and Tools / Use of _profile_data tag
« on: February 05, 2010, 02:21:04 pm »
Does anyone know the significance/use of the _profile_data tag applied to a profile package? Its value is stored in the tag Notes field (as a <memo>* value) and appears to be XML associated with the profile (<ProfileData/> by default).

Fred W


Brilliant! Just what I needed!

(But whereas the customer giveth and the customer taketh away...)

I note that this method isn't documented in the User Guide, and I suspect that there are other "custom commands" that could be issued that would render my recently-filed (and not yet issued, even) feature request redundant. When can we expect the Help & User Guide to be updated accordingly?


I have the following scenario:
  • I create a new Element using the AI.
  • I assign the Element just created a stereotype from a profile created previously.
  • I now want to synchronize the Element with the profile to ensure that all tagged values, shape scripts, etc. are applied to the new Element.
How would one accomplish this using the AI?


Hi Pedro,

I have posted a similar question and have also logged a formal support request regarding opening up t_document for customized use by add-ins. Sparx hasn't gotten back to me yet, but maybe if you were to post this as a formal support request they might prioritize the issue.



Works like a charm! Thanks again for the help.



I wish I'd thought of that! Thanks, Geert! I will do some tinkering along the same lines and let you know how it works out. Brilliant!

As a side note, I tried the same thing with AbiWord instead of WordPad, primarily due to the fact that there appears to be a rather large version gap between the RTF version in Windows 7 WordPad and that used in the Windows Forms RichTextBox (which uses, I think, v1.6). This causes some formatting changes which, while minor, are annoying. AbiWord seems to do a better job at preserving the formatting. The interesting thing is the "wait" WORKS when using AbiWord (although an annoying "busy" box pops up in the add-on). The busy box doesn't appear when using WordPad (or at least it didn't).


I'm working on a .NET requirements management add-in for EA that integrates viewing of linked documents together with the normal requirement attributes (and then some). To allow advanced editing of the linked documents (beyond the editing capability offered by a .NET RichTextBox), I fire up Wordpad and load the linked document into it (after saving the linked doc to a temp file); this allows the user to remain within the add-in environment to do fancy editing without having to open EA's document editor. The add-in then "waits" for Wordpad to close, reads the modified file back into the linked document, then updates the display. The problem is the "wait" doesn't wait at all... the add-in blows right through the wait statement and updates the linked document with the original temp file - in other words, without the changes made in Wordpad. Adding a message box to the code, however, forces a wait (until it's closed at least); this "fixes" the wait problem and the update to the linked doc is now successful.

Here's the (C#) code:

Code: [Select]
private void editToolStripMenuItem_Click(object sender, EventArgs e)
            bool res;

            if (this.processEditor == null)
                this.processEditor = new System.Diagnostics.Process();
                this.processEditor.EnableRaisingEvents = true;

            tempdoc = Environment.GetFolderPath(Environment.SpecialFolder.Personal) + "\\EA_" + Guid.NewGuid().ToString().Replace("{", "").Replace("}", "") + ".rtf";

            processEditor.StartInfo.FileName = Strings.AdvancedEditor; // C:\Windows\write.exe in this case
            processEditor.StartInfo.Arguments = tempdoc;

            processEditor.WaitForExit(); // This happens immediately; it doen't wait for the process to exit...

            MessageBox.Show(processEditor.HasExited.ToString()); // This provides the required wait to allow the process to exit!

            res = theRequirement.LoadLinkedDocument(tempdoc);
            res &= theRequirement.Update(); // Unsure whether this is needed, but what the heck.

            this.rtfEditor1.TheRichTextBox.Rtf = theRequirement.GetLinkedDocument();

            processEditor = null;

This seems to be a Windows problem rather than an EA problem, but I'm hoping that the Sparxians or one of our crackerjack EA gurus (and there are quite a few of them on this forum) can offer some advice. It's as if the wait call, viewed metaphorically as a yodeler waiting to hear his/her echo return from across a wide valley (!), has his/her yodel bounced back immediately by an invisible wall (non-metaphorically, the COM barrier of the add-in model or the EA process itself?). I'm no Win32 expert, so this is just a wild guess (a yodel in the dark?)

Fred W

PS: I know, I need to add code to clean up the temp file...


Those are good points and valid concerns. But the concept of "user data" is embraced in a number of applications and domains; why not in EA as well? I'm thinking of things like the "Tag" property in .NET Windows forms objects. The missing piece here, I think, is a commitment from Sparx to support, within limits, "user data" of the type we're discussing. In this way, tables like t_document could be opened up to custom apps wishing to store related custom information provided that they follow certain rules agreed to with or set down by Sparx. In exchange for users following the rules, Sparx could commit to providing proper transfer, replication, etc. of conforming user data.

BTW, that badge in your signature is pretty cool too. 8-)


Just to add my thoughts and observations:

1. I have successfully added tables and queries not only to Access databases linked to the tables in an EAP file but also to database repositories (including Access 2007). EA seems to blissfully ignore the extra objects even though they are directly in the database used by EA.
2. Some tables in EA can be "hacked" to accept entries that EA will ignore but your application could use. For example, the t_document table can hold arbitrary text and binary data linked to elements PROVIDED THAT you set the DocType field for your added row to a value not used by EA. I'm not sure of all of the values EA uses, but they include ModelDocument (for linked RTF docs), DiagramHelper, SSDOCSTYLE, SSMODELDOCSTYLE, and SSBackup. I've tried this with EAP files and other repositories and it seems to cause no grief to EA - it accesses the table data it knows about just fine while ignoring the additional, "hacked" data. I'm currently messing around with an add-in that would do something like this to allow multiple "attachments" to elements of various types in addition to the Linked Document provided by EA. The only problem I can see with this approach is if Sparx decides to change the way they use the affected tables or if name collisions arise due to added features.
3. If you want your app to work completely within the EA universe as defined by Sparx, extra stuff can be associated with elements by adding the appropriate objects to EA, linking these objects to the element of interest, and then adding the extra stuff to the linked objects. For example, the 255 character length limitation for tagged values can be overcome without sacrificing the tag Notes field by creating a class with attributes having the tag names (and types!) desired, creating an instance of the class (an object) linked to the element of interest, then setting the Run State of each attribute to the desired value for each tag. Since the RunState field in t_object is a Memo field, arbitrarily long values can be assigned. (In fact, the RunState field is already a "hacked" field since Sparx packs multiple name-value pairs in the one field using a delimited string.) Similarly, multiple linked documents can be associated with an element by linking several Artifact objects to an element, then assigning a linked document to each Artifact.

Fred W

Automation Interface, Add-Ins and Tools / MDG Add-Ins and Automation
« on: June 02, 2009, 02:08:22 pm »
There appear to be some arcane aspects to the implementation of certain MDG technologies, e.g. SysML, that are opaque to the Automation interface. For example, after finally getting an array copy (multiple copies) feature in an add-in to work (thanks to an assist from Aaron B), I discovered that SysML flowProperty elements copy as plain-old Parts. Checking the related entries in t_object (via Access) revealed that PDATA1 contains what appears to be an Xref to the property type, which apparently carries with it the fact that the element is no mere part but is in fact a SysML flow property. Such undocumented features make it difficult to extend the MDG technologies. Can we expect a write-up from Sparx explaining the use of custom properties and Xrefs, particularly as they apply to MDG add ins?


Pages: 1 ... 25 26 [27] 28 29