Author Archives: exploringea

Another year is nearly over plus a Xmas 2016 giveaway

As we approach the end of this year I reflect on what has been a varied and somewhat busy time for me (us!).

As far as exploring EA, I haven’t been able to do as much as I would have hoped this year, and there haven’t been many post.  However, the list of experiments continues to grow rather than reduce and I continue to enjoy using EA and still find new stuff – so that’s all good.

Commercially our main product focus has been with eaForms, however we recognise that the world continues to change and a “fat client” is not always the best solution, especially when trying to expand access to a wider audience.   Over the years I have received several queries regarding a web interfaces to EA and this year was no different with questions such as – “does eaForms provide a web interface?”   The simple answer is no – it is a traditional EA addin.  But the need to provide access in different ways and possibly to a wider audience is clear.

Last year (2015), we experimented with a small standalone windows client for EA using eaForms.   As illustrated in the screenshot below, a simple project browser tree with tab(s) to present the relevant eaForm were provided.  The user could view/edit element/package information and using buttons in the toolbar add or delete  items.

Screenshot from eaForms eaClient application

Screenshot from eaForms eaClient application

At the same time as developing this windows client I did an initial design for a web based version but didn’t progress.  So with the growing interest in web interfaces I thought it was about time I’d verified my idea with a working demo.

The basis of my design is to use the same concepts of eaForms where:

  1. A request is made, for example by selecting an item in a project browser
  2. The required item element/connector information is retrieved
  3. The item information is presented as defined by the eaForm, including running scripts and providing relevant action buttons

For my experiment I took some short cuts and didn’t code everything myself but used an open source library to provide the test project browser.  As a result I used a standard web server to host this library and our launch page; all the other code is within the web service.

The main components in the design are:

  1. Request handler which receives requests on a specific port from the web client, does request validation sending valid requests to the relevant sub-service for futher processing, handles response returning results to the appropriate caller
  2. Model information provider – used to query the EA datasource and provide the information needed to populate the project browse.
  3. Form generator – used to access the element information and generate the web page.  And handle any events e.g. updating the EA datasource.

All the code and form definitions are stored on the server, with design option to accommodate different eaForm definition sets for different users/roles so that the information that work with is relevant to their task.

One positive aspect of this design is that the information passed to the client is restricted to the information defined by the eaForm.

Now I will admit I’m not a web developer (ours is too busy doing real work, so I had a go which is part of the fun!).  And I haven’t finished writing all the control presentation code for the forms (no lists yet), but as a taster below is a screen shot of an eaForm in a web browser.  Selecting an item in the project browser on the left and the relevant form is generated and presented in the window on the right.  The form definitions were created within the eaForms addin and are used without modifications (what we expect) – below we are using one of our example class forms


screenshot of example form with eaForms webclient

screenshot of example form with eaForms webclient

So my experiment a success demonstrating that it was fairly straightforward to produce a simple web interface to EA, but as always a product is a completely different task.

In this experiment I discovered so much and was amazed about what can now be down within the web browser environment – so more experiments when time permits.   In particular, it made me aware that producing a fully flexible graphical interface to support the presentation/generation of EA diagrams, and in our case eaForms definitions, is feasible.  Perhaps Sparx have something just around the corner???

There are EA aware web-based products around, usually tailored to a specific target market,  so accessing information on anything from a phone upwards is possible.  So this and the queries I received are all testament to the need to access information within EA anywhere anytime.

Not sure if we will do anything – to start with I’ll probably just tinker and see what happens.  Perhaps we could make this web code open source, although it will probably a bit of a tidy up, so won’t happen quickly!

XMAS 2016 giveaway

Finally, as we enter the holiday season and it’s a time for giving, we are offering those interested a free personal eaForms professional version licence (time limited offer), so do check out the eaForms XMAS 2016 licence giveaway – if nothing more than something to play with over the holiday period.

With best wishes and happy new year to all



One of our Add-Ins is missing

Prompted by 2 queries in a week about missing Add-in DLL’s I thought a quick post of the subject may be useful.

One of the problems that I have seen many times during the development and use of EA extensions is the missing Add-In DLL.

If you look at the Manage EA Add-Ins window in EA you may see an entry, as listed in the screenshot below, in the status column indicating that something is missing.

Manage EA Addins windows indicates a missing DLL

Manage EA Addins windows indicates a missing DLL

There is a error code 8000401f3 which indicates that the application failed to create an instance of a COM object using a Class which is not registered on the machine. Hence EA is unable to load the AddIn.

Having seen this issue numerous times I developed my EA Installation Inspector. This program emulates the process that EA may perform in loading your Add-in (Caveat – I don’t have insight to how EA code or how it does stuff in detail works so it’s my guess but seems to work so far).
This program provides more information about the status of the AddIn as illustrated in the screenshot below.

EA Installation Inspector illustrating a missing DLL

EA Installation Inspector illustrating a missing DLL

In this screenshot the purple line indicates that the DLL has not been registered, and hence is unknown to windows. Read the documentation supplied with the AddIn for more information.

Two steps to installing an Add-In

To be able to use your Add-In (DLL/Class) it needs to be known by:

  • EA as an Add-In
  • Windows as a class that can be loaded

I’ll look at these in turn

How does EA know about your Add-In

EA knows about AddIns through registry keys located within the HKCU\Software\Sparx Systems\EAAddins… as illustrated in the screenshot below. The value associated with any of these keys needs to be accurate as it references the class defined in you DLL with the format Assembly.ClassName

EA Add-In registry key

EA Add-In registry key

This list of keys matches the list of AddIns shown in the manage Add-Ins window.

How does Windows know about your Add-In DLL

To be able to load your class EA will make calls to Windows, hence windows needs to know about your class as well, and your DLL (Class) must be registered with windows in a specific manner.

The registration of your class may be performed in different ways. Typically it can be done manually using Regasm or performed as part of your installation by your installer. The registration process should create keys in relevant places in the registry so that when a request is made to load your class the appropriate DLL can be found. There are different versions of RegAsm depending on which .NET framework is being used.

The EA manual indicates that the version of RegAsm to use is that provided with .Net 3.5 with the example

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\RegAsm.exe “C:\Program Files\MyCompany\EAAddin\EAAddin.dll” /codebase

I suspect, but not tested, that you should use the Regasm supplied with the framework you are using.

The problem as I see it is that with the co-existence of 32-bit and 64-bit programs the location of this information is crucial. Now I’m not a windows expert but I know that by working through the trail from the EA AddIn key,a slow process, a class can be registered with keys in the wrong place. So this is where EA Installation Inspector helps. It follows the trail through the registry from the EA AddIn key to finding the DLL file that contains the class that will be loaded.

So how to resolve

Typically when EA can’t find a file then keys have not been registered correctly. EA Installation Inspector will hopefully indicate the error condition and provide an indication of what is wrong e.g. DLL file missing, keys in wrong location.

To check I will usually then manually register the DLL and rerun the installation inspector to check if the situation has improved. So far this has usually worked and leads me to check out what settings are missing or incorrectly set either in the IDE I am using or in the installer definition.

Here are some checks that you can make which may help resolve your missing DLL within an IDE.

  • Ensure that the DLL you are building is compatible with working with a 32-bit application. I always build my DLL’ 32-bit.
  • With IDE’s check setting
  • some of the defaults are geared towards 64-bit systems – e.g. default framework, default build configurations
  • check the setting Register for COM interop

For installers it is usually the case of accurately checking the definitions – usually against a know good installer.


Hopefully this information has been useful in finding your Add-In. However, if not I’m always interested to know what other issues exists (and hopefully solve them), let me know