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

Pages: [1] 2 3 ... 11

Don't be put off by the "youngsters", I started using Excel VBA with EA in 2002, then later used VB.NET (At the time Java was my preference but couldn't get it to work with EA then; not sure where it is now).  Done a lot with EA and Excel including the XL part of eaDocX in VB.Net so know it is fit for purpose!

For some projects, where an off-the-shelf solution doesn't provide the functionality and dynamic interactions with Excel are not required I have used libraries both my own and the EPPlus open-source Excel library.  The later is a file based solution so useful for reading and creating /export Excel workbooks; it also avoids the need for the Excel Interop and the challenges that can present.


Hi Rich,


As pointed out it's not the language that's the issue with writing an AddIn - C+,C#,  - anything that can create a valid DLL.  In my experience writing AddIns is more about understanding the EA API and dealing with the quirks of windows.

BTW: These days I write nearly all my AddIns in VB.Net unless my customer specifically wants another language, although I'd probably draw the line at doing it in assembly language these days!

If it would help I'm sure I can provide some example projects including installers - what type of stuff are you trying to do?

Re the error, 800401F3 that is nothing to do with the language; the error message translates to Invalid class string, so this looks like your AddIn DLL isn't registered or name is not correct.  Suggest you download my free Installation Inspector as that may provide a bit of information.  V5 of the installer is in Beta but may be more useful as it includes registry search functions that may help find any mismatch between class name and the class names in your dll file.

I also have some information/examples on registration/installation on the public part of my tools site that may be of interest. As suggested by Uffe Wix works fine and worth getting a good working template sorted early on. 

And as you've probably guessed there are plenty of experts on the forum always ready to help.


Hi Helmut

Thanks for feature requests:

Item 1:  is now available in the test release (I've put a copy of the working development version DEVc).  You can either select the progID in the registry tree window (context menu) if the progID exists or select the query tab; press the Run query button (at bottom of the form), then type whatever ProgID / classname you wish to check, then press "Run query" - and wait; the query happens in the background (a query active label appears top RH), so you can carry on doing other stuff then return to the query window when query info text box goes green.  BTW: This is not limited to EA but will execute a query for any class.  You could enter a classID but an unlikely request; can be done from context menu options in the registry tree view.

I need to refine the UI and help file but in the meantime have updated V5 concept page with some more screenshots/descriptions.

Item 2:  Seems like this is a request to inspect an installer (msi) file and determine what rights will be required - have I understood your request correctly, if not perhaps you can expand - there may be bits that can be done if not all.  I am guessing that if it is I need to do some more research:-)  It may be as quick to just try!

@all addin developers.

Any more requests? ideas that could make it more useful.


Ever curious, I've had a play and can confirm that I find no way of dragging something from the EA UI onto a custom contol; no surprise as the control is a child with no clear link back to the EA UI code.  In fact, it's clear from the error message "There is no current diagram to perform this operation. Please select a diagram first" 

However, not sure what you application is, so this may be completely out of scope, but what you can do is track the context e.g. the last item selected in the project browser and click in the tab and capture the information relating to the relevant project browser object.  One could argue that it is easier in some ways that drag and drop i.e. -> click & click!  There are probably several variants of this approach depending on your specific requirements.


Hi Guillaume,

My guess is that EA is losing focus for some reason, but not entirely clear from your description. So a brute force way to try and bring EA to the the front after closing your forms is to call windows API to bring EA to foreground.

Something along the lines, in VB.Net but easy to convert to C# I'm sure:
1. declare functions and a constant
Code: [Select]
Declare Function SetForegroundWindow Lib "user32" (ByVal hwnd As IntPtr) As IntPtr
Declare Function ShowWindow Lib "user32.dll" (ByRef hWnd As IntPtr, ByVal nCmdShow As Integer) As Boolean
Private Const SW_MAXIMIZE As Integer = 3

2. Get the process handle (of EA) and then set as ForeGround
Code: [Select]
Dim proc As Process = Process.GetCurrentProcess()
Dim hWnd As IntPtr = proc.MainWindowHandle
If (hWnd <> IntPtr.Zero) Then
    ShowWindow(hWnd, SW_MAXIMIZE)
End If

A quick test with this will at least identify/eliminate loss of focus as the issue.


