Category Archives: Administrator

Information for those tasked with setting and performing the administration of the models

Using eaForms to hide tagged values (and improve the quality of your model)

Tagged values are used extensively since they allow us to customise the information we store for our elements. So unlike pre-defined fields we can add them as we require to match the needs of our project. Also within EA we can specify the type and, for some types valid values.  So that’s all great.

Within EA, tagged values can be accessed in several ways. For example, they are available as a tab of the element properties editor or can be accessed via a separate tagged values window. However,  this does mean that the user needs to remember to switch to the relevant place to enter values.  And although there is often the option to set a default value, there is no check that a value has been entered by the user, and hence it may be that the value is a true reflection of the authors input.

We believe this leaves some room for errors and/or incomplete information when editing elements.  So in eaForms we have provided some features which we believe can help users when creating and editing elements.

  • For a start eaForms presents tagged value in the same way as other element fields, with all the same window controls – whether it be a text field, checkbox, rich text box, drop down list, etc – and hence can better reflect the type of input required and simplify data entry
  • The eaForms designer can set pre-defined values to help ensure consistency of values across the model
  • The eaForms designer can also mandate the need for a valid value and hence ensure that data is entered, which in turn can help drive completeness

Although simple these features not only hide some of the fiddly stuff associated with using tagged values, but also help improve the quality of the model.

To illustrate we have some sample screen shots below that show the use of different controls for tagged values.  (Note: these features can be applied across all elements, stereotypes and MDG’s)

Example eaForm showing the use of common windows controls for data entry

Example eaForm showing the use of common windows controls for data entry

On the left we have used several check boxes to capture choices. On the right is a rich text box used to allow them to provide more detailed information.  And on the top right we have a drop down where the user must select a value, no default value has been set and in the definition of the form we have flagged the field as mandatory.   If the user fails to enter a value they are reminded that it is required before they can save their edit.

Example of eaForm warning when required (mandatory) field value not set

Example of eaForm warning when required (mandatory) field value not set

And we must remember that our aim, as always, is to simplify the work of the user who has the knowledge that we need in our model.  So in removing the need to switch to a different place to enter information, by consolidating it all onto a single form in a consistent manner, we can help the user focus on the task in hand.

So just to recap – eaForms:

  • Treats tagged values in the same way as other element fields – easier for user to understand
  • Offers a range of different windows controls for editing including those that force a selection from pre-defined values
  • Allows fields to be flagged as mandatory to ensure completeness of content

Just one small aid to helping getting the job done – I hope you agree.

Click for more information on eaForms


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


eaForms – an element properties editor which can extend and enhance the EA experience

For the last few months I’ve been developing an EA Add-In which has taken longer than originally planned, hence my lack of time for other experiments.  As the project unfolded, we discovered more, expanded the idea, added more features (scope creep!), and then a few redesigns of the UI to provide users options. And even now we still have more ideas to explore.

All in all its taken a few months longer than planned.  I suppose I should believe my rule of thumb which is, when asked by a project manager how long will something take to do – take your first estimate and multiply the time by PI (3.14159265359….   – perhaps not to that level of precision!), and its the number you don’t want to believe, as it could well put you off starting the project at all.

So 2 months becomes 6 and I am now nearing the end of completing the initial phase of this new Add-In – eaForms.  I  had expected to be where I am now before my summer break in July, but instead spent much of my break coding albeit in the sun and must admit it was fun – especially learning more about what you can / can’t do with EA all the time.   I have lots of material from my discoveries for some posts on writing Add-Ins – hopefully I’ve get some time to write up soon.

So what is eaForms – simply it’s an Add-in that allows users to design and run alternative element properties editors.

The idea came from my work in trying to capture knowledge from people who had no knowledge (or interest) in modelling and when pushed to found EA too techie to use.  This led to confusion, frustration and often a bit of a mess for your’s truly to sort out. So why can’t they have something that is a bit more accessible.  They may still have to use EA and so accept that they will be using a modelling tool.  Also there is no getting away from them needing some training to cover the basics plus monitoring afterwards, but at least I could make life a little easier by removing some of the complexity for data entry/editing.  In addition, in doing this I could also help drive consistency by, for example, providing them with a defined set of values instead of a free form text box etc…  less mess for me:-)

eaForms operates in 2 modes:

In Designer mode – the EA user can configure a form, using the eaForms toolbox,  to produce a form that will be displayed for a specific Element type/stereotype combination (support is included for both core element as well as MDGs that are enabled at design time). The content, layout and appearance of this is up to the designer.  The form designer is free to produce forms of different shapes, sizes, colours and perhaps more importantly content using “controls” that go beyond that provided by the standard EA dialogs.  For example:-

  • Combobox (with options for user defined values, to restrict users selections)
  • Checkbox – to provide that quick “yes/no”, “true/false”, as well as other booleans
  • Related elements – with the ability to link to one or more other elements without dropping the current editing context
  • Listviews that display collections with some options to edit items in the list, once again without dropping the current editing context.

Plus built into the design is the ability to add further “gadgets” that as the need is identified.

As an example – here is the basic design of an eaForms in EA – drawn using EA’s drawing tools on an eaForms diagram


In User mode – the EA user, assuming eaForms is enabled, need do nothing.  When they edit an element for which there is a matching form available eaForms will present this instead of EA presenting its standard dialog – below is a screenshot for the form design above:


All in all no real magic but pretty useful.

Of course, for the experienced EA user the benefits are different.  They can produce forms that help them by bringing information together in a single place in the way that they want (I do this for classes, where I have a single form with the class information, its attributes and operations). And bearing in mind it only takes a few minutes to produce a form it can be time well spent, of course, for the artistic it’s easy to spend more time enhancing the look of the form!

Although we think this is a great tool it is important to remember eaForms is just another tool in the EA toolbox. It is an Add-In that can extend and enhance the users’ experience. Using EA still requires guidance from those responsible for the models. Our aim with eaForms is to help in making EA more accessible, reducing some barriers and helping ensure data consistency. Not for everybody but useful to the many.

We have more ideas on where we could go with eaForms and could just continue developing but probably better to let you play (and hopefully provide feedback).

We plan to start trialing eaForms soon – so watch this space.  In the meantime we have started with some short videos that demonstrate the product and its use which you can find on YouTube Channel.

Be back soon.


Update and setting up a multiuser EA Project

I’ve been a bit inactive on this blog for a few weeks, just had my head down finishing off a product.   When you think you are just about into final testing, you come up with another bright idea and before you realise the goalposts are moving and …

I think we have all been there either through our own doing ( as in my case) or because our boss/client has changed their mind or expanded their requirements.

It does remind me of the importance of documenting and, very importantly, agreeing the requirements for the “product” being developed (plus ensuring that there is an agreed change process to accommodate the inevitable revisions, not least to help with expectation management!)

As its only me and its summer here, until I put the product out user testing I’m the only one to be concerned.  However I’m hopeful that “just” a few more weeks of tweaking, testing and ensuring that the documentation is consistent and it will appear;  I’ll keep you posted.

On a completely different topic, I was asked by a friend a few days ago for some thoughts on setting up a multi-user EA project so put together a short document (Setting up a multiuser EA project Draft V1).  At present it’s a working draft but I expect to enhance not least when I get more questions that come back – in fact, just thought the points I made earlier about agreeing requirements/change processes should be included!

I’ll leave that with you – always happy to receive constructive feedback.

Be back soon.