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 ... 12
1
General Board / Re: Reading data from imported MDG
« on: October 31, 2018, 02:58:55 am »
Hi

As Qwerty says only way to get the MDG information is to read the relevant files, note that there may be MDG files within Sparx Program files area e.g. "C:\Program Files (x86)\Sparx Systems\EA\MDGTechnologies"  as well as within the users appdata e.g. "\Sparx Systems\EA\MDGTechnologies\"  - that caught me out 1st time I did it.

You then need to parse the relevant files to extract the information you need.

Adrian




2
Hi Rich

In my experience there are 2 issues when exporting large amounts of data to Excel:
  • Excel Interop - each call has an overhead and this can soon be significant
  • Extracting data from Sparx using the API
To address the Excel issue my approach is similar to where you got to, i.e. not using Excel at all but using a library that can generate Excel format files.  In my case, I have used EPPlus .  This had the further advantage of having no dependency on Excel, hence can be used on a computer where Office may not be installed.  When developing code for a large export, tests indicated a 100-fold improvement.

Having addressed the Excel issue, and as Geert mentioned, the time taken to extract information from EA can be significant when working with large databases (or those that are in a cloud somewhere).  My approach is  to reduce the number of interactions with EA; ideally at most a few SQL queries.  I then:
  • Either have the data I need directly from the query
  • OR can process the query results in my code to produce the required output data

The results in my case has been that reports from repositories with 10K's elements and excel files with 1000's rows can be produced in seconds rather than in 10's of mins.

And all done using VB.Net.

BR
Adrian





3
If anybody is interested this pop-up issue is resolved, although MDG integration for VS is not fully working for me yet.

I found that EA/MDG was getting errors looking for some of its "web" files which were not present on my system - looks they didn't get installed, not sure why as no warnings during installation (thank goodness for Procmon).  So uninstall (to allow a tidy up) with registry clean and reinstall; this time all the files appear to be installed OK.  Interestingly, I had done a clean install on another machine and got exactly the same issue!  Is it permissions?

Now I have an issue with UML documentation with the ea.js file which I need to explore ???  But at least I can do some initial experiments - I'll capture the information so I can use in a future post for my blog.


4
Bugs and Issues / EA error dialogs pop-up when using MDG for Visual Studio
« on: September 26, 2018, 09:19:50 pm »
Hi

Just started looking at the MDG for Visual Studio (again) and early stages, but every time I try to do something involving the EA Project Explorer I get a series of pop-ups e.g.
  • Couldnt find html template file
  • Couldnt find ea.css
  • Couldnt find ea.js
  • Couldnt find index.html
  • Couldnt find top.html

Which is more than a little annoying plus the dialogs don't pop to the front so need to search for them.  I assume this is something simple such as an environment variable that needs to be set so that the EAVS stuff can find the files.

Any ideas?
Whilst posting has anybody seen any documents on this MDG later than 2009 - which references VS 2005/2008?

Thanks
Adrian

EA build: 1427
VS-2012


For those who may understand this the error message is:
Code: [Select]
System.InvalidCastException: Unable to cast COM object of type 'EA.ModelWatcherClass' to interface type 'EA._ModelWatcher'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{23E29B09-8870-4ED9-844C-74DCEA6C06AC}' failed due to the following error: The RPC server is unavailable. (Exception from HRESULT: 0x800706BA).
   at System.StubHelpers.StubHelpers.GetCOMIPFromRCW(Object objSrc, IntPtr pCPCMD, IntPtr& ppTarget, Boolean& pfNeedsRelease)
   at EA.ModelWatcherClass.GetRefreshXMI(String& Item)
   at Vsip.VSIntegrate.EAProjectControl.timerUpdateTree_Tick(Object sender, EventArgs e)

5
Hi Geert

Thanks for the info.  As you can see from my comments above there seem to have been some changes, not surprising it was 2014 when I did my previous tests, and it appears to work fine - to my surprise.

It is a simple test that has 2 addins both know to EA, and with AddIn1 having a reference to the DLL of AddIn2 to allow it to build.
To check operation and ability to get state information:
* AddIn1 - creates an instance of the AddIn2 class and calls a method to retrieve information from AddIn2
* AddIn2 - via an EA menu or context change (events used for checking) will update some static variables which are then used as part of providing the information to AddIn1.

I am sure that there are some other test cases that should be run.

BR
Adrian
PS: Sorry for any confusion caused.
 



6
@Geert -
Quote
Yes you can execute public operations on an installed add-in. That is precisely what EA is doing.

When I did my tests (albeit a while ago now) I found that the calling an AddIn from an AddIn loaded a separate instance of the DLL, hence state information (for the EA called AddIn) wasn't present.  Are you saying you could access the instance of the DLL that EA has loaded? I am interested to know more about this please.[/s]

CORRECTION: It has changed and as Geert explains you can create an instance of a class contained within another loaded AddIn and call its public methods.  That will teach me to rely on old (clearly out of date) tests :o

Of course, your approach using an AddIn manager would work as the DLLs would be loaded by the AddIn manager and hence within the same context.


Thanks
Adrian



7
Hi

