Add-in user friendly

[ChrisMW]

After getting some fine pointers here, buying some books, I'm revisiting the 'write your own EA add-in'. It works well, except for one point.

I'm going through a package structure and it takes some time (I still have to digest the using SQL statements for increased speed.

Anyway, the speed is fine (for now), but I'd like to display some kind of progress while it is gathering the info. I've been unsuccessful in getting a window running in a seperate thread. Writing to system output works, but only when my menuhandler ends, you get to see it.

I'm hoping there's a friendly way to do this, other than moving the code into a form and doing it there. As I'm collecting data, then the users gets to twiddle with the results before deciding how to proceed, it would require quite a bit of rethinking on UI's and bar for the progress display, I'm already happy with how it works.

But the async displaying I'm trying for is elusive, so I'm sort of assuming I just need to create a UI that covers collecting, processing. I was hoping I could collect before display the UI, with just a simple progress bar.....

Suggestions?

[Geert Bellekens]

Hi Chris,

Progress bars are never simple.

The proper solution would be to use a separate thread to show the progress bar.

An easier solution might be to first start up the gui for the progress bar, and then after processing each element launch an event.
Your progress bar can then subscribe to that event and move the progress bar when it has been launched.

This approach will only work if indeed you are processing a bunch of elements, and you can indeed send out an event in between elements.

But you must be doing some serious stuff if you really have the need for a progress bar.
Maybe it might be more rewarding to put this effort into using SQL to select the elements instead of iterating Package.Elements.
This often yields an enormous performance boost. (I've known programs to go from 20 minutes to 20 seconds just by using SQL iso Package.Elements)

Geert

[ChrisMW]

Hi, I've tried using a modeless window in a different thread, but it seems that it doesn't sit well with EA. I've also tried the backgroundworker on the progress dialog and that failed. Although I'm now thinking I read something about TLS being different in .NET nowadays. My .NET knowledgde is a little dated, say .NET 2.0, so probably the problem lies there.

I was hoping someone had a working example I could adapt.

It's not that long, max is around 2 mins, but since EA 12 I've noticed that the GUI 'jumps' a little after about 10 secs or so. And seeing there's no visual clue things are going well, I'd like to have something there.

SQL might be an option, but at this point, the API seems fine. I can't find any documentation on what you can and cannot do in a thread. So I could simply move the processing to a dialog, which feels wrong, make a complex dialog (something like a wizard), which is a lot of work for a simple task and I've even been thinking to simply not make an add-in, but write a standalone program. The latter would be a lot of work, and again, don't feel really validated in this case.

I'd like it to be C# and .NET, as those are the ones I'm most familiar with, albeit from some time ago. As most repositories I have are either eap or PostgreSQL databases, SQL seems a step too far, not wanting to have to cater for different SQL dialects (which would mean I would want to wrap the SQL dialect in a set of classes to keep it out of my functional layer).

I'll have a look and see if TLS is now separated (I remember you objects being shared across threads and writing code to prevent accessing members from different threads at the same time).

[Geert Bellekens]

Chris,

My EA Navigator add-in uses a multithreading approach.
It gets the details of an element in a background worker thread and only updates the GUI when the data is ready.

You can check the source code for it on github: https://github.com/GeertBellekens/Enterprise-Architect-Toolpack/blob/master/EANavigator/NavigatorControl.cs


But still, you can't live without SQL when writing add-ins. Your 2 minutes could go down to 2 seconds if you use SQL to select the elements.
Usually you don't have to worry much about the different dialects.

I wrote some functions in my add-in framework to cater for the few differences there are. Check the Model class for the SQL formatting stuff. https://github.com/GeertBellekens/Enterprise-Architect-Add-in-Framework/blob/master/EAAddinFramework/EAWrappers/Model.cs
I'm pretty sure you'll spend a lot less time going the SQL way then any other solution (and you'll get a performance boost as a added bonus)

Geert

[ChrisMW]

Thanks Geerrt, lots of inspiration to be found in the links you gave. Will try some of the ideas. I will possibly go to SQL sooner, as you've provided a nice headstart.....