Stepping back, but leaving sites up for a while

Having officially retired, or been retired, and other activities are consuming my time it’s clear that I’m not going to able to contribute much that is useful to this blog about EA.  And although I never managed to do as much as I wanted with my EXploringEA experiments it has been fun.

I’m going to leave this site and my other EXploringEA sites eaForms & Tools (there are a few utilities that may still be useful) up for a while just in case some of the information is useful to others.

All the best,


EA Installation Inspector V6

A new version of the EA Installation Inspector has been released.  This free utility can be useful to addin developers as well as users of EA AddIns checking or troubleshooting their installations.

This new release has simply added an “EA debug config” button which becomes visible when an EA.exe.config is present in the EA install path and which could specify the sequence for checking runtime frameworks.EADebugConfig

An example config file is displayed as illustrated below.Config

An executable, documentation and source code can be downloaded from our GitHub page




EAInstallation Inspector – new development

One of the most useful tools I have probably produced for use with EA is my EA Installation Inspector.  Although less so nowadays, there was a time when I was forever wondering why my AddIn wasn’t working.  It was several years ago that I produced the first release and have periodically added a few enhancements.  With this I have added some information to main form.

But also felt I could improve the presentation of information to help AddIn developers get a better overview using a treeview of Sparx Addins information as illustrated below.

However, often the hard to find issues are those where there is a mismatch of something, such as the wrong class being called, and although careful inspection of filenames may resolve a search of the registry (not necessarily quick) can help expose the error.  As the searches usually relate to known AddIn classes it is straightforward to use information in the AddIn keys to initiate a query with context sensitive menu.

In addition, a user can define their own searches, e.g. entering a class name or filename.


The queries execute in the background allowing the user to continue using the tool for other tasks. Furthermore, queries are queued with the results being presented in their own tab, as well as being output to a unique log file.

Although not yet polished this version is available for download from either my EA Tools Wiki or where the source code is also available.

I’ve also added some of notes on Installers and EA Installation Issues on my EA tools wiki, and always interested to know of any other issues with installing EA.

I hope you find the new features useful.




eaForms Community Edition – alpha release

eaForms(tm) has been around for some time, and although not a major commercial success in its own right, it has proved useful to me and others.  For budding AddIn developers my experience is that you only make money from AddIns when somebody else pays for the development(!), although they can be really useful in supporting your projects.

Since the demand for new features has stopped, we haven’t been doing much development, and have no plans for further development on the commercial product.  However, I felt that it may be useful to make available a version that may be of use to a wider audience – hence this Community Edition of eaForms.

This version is similar to the existing commercial product, a few functions have been removed, there are significant changes in the Form Designers’ user interface, and there are some underlying changes which provide greater flexibility when making enhancements and using some of the components in isolation.  And most importantly, we have removed all license menus/options have been removed – it’s free to download and use!

Interested? – you can download an early access version on the eaForms(TM) Community Edition download page. This is not a production release but provided to allow users to test and gives us some feedback; keep an eye on the download page for further updates.

Other changes

For those customers familiar with the existing product the following changes should be noted:

  • There is now only a single version with no difference between the designer and user versions; just an additional menu option
  • The format of the Form Definition files has changed to make it easier to add new control types – we have produced a Form Definition convertor to help.
  • Editing of controls has moved from individual dialogs to a common approach using property grids dialogs
  • Some menu options have been removed, specifically those where we no longer see a need for the function (please let us know if there is something you really need!)

One of the areas we are keen to get feedback relates to the multiple windows i.e. the FormDesigner, control properties window, trace window; at present they exist as windows forms outside of EA but would it be preferred if one or all were EA tabs/addin windows?

Open source / toolkit?

When deciding to release this version of eaForms I thought about how much I have learnt from  its development.  There were odds and ends with EA, but more significant and challenging was Windows; I’ve always found that writing AddIns has always been more about Windows programming than EA!!

With the learnings in mind I am toying with the idea of making this version (or parts) availanle as open source.  This would allow me to share my learnings, and it may be that others would wish to enhance the product or use some its components in their work.  However, I see little point in doing this unless there is real interest as it will no doubt involve me with some work and potentially lots of questions!

What next?

Give it a go and provide me with your feedback so that I can review options for the next step.

In the meantime, have fun, and if your project requires EA support drop me an email!




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


Non-admin installation of AddIns

Further to a query in the EA forum on how to install an EA addin without admin rights here is an outline of the way I do it – it is probably not perfect and for somebody with greater knowledge than me about windows installers there are probably some slicker or better ways.  However, it has been working reliably with some of our customers for some time.