In response to your queries - this is my understanding (mainly based on some experiments I did a few years ago.  I wrote up in 6 or 7 blogs posts starting with Customising EA, in particular see Calling a running AddIn from a script which was looking at call an AddIn from a script (which could similarly be another AddIn). Another caveat- I assume normally programming and not poking around in system tables to look for entry points, etc!

Is there a way to access (public) functions of one addin inside of another addin?
Yes if you consider your other AddIn is only DLL that can be called and access any public method; HOWEVER this would be as a DLL within the context of the calling AddIn and NOT within the context of EA and an instance of the DLL that it could load separately and which would have its own state other actions resulting from calls from EA to that AddIn. 
CORRECTION: Further to Geerts comments I was curious so rerun some tests and it now looks like EA only loads a single instance of an AddIn DLL. Therefore when creating an instance of a class in the other AddIn it is using the same DLL instance.

FYI: My test consists of 2 addins.  The first has a menu option to call the 2nd and retrieve information (time of day, some counters and context for currently selected item), the 2nd AddIn has a menu option to allow me increase the counters.


Is there a way to raise an EA_MenuClick signal to trigger an addin?
No, this is an EA event and cannot be initiated from an AddIn action

can i then also call an addin on them (through the menu)?
You can dynamically provide AddIn menu options.

However, it would be useful to get a better idea of what you are want to do rather than assume it has to be multiple AddIns as there is probably a way to design an AddIn that would fulfill your needs.

Hope this helps.
Adrian



8
General Board / Creating / coding a c# windows application in EA
« on: September 19, 2018, 04:48:13 am »
Hi,

I have been exploring producing a C# Windows applications using EA, unfortunately the documentation seems a bit light in this area and hence I'd like to check with others who may have succeeded (or not)!

I have used the Model wizard to create a c# windows app.  It produces a package with form classes, with source code, project files, etc (all just copied a zip file), plus scripts.  So I can use the scripts to build and run the solution - OK. However, I am curious and want to check that I am not missing anything that can help beyond a trivial example.

So if, for example, I want to add more code to produce a real application, e.g. another dialog:-

1. Adding another form / class.
I create a diagram using Win32UI MDG for a dialog but it looks like I can only export a .rc file (c++) so no good (directly) for a c# project.  Therefore, I assume I need to create the 2 classes (assuming I want to view the form - which looks like I can only do in VS or similar) for my form and then type the code for the "form" and its "designer".  This means that it's only relationship to the EA screen design object will be a link (realisation) between these classes and the dialog.

2. Editing project/solution/resources
When adding classes there doesn't seem to be a mechanism to view/edit the project (and other) files to add a new class.  Hence I assume I need to edit these files (.csproj, .sln, .settings, assembly files) outside of EA.

The same issue exists when working on a class library (e.g. an EA Addin). I can produce and edit all the classes fine within EA however there doesn't appear to be a mechanism to create the project/settings/resource files?


So just to check.
  • Are my observations correct
  • Is the pattern just a "noddy" example, using predefined code without the potential for extension
  • EA doesn't provide support for coding a real c# windows application

Perhaps somebody who has done real code development of windows apps within EA may have some experience/comments on EA's capabilities that I have missed. Are there other development tools/addins besides VS / Sharpdevelop that are useful for code development with EA?

Many thanks
Adrian


9
Not entirely clear what you are wanting to do.
If you want to launch a specific instance of the EA application programatically you can use  the microsoft ProcessStartInfo Class. For example, in VB.net the following will launch the .exe you specify.


Dim p As New Process
p.StartInfo.FileName = "C:\Program Files (x86)\Sparx Systems\EA\ea.exe" ' filename of specific EA .exe so could point to a different directory which has a different version
p.StartInfo.Arguments = "C:\Users\EXploringEA\Downloads\123.eap" 'e.g. filename of eap
Dim hasItStarted = p.Start()

This will launch the required version of EA and assuming its completely OK for different versions to coexist this should be fine.  I did a quick test and all seemed to work OK, but best ask sparx to confirm multiple versions are OK and there is no potential crossover.

Hope this helps.

10
Yes - uses the diagram.diagramobjects then for each of the diagramobjects use the ElementID to access the element object and its properties

11
I had this requirement sometime ago and used EA_OnNotifyContextItemModified but this doesn't let you know if this is due to a tagged value change. 

Hence, my approach was to use EA_OnContextItemChanged to track the selection of an element, and take a copy of tagged values before any changes.  Then when ContextItemModified is triggered a check can be made to see if there is any difference for a tagged value.  Not ideal.. 


12
Hi

Github for Installation Inspector is on the EXploringEA site and is https://github.com/EXploringEA/EAInstallationInspector
(Note: the code on GitHub is for V4 - not the current development release)

Regarding you problem can you post the contents of your cmd file that you have found doesn't work and I can take a look.

Regards
Adrian

13
Further to Helmut's post - I have a newer version of the tool which can provide additional information e.g. Registry Tree view which may help.  For details and download link go to http://tools.exploringea.co.uk/index.php?n=EaInspector.Development.




14
Helmut,

Seems like a valid experiment rather than pure luck, and fortunate that you got a meaningful message!

All makes sense as loading the AddIn DLL is exactly what EA does.

Good to have a logical reason (and test).

BR

Adrian


15
Hi Helmut

Thanks for the information - I'd better make a note of this for future reference.  It is something I would never have thought about - what gave you the clue or was it just luck you found the solution?

BR
Adrian

Pages: [1] 2 3 ... 12