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 4 ... 11

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.


I assume that your AddIn is a standard windows user control.  In which case the reasons it doesn't resize to its parent is often because its properties prevent resizing.

Some of the properties to check are:
* Locked - False - to ensure that the control can be resized
* Maximum size is 0,0 - so not limiting the size of the control

You also need to ensure that any embedded controls do not have any restrictions on them.

The only time I have had to do anything more than that is when embedding external applications into the addin window. In this case you will need to respond to Win32 messages and that's a different story!

Automation Interface, Add-Ins and Tools / Re: EA.App in VBA automation
« on: September 02, 2016, 06:25:27 pm »
I haven't tested with EA, but as the first parameter of the GetObject function can be set as "The full path and name of the file containing the object to retrieve"  - this can be used to specify which version to run.

So the issue is knowing the filename for a specific version.  Here are several ideas (I am sure there are more):
  • Search the registry in your code to retrieve the path for the desired version - or
  • Install EA in specific directory that has the version number e.g. "C:\Program Files (x86)\Sparx Systems V12\EA" - or
  • Have a text file which contains the filename which could be read (or use a registry key you could read)
The purest in me would be to search the registry however this is a bit of an overhead.  Both the version number and install path are located under each EA install section within
  • HKLM or HKCU (depending on installation type) \ Software \  (optionally WoW6432Node) \ Sparx Systems \ EA400 \  EA
The relevant keys are:
  • Version
  • Install Path

NB: I haven't installed Version 13 yet so there may be some changes that I haven't seen yet!

My practical approach would be to install with a version number (but that could be too late and prone to omission when updating etc), ...

Hope this helps.

As promised I have done a post with information on how we create non-admin installers

Hope this helps.


I have a non-admin installer for eaForms, which works fine, although without admin rights you need to be careful with updates/uninstall.

I'm out of the office today but if you send me a mail eaforms(at) that will remind me and I'll try and provide the relevant information.

Just to let you know, although you will see an entry with my installation inspector it won't display the DLL information for VisioImporter DLL, even for a working installation. 

I was about asked about this addin earlier today, and upon checking, see that the VisioImporter is not a .NET assembly, it's a typelib, which I don't check for.

The error code indicates an "invalid class string" - so I guess sparx will have to provide insights into how they are loading addins and what could go wrong.  I'm afraid my inspector is based on general assumptions about loading dlls rather than any knowledge of what is actually checked.

I have made some additions to the Installation Inspector (V3) and submit to the community site - which will take a few days.
In the meantime a ZIP file containing the Beta for Installation Inspector V3 can be downloaded at - note: this is a temporary download only until updated on the community site.

I should have noticed that on a diagram the right click properties is equivalent to "Alt+enter" and this combination has always opened the properties page regardless of where the item is selected, and does not fire an event.  I've always used this to open EA properties editor even when eaForms installed.

@Uffe agree that the it would be useful to differentiate real events so that when the item was selected from a context menu I knew that compared with double clicking the element in one of several locations.  However I guess this is probably too deeply established in EAs UI code.

BTW: Clicking a diagram in project browser fires the EA_OnContextItemDoubleClicked event.

Pages: 1 [2] 3 4 ... 11