Opening Repository from API in VisualStudio, no UI opened.

[YvesC]

Hi there,

I am using EA Version 14.1.1428. When I try to open the Repository through the Interop Interface using Visual Studio/C# (see the following code abstract), a new EA background process starts on my PC but the Application itself does not start so that I don't have access to the UI. And surprisingly enough, the Repository.OpenFile("filePath") function returns "true" as if everything was allright.

Here is the code I used:

private EA.Repository myRepo = new EA.Repository();
private myRepoPath = "Valid eap file path";
myRepo = OpenRepository(myRepoPath, myRepo);

...

        public EA.Repository OpenRepository(string thisRepositoryPath, EA.Repository thisRepo)
        {
           if(thisRepo.OpenFile(thisRepositoryPath))
            {
                return thisRepo;
            }
            return null;
        }
...

And if I try to use the statement...

private EA.RepositoryClass myRepo = new EA.Repository();

...the compiler complains that the RepositoryClass cannot be embedded.


Am I doing something wrong or is this a bug?

Thanks a lot.

[Geert Bellekens]

Can you explain your use case?

I've never needed to start a new instance of EA with the GUI.
I either start a new instance in the background, or I connect to the existing manually started instance

Geert

[YvesC]

Thanks for the prompt reply G,

Actually, I wanted to use the "GetTreeSelected" functions from within C# since I need to write processing code that should apply only to subareas of the repository.

But you know, I have been using EA for many years now and if I recall what I did a few years ago, I was under the impression that the UI was opening automatically when loading an .eap file as I tried to do in previous versions. Am I wrong?

Having said that, if opening the UI is not the default behavior, how could I do it from the C# code?

Thanks again for your help!

[Geert Bellekens]

You can use Repository.ShowWindow (long Show) according to the manual https://sparxsystems.com/enterprise_architect_user_guide/16.1/add-ins___scripting/repository3.html

Have you thought about running your code as an add-in? Then you could add a context menu to start your functionality.

Or else use the InvokeConstructPicker method to allow the user to select an element or package.

Geert

[YvesC]

Thanks again,

I already tried the ShowWindow(long Show) method and it does not work and I think it is simply because I don't have an handle on the right instance of the EA process. If I launch the Application manually before trying to open the Repository programmatically, the UI instance is not the same as the one I get from the OpenFile() method. So, pretty predictable the the ShowWindow sent to an instance that is not opened in the UI could not actually show this Window.

The Add-in solution rings a bell but this would make the whole development process heavier. I would have wish to rely only on VS as my development environment. But if I have no choice, this is what I will do.

Regarding the InvokeConstructPicker method, unless I misunderstood your point, I don't think this would help in my case since I wish to rely on the flexibility of the user interacting with the UI to taylor the kind of processing I will get. The InvokeConstructPicker needs its arguments to be set at design time, not at runtime. Or if I want to set them at runtime, this is a catch 22 since I will need the UI to provide them...

Anyway, from your last reply, my conclusion is that this is the normal behavior of the Repository interface and that there is no way to open the UI from a programmatical instruction through the Interop API, right?

Thanks again!

[YvesC]

Hi again Geert,

FYI, I found the solution.

After opening the Repository, we must add the following:

myRepo.App.Visible = true;

Thanks again for your help!

[Geert Bellekens]

The Add-in solution rings a bell but this would make the whole development process heavier. I would have wish to rely only on VS as my development environment. But if I have no choice, this is what I will do.

You can still use VS to develop your add-in. I do so for all of my add-ins.
Big downside of add-ins is that you have to install them, which requires local admin rights.
(There is a workaround, but it's quite complicated)

Geert