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

Pages: 1 2 [3] 4 5 ... 10
Bugs and Issues / Operation of TaggedValue HasAttributes fails
« on: July 08, 2015, 04:43:35 am »
I've been trying to use the taggedvalue methods such as HasAttributes (, but have been getting EA error messages (code 0xc00ce556)  (also see post on automation forum -( where you see that another experienced forum member has found the same issue with EA.

Tested with EA build 1214, corporate edition.  OS Windows 8.

  • Can you advise if there are any known issues with this method or the other TaggedValue methods?
  • What does the error message "Invalid at the top level of the document" mean?
  • Are there any preconditions/assumptions that could lead to an EA error message?  
  • Can you provide more details of what the error message means?  
If not, is there more information or examples of use available.

Many thanks

Automation Interface, Add-Ins and Tools / Re: Call Addin from JavaScript
« on: August 11, 2015, 08:55:23 pm »

yes loading an AddIN (i.e. a DLL) is straightforward from scripting - yes the problem is accessing the already running DLL.  My initial tests, some months ago now, didn't succeed and I have the idea of doing some more.  As you say it should be possible as it's only finding the correct table entry in the windows OS and when I get some time I hope to sort it out - perhaps the Christmas holidays!!

However, if you are not worried about state then you could load the addin as a new instance, and I guess if you wanted to respond to EA AddIn events that's where EA-Matic could come into it's own - is it realistic for it to capture and pass on all events that are configured?  Seems a genius idea.

Automation Interface, Add-Ins and Tools / Re: Call Addin from JavaScript
« on: August 07, 2015, 06:36:45 pm »
Hi Geert

I must admit I haven't looked at your code, which probably has the answer, but interested to know the approach to getting the reference to the addin as this was the problem found before when working within the scripting thread.

Is your approach to launch the addin from the scripting environment?

I will look at the code when I get time - but curious to know!



All depends if you want to call the running Addin and access current objects or access a DLL that is not "connected" to the running instance of EA.  The problem is finding the relevant reference to the addin DLL.

If you create an object for your DLL there is no problem, however trying to get a reference to the EA "connected" copy proved problematic.

I wrote a post outlining my unsuccessful experiments

Let us know if you find a reliable means to identify the addin object as I'm sure there are a few out there who would like to use it.


If you look for menuLocation parameter in the calls such as EA_GetMenuItems / Menustate / MenuClick  - it is a string representing the part of the user interface that brought up the menu. This can be TreeView, MainMenu or Diagram.

If you right click on an item you will probably want to check the type of item as you will get an object (e.g. myObject = Repository.GetContextObject ) then if you are looking for an element  you can use myObject.ObjectType = EA.ObjectType.otElement  or similar for other item types

Hope that helps.

Automation Interface, Add-Ins and Tools / Re: Sharing an Addin
« on: July 01, 2015, 04:59:29 am »
I also wrote a blog on the topic with a description of what bits need to be where you can find it at

The utility I developed can be downloaded for free from the sparx community site.

Hope that helps


Not sure I've seen this before, but when I make a call to Tagged Value HasAttributes method, I get an EA error dialog pop up - with error code 0xc00ce556 and description "Invalid at the top level of the document"

My code is checking a set of tagged values,  and I assume the error is because one of them is not a structured type;  is that a pre-condition for making this call?  may be implied but not clearly stated (and when I call Getlasterror it returns an empty string).  If this is the case, is there an easy way to determine if a tagged value is structured, other than making a search in t_propertytypes for all tagged values?

I assume I am correct that the taggedvalue attributes relate to the structure type properties or perhaps I've misunderstood something.  

BTW: Even with structured types I'm not getting the results I would expect - has anybody got this part of the api working reliably?

Any information would be welcome.


Automation Interface, Add-Ins and Tools / Re: Live Automation Changes
« on: June 03, 2015, 02:17:58 am »
If I understand the question you use a repository method

- Repository.AdviseElementChange(myelement.ElementID)

Worth checking out the other Repository methods that are available following changes e.g. RefreshModelView, RefreshOpenDiagrams

I have a hunch that the EA UI and your tab control could be in different threads. I had some issues with some of my code doing something similar i.e. EA UI and my own tab control, and getting cross-thread exceptions being thrown.  

I did look around at the time for solutions but the problem I saw was getting into the EA UI code, not least as I needed to understood what object was being dropped.

From memory one approach I looked at was to:
1. Track the selected item using context change events
2. Have some windows graphics code intercept all mouse events, catching the release of mouse events, and checking if the coordinates were in my window.  