Please forgive me if this is not considered the correct place for this post but I'm unsure how to let the AddIn developers who use my (free) EA Installation Inspector know that I'm working on a new "infrequent" release and keen to get any feature requests.

I have a page EA Inspector Development with some outline ideas and screenshots, with a link to download an evolving working development version.

So if you've found the EA Installation Inspector useful and would like some other functions do let me know.




The fact that the EAInstallationInspector identifies an issue is good news in that it can help identify where the problem is as it goes through the process of identifying the DLL that provides the class for your addin.

Looking at the Installation Inspector screen - left to right:

The first 3 columns relate to the sparx addin entries.
Col1: Name of the addin - is the name of the key in the Sparxs Addin entry (and location in the registry) - this is the name that you have created in the registry.
Col2: The area in the registry where the Sparx AddIn key is defined (has been found)
Col3: The class name is the value that you have set in the Sparx AddIn key value - and MUST match the class name in your DLL assembly Exactly.

The next 2 columns - identify the class ID
Col4: The location in the registry where the Class ID is found for the class - from Column3
Col5: The ClassID -

The next 2 columns - identify the DLL that provides the class
Col6: Location in the registry where the file reference for the DLL has been found
Col7: name of the DLL which provides the class

Depending on which columns have valid values will help identify where the problem could be.

You can double-click the entry to get a better presentation.

BTW: The InstallationInspector simply performs a manual process I went through all too often and simply checks:
1. What class is EA looking for?
- Is the class defined and matches the class definition in the DLL
2. Is this class defined? Is it public?
- You should be able to see the class in defined under HKEY_CLASSES_ROOT
3. Where is the DLL providing this class?
- Under the class entry - does it have a CLSID defined - normally under a WOW6432Node\Classes\CLSID entry..

I assume that you have built the DLL as a 32-bit DLL

If you post or send me the InstallationInspector screen shot (Press the button at the bottom of the app) and I'll give you a response.



Solved thanks to Simon reminding me of an option I missed!

"connectors will only be locked if the "Configure | Security > Manage > Apply Locks to Connectors" option is enabled."

Just reminds me there are so many things in EA!

Solved thanks to Simon reminding me of an option I hadn't noticed!

"connectors will only be locked if the "Configure | Security > Manage > Apply Locks to Connectors" option is enabled."

So far tests seems to work; and saves me time writing code.

Just reminds me there are so many things in EA!

Hi qwerty
Thanks for pointing that out - will do.



If a user has locked a package that contains elements with connectors, which only connect the elements in the package, should it be possible for another user, who does not have any editing rights to these items be able to delete the connector and its tags?

