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
Hi Ian

In case it's useful I updated EA Installation Inspector (V7009) to highlight in green the currently registered COM server.

Adrian

2
Hi Eve,

I was curious by your response as it wasn't what I expected. So being me, I explored further and yes as Geert and you state the EA Com Server registration is set by the last installation. 

If I look at the EA registry entries I see that the LocalServer32 value reflects the different versions of EA and hence when you create a new instance of EA it launches the version of EA relevant for the build so consistent with my test (let’s forget AnyCPU for the moment!). 

However, the InprocServer32 for both EA32 and EA64 entries is the value set by the last installation and references Interop.EA.dll.  However these files are identical for both EA32 and EA64.  So, does it matter which directory is referenced?  Or does Interop.EA.dll uses libraries that are bitness specific?  If so why not do COM registration for the products seperately?

It would be good to know especially since a difference could create an installation order requirement (more likely for developers than users) to ensure correct operation! 

Also, it would also help understand whether the initial issue that Ian raised relates to the App that calls EA (as I had assumed) and/or which version/location of Interop.EA.dll is used.

Your comments appreciated.

Many thanks

Adrian

3
I think the issue relates to how you build your app - AnyCPU has rules which I don't fully understand!  It's neither one nor the other but supports large address spaces so will work with both 32-bit and 64-bit processes.

So what/how does it select which version to use when there are 2 valid options available defined in the registry i.e. 64-bit under HKLM and 32-bit under HKLM..WOW6432Node.

Rather than start going through docs I did a quick check on a machine that has both 32-bit and 64-bit versions of EA running.

The results were:
  • Build app x86 uses EA 32-bit
  • Build app AnyCPU uses EA 32-bit
  • Build app x64 uses EA 64-bit

Guess in this case an AnyCPU app defaults to using a 32-bit version of EA.

So by using a 64-bit build for your app you are forcing the selection of 64-bit EA as Windows will know that a 64-bit process needs to use a 64-bit app, a 32-bit app won't work.

BTW:  If interested and want to look further (and have time to spare!) a tool I find useful is Process Monitor which is included with the free Microsoft SysInternals suite - https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

If you run this app and set the filter to select on "Process Name" with the value "EA.exe" and then run your code you'll get a long list of entries, 10,000's within a second of EA starting up!   In the examples above you can see the version of EA launched depending on the application build.

Hope this helps.

Adrian

4
Paolo

Many thanks
Green is the colour that is expected if all working OK.  So looks fine.  In the rework to support 64-bit I think I've improved the checking that sets the colour.
Anybody find anything unusual/unexpected please let me know - email best - so I am made aware and I'll try to resolve.

5
Hi
Sorry I don't check out the forum much these days, but Ian alerted me so just read this thread and a couple of thoughts which I hope are helpful.

As I understand it:
* VS2022  - registered as compiled as x86 (not AnyCPU as Geert has said this will register as 64-bit) or manually using regasm
* 32-bit addin

From the latest log:

1. EA knows about yout AddIn hence the keys are correct and the DLL is registered.  You mentioned before that EA Installation Installer was Cyan - this can also indicate that the DLL has been registered without /codebase option however a bit confused as it seems to have loaded OK  - but you've got past that now.

2. However, looking at your latest information it looks to me like something (resources referenced by your code / project / DLL) is missing and hence when loading the DLL the core library throws an exception.  Worth checking the project for anything that may be referenced but is not present in the dll location ( specific - e.g. non-system - libraries) or embedded (icons, docs, ..)

BTW: I have just updated the Installation Inspector to V7 adding 64-bit support.  What colour does it show now - be interested to know if it differs?
This also meant I've had to change the way some information was obtained as well as tightened some of the checks, but still early days so sure I've missed something (let me know!).   Also the documentation now includes a list of registry locations which may be useful.

Adrian

6
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




7
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





8
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.


9
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)

10
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.
 



11
@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



12
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



13
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


14
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.

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

Pages: [1] 2 3 ... 12