Create an installer project

Our installers are created using Wix. Hence, the steps involved are to:

  1. Create a wix project adding the wxs file to the project.  We use a graphical UI so the project will need to include references to the relevant Wix libraries (WixUIExtension, WixUtilExtension, WixNetFxExtension)
  2. Create a wxs file defining the installer requirements; an example wxs file is provided below
  3. You may optionally use heat to havest information from projects to be included in the installation (the example wxs file provides an illustration)

Points to note

It is important to note that a non-admin installation will install the addin for the current user only.  Registry entries are placed in the current user area (HKCU) and not the local machine (HKLM) need to make it generally available.

When running the installer, for somebody without admin rights, the target directory must be set to a location in current user area where they have write access.

When doing an update of a non-admin installation we recommend that your do an uninstall AND then ensure that you delete any installing dll’s as we have seen instances where the sequent install has not updated dll’s!  Perhaps an installer expert will explain why to me someday!

I wouldn’t say that sorting our installers was all plain sailing.  A useful tool that is supplied with windows SDK is orca – a tool that allows you to inspect install files (msi).  Really useful for checking information.  You can edit installers files with orca but I wouldn’t recommend it but solve issues at source, otherwise I feel you could get into a real mess.

I hope this short post provides sufficient information and you can get you non-admin installer working.


Example WXS file

The example WXS file below will need to be adapted to your requirements by setting:

  • GUIDs for the relevant items.
  • File locations for project files
  • Files for images and any included files

<?xml version=”1.0″ encoding=”UTF-8″?>
<Wix xmlns=””&gt;

<!– Set as required –>
<?define MajorVersion=”0″ ?>
<?define MinorVersion=”1″ ?>
<?define BuildVersion=”2″ ?>
<?define Revision=”3″ ?>

<!– Full version number to display –>
<?define VersionNumber=”$(var.MajorVersion).$(var.MinorVersion).$(var.BuildVersion).$(var.Revision)” ?>
Upgrade code HAS to be the same for all updates.
Once you’ve chosen it don’t change it.
<?define UpgradeCode=”YOUR UPGRADE GUID” ?>
Path to the resources directory. resources don’t really need to be included
in the project structure but I like to include them for for clarity
<?define ResourcesDir=”$(var.ProjectDir)\Resources” ?>
The name of your application exe file. This will be used to kill the process when updating
and creating the desktop shortcut
<?define ExeProcessName=”SuperForm.MainApp.exe” ?>
<!– defines include the version number –>
<Product Id=”*”
Name=”!(loc.ProductName) $(var.VersionNumber)”
<!– added Install scope to install for the machine rather than per user –>
<Package Keywords=”Installer”
Description =”Your product name”
InstallScope =”perUser”/>
<Media Id=”1″ Cabinet=”” EmbedCab=”yes” />
<UIRef Id=”WixUI_FeatureTree”/>
<!–  These dialog references are needed for CloseApplication above to work correctly    –>
<DialogRef Id=”FilesInUse” />
<DialogRef Id=”MsiRMFilesInUse” />

<!– Set the icon to show next to the program name in Add/Remove programs –>
<!– need to set $(var.????.ProjectDir) in lines below to reflect the your source project directory e.g. $(var.myaddin.ProjectDir) –>
<!– You don’t have to have icons or background images, or a licence agreement – these are optional so read the Wix documentation –>
<!– also note that the images MUST BE of an exact size otherwise they may not be clear –>
<!– banner.bmp must be 493 x 58 –>
<!– backgroud.bmp must be 493 x 312 –>
<Icon Id=”AppIcon.ico” SourceFile=”$(var.????.ProjectDir)\images\EX.ico” />
<Property Id=”ARPPRODUCTICON” Value=”AppIcon.ico” />
<WixVariable Id=”WixUIBannerBmp” Value=”$(var.????.ProjectDir)\Images\InstallBanner.bmp”/>
<WixVariable Id=”WixUIDialogBmp” Value=”$(var.????.ProjectDir)\Images\InstallBackground.bmp”/>
<WixVariable Id=”WixUILicenseRtf” Value=”$(var.????.ProjectDir)\Legal\Our Licence Agreement.rtf”/>
<CustomAction Id=’NoDowngrade’ Error=’A later version of [ProductName] is already installed.’ />
<!–     Set the default install location to the value of INSTALLLOCATION (usually c:\Program Files\YourProductName)  –>
<!– Feature to build the installer file –>
<Directory Id=”TARGETDIR” Name=”SourceDir”>
<Directory Id=”ProgramFilesFolder”>
<Directory Id=”INSTALLLOCATION” Name=”!(loc.ProductName)”>
<!– this component defines the files that are to be installed DLL’s, help file and the sample eafd –>
<Component Id=”YOURDLLs” Guid=”A COMPONENT GUID” KeyPath=”yes”>
<File Id=”Interop.EA.dll” Source=”$(var.????.TargetDir)/Interop.EA.dll” Vital=”yes”  />
<!– ADD entries for all DLL’s and other files that need to be installed –>