In the end it wasn't nice so gave up on it - but if you find a reliable solution please let us know.

A further thought I had after posting my initial response.  Unless EA provides a mechanism to let you "take the element" and let you tell EA that you have handled the event, as some addin events support, you will still get the unwanted message about not dropping on a diagram.  

Glad that I could provide a little help.

Also I'd be interested any feedback you have in applying to your testing which could be a lot different from my proof of concept.  Any problems I'm always game for a challenge 8-)

Curious to check whether the approach I have suggested worked, I performed an experiment using a test AddIn. My tests automatically:
  • Added content to an EA model
  • Ran a check to verify the correct results - i.e. the AddIn worked
The experiment was successful  :) and documented in my latest post Automatic testing of EA AddIns which can be found at  
Direct link to post -

I think this is a really interesting issue.

The main problem you have is that the AddIn events are only fired by EA UI actions. Perhaps Sparx can have a setting that can be enabled for AddIn testers to fire these events when the creating/deletion/etc... is created pro grammatically?

So I guess you will need to get one of the "GUI application" testing tools that operate as the "human" using your recorded action which can then subsequently be executed automatically.  Using these with a combination of EA scripts, that you may need to write to do some further detailed checks to output results to an additional test log file during your test runs, could well address most of your requirements.

It may not work exactly as you would like, but at least it would save you the manual effort to perform the bulk of your testing.

BTW: It's been decades since I've used these testing tools but I assume they still exist, and I would imagine they are more powerful than I remember so could do even more.

Hope this helps, and if you do look at these tools I would be interested in feedback.


One thought - is your AddIn interacting with any other process e.g. Using a com service - if it is then the problem could be related to that.

When I am using com services I usually track the relevant processes and  when EA is closing I check if the processes have ended, and as necessary kill them :-X but not often, so I can ensure they are closed otherwise EA can hang.

Of course, if you're not doing this then this suggestion won't  apply.


Yes using an installer is best, however during the development you don't need to go through the process of creating an installer until it is stable and/or ready to deploy to users.

As you state it's not too difficult, there are plenty of tutorials on creating a Wix installer, but some are confusing and may not relate well to the needs of an addin developer. For me it was remembering which stuff to include and where.  Like you I soon produced a template that I use for creating virtually all my addins and their installers which is really useful, not least as a check list of what to include/where.  However, I also saw little demand for AddIn or installer "helper" products - I even started writing a book on addins about 3 or 4 years ago but my interest waned when I saw there probably wasn't a market, so just keep a private wiki iof useful stuff instead.

Coming to the point you make about com registration and admin is interesting.  I'm not a windows OS expert (too new an OS for me!) but had assumed that to make changes to the registry (at least in Win 7 onwards with GAC) you need admin rights.

It may be wrong or specific to my system(s), but I've seen some issues with VS when it hasn't been running as admin and failing to register a DLL.  So worried that I imagined it I've just rerun a test (as a normal i.e. non-admin user), and on building one of my AddIns I got an error message:

Code: [Select]
Error 44      Cannot register assembly "C:\Users\NormalUser\Documents\Visual Studio 2012\Projects\eaForms81439\eaFormGenerator\bin\x86\Debug\eaFormGenerator.dll" - access denied.
Please make sure you're running the application as administrator.

I remember this situation changed when I moved from XP to Win7.  I had always assumed it was a consequence of how the OS GAC is configured.  Never really explored it further, so just accepted I needed to ensure that EA wasn't running and I ran VS as administrator before I built my solutions.

Of course, my observations may not be typical, but I do feel there is more to it other than it isn't an issue of privileges or locks.  Unfortunately it would take some time to understand all the rules and if there is an easier way....

As one of my colleagues always reminded me years (decades) ago "always work at the lowest possible privilege level" - but that also means spending time working out what is essential and what is nice to have. Easy just to work as an admin user. :)

Finally, coming back to the original reported issue,  Stenvang hasn't indicated any error messages - so I would have initially discarded the saving of the DLL more about where the registry thinks the class is linked.  So  think getting the key information from the registry to see the mapping between EA and the class and the linked DLL file is key to getting a clearer understanding of the issue.


Good point - although already suggested it is an absolute must, so worth emphasising to make sure it's double checked.   Especially if you are relying on shortcuts - which could well get modified - and in view of the observed change in behaviour, don't assume anything.

Pages: 1 2 [3] 4 5 ... 10