The documentation (see clearly states
  • "You can set the lock on the entire contents"  and
  • it applies to "Elements and/or diagrams in the Package"

Hence, I had assumed that this applies to relationships that are solely within the package.
If not perhaps you can advise.

BTW: I understand that if the element has a relationship to an element, outside of the package for which the user has access rights is different.
FYI: Tests were done using EA V13 bld 1310, where different users are able to delete both the connector and its tags of of packages controlled and fully locked by other users.

I have also outlined my scenario and search for workarounds in another post (see -,38947.0.html)

In summary, can you confirm:
1. What the behaviour of EA should be? 
2. If the deletion is a feature of EA is their a recommended workaround to protect the integrity of our models?

Many thanks



I've an interesting issue relating to connectors in locked packages.  Let me explain by example:

I have one user who creates a couple of components (A and B) and links them with a connector (C).  Both components and connectors have tags.
The package is fully locked.

Any user without rights to the locked area can create a diagram in their own area, add links of the components A & B to a diagram.  The conenctor(C) between them automatically appears.  All fine.

Next I try to modify the element and its tagged values - no can do, of course not there locked so behaviour as expected.  Fine.

Next I try to modify the tagged values on the connector - no problem, what I can edit tagged values and what's worse I can delete the tagged values!

However, on the positive side I cannot add any more relationships between components A & B since they are locked - EA picked that up.

So why the automation board for this issue, well and not to be outdone:

1. To prevent the deletion of the connector tagged values I use the EA_OnPreDeleteConnector event and using that can prevent the deletion based on checks made on ownership / groups obtained from the security tables.

2. To prevent the editing of tagged values, if ensure that I manage all tagged values in my addin using Predefined Structured Types of type AddinBroadcast I can intercept attempts to change the values and prevent an unauthorised user changing the value.  Although it places big restrictions are requires all tagged values to be known to the Addin - not ideal!

3. Then to prevent deletion of the connector tagged value... there isn't an event; all I really want is an event OnPreDeleteConnectorTaggedValue - Have I missed it?

One approach could be to use EA_OnContextItemChanged event to check when a connector is selected and whether it is between locked items and so will need protecting. If that is the case then I make a copy of all the tagged values, and if there is a change then use the EA_OnNotifyContextItemModified event to reinstate them.  Not an approach I like and not that confident that something could be missed, so just doesn't seem correct.

Anybody else had this issue and if so what approach worked/didn't work?



Hi Guillaume,

Sorry not had much time to look at forum recently - head down mode...

Re registering the DLL have you include code in wxs file to do this, e.g. below is the complete registration for my eaForms installer, which works for both machine and current users hence use of root HKMU but this could be HKCU if definitely only for current user.  This is the component that does class registration and sparx addin key

     <Component Id="ProgramKeys"  Guid="9******">
          <RegistryKey Root="HKMU" Key="Software\EXploringEA\eaForms">
            <RegistryValue Type="string" Value="Default Value" />
            <RegistryValue Type='string' Name='ProgramDir' Value='[INSTALLDIR]' KeyPath ="yes"/>
            <RegistryValue Type="string" Name="Examples" Value='[EXAMPLESFOLDER]' />

        <RegistryKey Root="HKMU" Key="Software\Sparx Systems\EAAddins\eaForms" ForceCreateOnInstall="yes" ForceDeleteOnUninstall="yes">
          <RegistryValue Type="string" Value="eaFormsCE.eaForms"/>

        <RegistryKey Root="HKMU" Key="Software\Microsoft\Active Setup\Installed Components\eaForms"  ForceCreateOnInstall="yes" ForceDeleteOnUninstall="yes">
          <RegistryValue Type="string" Value="eaForms Addin" />
          <RegistryValue Type="string" Name="Version" Value="1" />
          <RegistryValue Type="string" Name="StubPath" Value='reg add "HKMU\Software\Sparx Systems\EAAddins\eaForms" /ve /d eaFormsCE.eaForms /t REG_SZ /f' />

Then includes in the feature section as:

 <ComponentRef Id="ProgramKeys"/>

Perhaps this may give you a clue, and one day I'll update my post with other findings such as custom UI etc along my path of creating quite a few installers now!!
Ping me if you are still having issues and I'll see what I can do.



@Helmut - in view of your response I needed to check as in my experience I have not needed to have the custom window code in a separate DLL (unless it made sense for the design), as the AddIn is already a COM DLL, but did a simple check this morning in case things have changed!

@Phil - this is what I did to double check:

  • Created a simple user control, called "UC1", which was in my main AddIn DLL (Assembly "testAddIn") - MUST be a public class
  • Added code - see below

I added a simple menu item to show the window in the menu click (in

Case "Show window"
 Dim myNewAddInWindow = Repository.AddWindow("My tab Label", "testAddIn.UC1")

Register the new class (VS doesn't do this automatically), so I re-registered the AddIn, running the batch file below.  I could then see a new class entry for "testAddIn.UC1"
When deployed the installer will handle the registration.

For testing I have an existing batch file to do the registration with the single line which runs RegAsm for the required .NET framework for my AddIn DLL.  So just re-running this did the job both the AddIn and User Control are in the same DLL.

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe   "./bin/x86/Debug/testAddIn.dll" /codebase

Note this is for .NET3.5, for other .NET versions use the appropriate RegAsm app e.g. for .NET4 use the app to register 


In the case that you develop the code in a separate DLL then clearly Helmut's advice applies.

Hope this helps, but any specifics do ask


Hi Phil

A quick thought - you have said that you have registered the class, have you?
User guide says "Once the custom control has been created and registered on the target system"

EA will look for a class with the name (in your example) "TestAddIn.MyCustomControl" in the registry.
Use RegEdit to check that there is an entry under HKEY_CLASSES_ROOT

I've forgotten to do it before now.


Pages: [1] 2 3 ... 11