<!– this section creates the keys for the add in –>
<!– YOURCOMPANY and YOURPRODUCT are defined by you are are where the installer will place the keys –>
<Directory Id=”Keys”>
<Component Id=”ProgramKeys”  Guid=”ANOTHER COMPONENT GUID”>
<RegistryKey Root=”HKCU” Key=”Software\YOURCOMPANY\YOURPRODUCT”>
<RegistryValue Type=”string” Value=”Default Value” />
<RegistryValue Type=’string’ Name=’ProgramDir’ Value='[INSTALLLOCATION]’ KeyPath =”yes”/>

<!– ADDINNAME – is a key that will be created in the registry, which EA will check on load. –>
<!– ASSEMBLY.CLASS – is the class that EA will attempt to load so needs to be registered–>
<RegistryKey Root=”HKCU” Key=”Software\Sparx Systems\EAAddins\ADDINNAME” ForceCreateOnInstall=”yes” ForceDeleteOnUninstall=”yes”>
<RegistryValue Type=”string” Value=”ASSEMBLY.CLASS”/>
<!– when registering the class you want the keys to be placed in somewhere meaningful – hence use a string that you can find e.g. YourADDINNAME –>
<RegistryKey Root=”HKCU” Key=”Software\Microsoft\Active Setup\Installed Components\YourADDINNAME”  ForceCreateOnInstall=”yes” ForceDeleteOnUninstall=”yes”>
<RegistryValue Type=”string” Value=”YOUR Addin” />
<RegistryValue Type=”string” Name=”Version” Value=”1″ />
<RegistryValue Type=”string” Name=”StubPath”
Value=’reg add “HKCU\Software\Sparx Systems\EAAddins\ADDINNAME” /ve /d ASSEMBLY.CLASS /t REG_SZ /f’ />


<!– we define the features which pull in the components above –>

<!– optional you can harvest files from the project using heat – if you wish to use this method check the Heat documentation for details of parameters.
“C:\Program Files (x86)\WiX Toolset v3.10\bin\heat.exe” file “$(SolutionDir)addinname\bin\$(Platform)\$(Configuration)\MainAddin.DLL” -v -dr INSTALLLOCATION -srd -gg -g1 -cg HARVESTED_DLLS_reference -suid -var “var.addinprojectdirectory.TargetDir”  -out “$(ProjectDir)HARVESTED_DLLS_reference.dll.wxs”

<Feature Id=”Complete”
Title=”AddIn setup”
Level=”1″ ConfigurableDirectory=”INSTALLLOCATION” TypicalDefault=”install”
Description=”your addin description” AllowAdvertise =”yes” >

<!– add this line (or multiple lines if you are havesting multiple projects) otherwise leave out –>
<ComponentGroupRef Id=”HARVESTED_DLLS_reference”/>
<!– these are the components define above which will be included in your installation –>
<ComponentRef Id=”YOURDLLs”/>
<ComponentRef Id=”ProgramKeys”/>


Working with multiple EA elements at the same time

Ever been frustrated when trying to edit an element and wanting to refer to information in other elements or packages?   You may need to close the current element, open another to capture the information you need and then go back to the element you were working on trying to remember the detail, only to repeat the same process a few minutes later.

This was a problem I have often encountered, for example when cross checking requirements and wanting to read the information from multiple items at the same time.

One solution is to output the information into a spreadsheet (using eaXL of course) then reimport the changes or into a word document (eaDocX)  which you can check as you make your amendments.  But all that takes time, and it may be that you still need to refer back to the model.  And as the model changes you may need to repeat the process to ensure that you have the latest information.  Don’t get me wrong these approaches work, and I find them particularly useful when needing to cross check and review information  before publishing documents.

So rather than remain frustrated,  I came up with a solution extending eaForms so that it could present element information within an EA tab.  The benefit of this is the ability to have multiple tabs and hence provide access to multiple elements at the same time.  If you look at the screen shot below you will see multiple tabs each representing an element or report.

eaForms Tab presentation - can display one or more elements as EA tab

eaForms Tab presentation can display one or more elements as EA tab

Furthermore, as you can undock EA tabs you can view mutliple tabs at the same time and as screen(s) permit spread them out.  Below is a screen shot showing 2 elements, one of which is an undocked tab; in practice you can distribute tabs across multiple screens.

Using multiple tabs - working with tasks and linking to requirements, and working on the requirement at the same time

Using multiple tabs – working with tasks and linking to requirements, and working on the requirement at the same time

And another example when completing use cases:

Example of use case form - where all information for prodject is input - together with editing a requirement

Example of use case form – where all information for prodject is input – together with editing a requirement

A simple idea using eaForms within EAs flexible framework that removes one little frustration.

One use I have is when planning projects and needing to ensure that I have linked relevant items.  For example, when checking tasks and their dependencies I use the Related Element Control, but need to check the detail of individual elements and diagrams to ensure all is covered.  There is a similar job when checking progress to ensure that everything is covered!BTW: I do use EA’s project management tools as well to manage allocation of work and progress, however they don’t offer the visibility I need to ensure all is captured in the plan!

I am sure you could think of other examples where information from different places is needed at the same time.  As eaForms evolves we will dsicover other use cases that we need to address; it’s still early days so we welcome your feedback.

Does eaForms have a use in your work making it easier to get the job done?

In the meantime, go to eaWorkplace to download your eaForms update or a eaForms trial version if eaForms is new to you.




All in one place

If you picked up on a news item on the community site last week you may have read the referenced article.  In this article I picked up on a key point and I quote:

“Enterprise Architect was developed with several key design rules in order for project teams to be able to use a single platform …”

Now coincidentally on the Sparx forum  Geert Bellekens made a comment

“Over the years I’ve come to the conviction that EA is the only application a Sparx Systems employee is allowed to have installed”

Now I’ve always been keen on having information in a single place with a “single version of the truth” – a phrase I have pinched from one of my friends , so that “…every stakeholder… needs access to the central information base…”.  Hence, thinking about the scenario that Sparx may well use a single platform to do all their product development I thought this a concept worth checking.  Before starting it is worth noting they have used the word platform, not a single tool since this would be impossible as there needs to be compilers, linkers etc, but a platform, a single workspace, that is use to do all the work –  “… negating information flow blockages…”.
So let’s think about the steps involved in our hypothetical simple product development.  What does EA provide and more importantly what is missing:

These could be anything, notes, pictures, links.  I tend to favour using a text editor and mind-maps for this phase.  Mindmap are supported within EA but the diagrams are not that different from other EA diagrams, so although they benefit from a familiar interface they are a bit clunky compared to other products (e.g. Mindmanager, Freemind and my current favourite Simplemind – as it works on my iPad), especially when wanting drop research items – links, pictures.  Although it can be done there are more steps involved in the process and for me at this stage the number of steps is a key factor in any tool design as you could be trying to capture lots of random ideas quickly

Design and analysis
EA’s core functions – as far as I know it’s well supported and it covers my needs.  So not sure I need to add anything more.

The ability to define classes and generate the stubs with initial code works fine but is very manual.  For a developer who started life with paper tape and cards each change, though welcome can take some getting used to, and compared with available IDE’s such as Visual Studio, Sharp Develop, eclipse or Android Studio EA there is a clear difference – a step backwards or is that just my configuration.  However, if it can enforce a discipline to focus on the class rather than the code this can only be good in trying to reduce design errors.

When you want to compile the code unless you use an IDE with an integration MDG you will have to write the project and make files manually – not for the faint hearted (potential for a wizard?)  Writing these files manually can help the developers truly understand what they include in their applications rather than delegating the task to a tool (and indirectly somebody else’s).  Also worth noting that as the source files do not reside in EA it does mean that knowledge, although accessible providing you don’t move your code, resides outside of the tool!

Within EA you can debug your code with many of the features I use within VS, albeit not as neat, however for me there is one major feature missing – “edit and continue”. It can save so much time; the ability to resolve simple mistakes as well as allowing temporary changes to code, really useful when trying to work out how an API really works.

An area I haven’t used greatly, sorry I’m still wedded to spreadsheets and my clients often have their own tools, such as HP QC, that must be used. So I can’t truly comment on testing using EA, although I observe that within tests their appears to be a lack of any history (unlike changes, issues, etc.).  I think the ability to have information about historic problem areas is really useful.

I see no direct support to create/manage installer projects within EA.  Yes you can have a class with an associated file, and you can edit <F12> the content; there is even a nice navigator for the XML. And whereas EA MDG will import a code project I haven’t seen it import any setup projects. So you’re on your own.

A key part of any product is post deployment.  The issues that arise, the support calls, new requirements, etc. this is an area where having the information in one place is a real win.  The challenge is having the systems in place to ensure the information is captured, and for me this really means that all involved need to use EA.  This is a real challenge as it could mean changing well established processes; not the easiest thing to do. I remember some statistics that state the maintenance of software maintenance accounts for 80% of the cost – so there may well be an argument to consider this further but you’d need to be a good politician trying to do this in a large organisation.  BTW: I’d be interested the Sparx internal process for this work.

Project management
I have been very sceptical in previous posts about the project management within EA not least as there are different types of task – task elements, element tasks, project tasks.  I find this both confusing and unnecessary – a task is a task, yes there are different types of tasks, but at least can we access all tasks in a common manner! However, I have persevered, not least to ensure the key information remains in a single repository.

Recently I have been working on a project where we have made good use of the project management features – keeping track of work across several delivery teams – and it has worked well. But having to manually check for dependencies between items on Gantt charts, overloaded resources and critical paths is error prone and time consuming.  It would be really useful and time saving to have a few of the standard features from traditional project management tools, not least to highlight the issue if not correct them.  It doesn’t need an all singing and dancing feature set – in fact adding items such as self levelling could risks the PM not looking at planning in enough the detail.  I’ve been tempted to write an AddIn to resolve these issues, but as the items are so near the core of EA it wouldn’t make sense.  I’d need to duplicate some diagrams and, in any case, the time and effort may not be justified as Sparx may simply add their own code to make mine redundant!

Team working

A great benefit of EA is the ability to work on the same repository, albeit in a controlled manner to avoid conflicts. But access to all the information with the ability to link to items as required is a real plus.

If we look at team working we cannot ignore the fact that EA include team review tools, model mail or calendar but in my years of using EA and talking to other EA users I haven’t met anybody using them.   The idea of keeping information in a central place makes sense and I have tried in the past but people are so wedded to exchange for mail / calendar functions it just wasn’t going to happen. However, what I find useful are the Element discussions to capture notes, usually from emails or snippets from documents that could be useful, but without contaminating the element description.

In the beginning I used EA’s tools to generate documents, but my use has reduced to a few of the standard reports. On occasion I use the HTML reports as they can be a really useful way of sharing information without viewers needing to know about a new tool.

For rtf documents the need to adapt templates, especially when needing to modify for different customers was(is) very time consuming.  I guess that if you are on the inside and have a standard set of rtf templates then the EA approach works.  However, if you are on the outside or constantly needing to produce different types of documents and/or needing to adopt customer defined formats then once I had eaDocX there was no contest.  I use (and eaXL of course) extensively with the great advantage I can take a customer document as a template, simply place pointers to the require packages and press generate – a few minutes work without much to do.  Sparx recently introduced their own office MDG, however I haven’t had the opportunity to test this yet.

What else?

I think that covers the basic items in the product lifecycle and yes I am sure there are other items that could be added, but my aim was to have a quick review to check if the work could be done within EA.  I guess the answer is probably, but is it a complete Design & Build Platform? I’m not convinced, it’s still just a bit too hard, and if I say that as somebody who is comfortable working under the hood I’m sure I can see why it’s a challenge for others used to dealing with high level tools.  That’s doesn’t say there isn’t potential but ..

I guess Sparx have developed a product that supports their own development process perfectly, and as a single product company some of the issues such as generating corporate documentation, make files and installers plus working with a wider diverse organisation is really not a big issue for them.

EA is a great product, otherwise why would I still be using it after 13 years, and has real value if it is to be the single platform – I love the idea of a single workspace.  And as our world evolves to a dual desktop – cloud solution the ability to interact with a phone, iPad or my monster development system in a consistent manner with automatic on/off-line modes taken care of is attractive.  However, I am not representative of users, most of whom use a small set of office based tools on meagre laptops with well established processes that cannot be changed quickly if at all; what’s the incentive? what’s the risk? could it happen by stealth?

I am sure with time EA could be enhanced to address the needs of this wider team, no mean feat, or perhaps, as voiced on the forum by existing users, EA should remain focused on being a UML design tool where it already does an excellent job.


In looking at using EA as a single platform I know that the comments have really focused on what’s missing – I suspect that is inevitable as it’s easy to notice these areas. I also realise that in writing this I may not be aware of some features of EA and I’m still learning.

The more your learn the more you realise how little you know, and how much more there is to learn.

So it could be that some of my conclusions are not completely accurate but do go EXploreEA for yourselves – and let me know.


Global replace leads to EA Installation Inspector V2

For the first time in so many years of using EA I had the need to do a global text search and replace – one of my clients wanted to rename something!  Now I knew that EA did not provide anything as standard, however a quick look on the sparx community site to find an addin from Helmut Ortmann that does just want I needed – ho_Replace.  I was set and my task was done within minutes – thank you Helmut.

However, as you can probably guess it didn’t stop there.  As reading on the download page there was a comment regarding a problem with installing the tool.  Although I had installed without a problem I thought I’d run my Installation Inspector to check the entries only to discover it wasn’t listed. So how does EA know about it?

I quickly discovered that EA not only looks for AddIns declared in HKCU\Software\Sparx Systems\EAAddins, but also in HKLM\Software\Wow6434Node\Sparx Systems\Addins, a location my tester wasn’t checking.  So to help those looking for these extra AddIns I’ve modified the code, which now checks both HKCU and HLKM locations.

EA Installation Inspector V2 Screenshot

EA Installation Inspector V2 Screenshot

Also, as I often find that the line is longer than the screen I’ve added a pop-up form which displays the detail for a single entry, making it much easier to read.

EA Installation Inspector V2 Pop-Up

EA Installation Inspector V2 entry detail Pop-Up

For those who have downloaded already may be worth updating to ensure you can see the other stuff.

I’ve also been thinking about adding a facility to change the target DLL file – not least as I find that during testing of existing installed AddIns with VS it doesn’t update the DLL location as required.  Is this something of interest to others? Are there other functions that would help when developing/testing AddIns?

I have updated the entry on the sparx community site – where you can download this new release.


Back to it – and hasn’t it flown since the summer!

I’m still here, but after a summer taking it easy and spending more time than planned doing some rework on eaForms, it was all too soon back to some real world projects, helping others, which have kept me busy, and hence this meant I haven’t had too much time to be exploring EA.

It seems that after summer there is renewed energy and an eagerness to get stuff done.  I can’t complain it can be really exciting but of course before you know it it’s Christmas; already in the UK we are seeing Christmas goods in the shops and it’s not the end of October year! This also means a new deadline appears – must be done before the holiday season.  I am sure it was never like this when I was younger, but I suspect that is the view through rose tinted glasses.

However, the eaForms rework was really good fun – not that I always enjoy refactoring code, but after a few years it was good to go back to the design, and with the knowledge gained from use and customer feedback we have been able to streamline some of the internals.

It was also the chance to clean out some deadwood.  For those who may have seen eaForms a couple of years ago, the initial design used an EA diagram for the form design and keep everything within EA (see example of our initial design), it was fun (especially some of the synchronisation needed), but it didn’t give users the near WYSIWYG experience expected.

Use Case form defined in EA diagram

Use Case form defined in EA diagram – as it used to be done – now we have a WYSIWYG form builder

Removing the need to support this functionality really did help with the rework – it simplified an awful lot and allowed eaForms to become more decoupled from EA in a positive way.

This work reminded me of the many projects over the years where I had written code to fulfil requirements for functionality that was really never used.  In our case, we thought it was cool to use an EA diagram, but users didn’t!  It’s all too easy to add a requirement because it seems like a good idea but really isn’t of value to the customers, however without a crystal ball there is no easy answer.  I’ve worked in organisations who do lots of research when defining products, and I’ve seen that doesn’t guarantee success.

Apart form doing work on the internals of eaForms we added some more features to meet customer needs, notably:

  • Datagrid control – which presents collections in a flexible table format with display, editing and adding capabilities.
  • More script capabilities have been added, for example running a script on form load (so checks can be made before the user even sees the form)
  • Workflow / “Wizard” like functionality allowing the editing to be split across multiple eaForms sequenced with a defined workflow.

For those who may be interested, I’ll put together some short posts on some of these new features in the next few weeks, but if you eager to have a look today you can pop over to eaWorkplace and simply register with them to download a trial version.

It also worth noting that all of these were added to meet incoming requirements, for which I’m always thankful, as it also indicates that there is a need for eaForms.  And of course far better than me trying to double guess what users really need.

If your an eaForms user, and eaForms doesn’t do what you want, let me know – no guarantees we can do it but unless we know we can’t even try!

Be back soon