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 - Helmut Ortmann

Pages: [1] 2 3 ... 65
Thanks a lot.

I think I have got the picture.

Best regards,


Hi Geert,

Thanks for your correction. Updating, deleting, or writing the code into EA shouldn't be too complicated.

Hi q,

Could you explain the wrapper? I only have a rough idea.



Automation Interface, Add-Ins and Tools / Re: MSScript for EA 16 64 Bit
« on: September 28, 2023, 07:50:18 pm »

OpenSource tsc64.dll (64 bit Tablacus Scripting Control) solves the issue. It's a 64-bit replacement of Microsoft ScriptControl ActiveX.


Good luck,


Sounds good.

What are your experiences, pros and cons? Would you recommend this approach for big projects?

In Scripting with JavaScript in the EA environment, we must synchronize the code. EA-Matic could do this.

Thanks for your answer.

Automation Interface, Add-Ins and Tools / Re: Integration with TULEAP
« on: September 28, 2023, 07:39:13 pm »
Some time ago, I've developed an Open Source EA AddIn to:
- Import ReqIF
- Export ReqIf
- Synchronize EA with ReqIF file/*.zip

The ReqIF support is only a part of this AddIn.

You find it at:


Have you tried an external JavaScript IDE like VS Code, Eclipse or WebStorm to develop your JavaScrips for EA?

External IDEs are powerful. They lack the EA integration. Do you have any experiences?



Automation Interface, Add-Ins and Tools / Re: MSScript for EA 16 64 Bit
« on: September 25, 2023, 07:50:41 pm »

The error seems to be known and confirmed by SPARX:
    Best regards,


Automation Interface, Add-Ins and Tools / MSScript for EA 16 64 Bit
« on: September 22, 2023, 06:14:59 pm »

I want to use MSScript for EA 16 64 Bit to start a JScript. The existing MSScript seems not to run in the EA 64 Bit environment.

Is there a way to start a JScript via MSScript or a workaround?

Thanks for your help.



If you want to run long-running SQL in parallel, you can use the BackgroundWorker, as Geert suggests.

You will get real parallel processing if you create a second EA.Repository object and use this in the background. Be aware, That you then have to ensure thread safety and the disposal of the second EA.Repository object.

I've tried it, and in my case, it works.

Best regards,


Hi Geert,

Thanks for your answer.

It works pretty well for things like doing a lot in the background. I've already done such things, and I'm happy with this. A lot of short-running EA API calls are no issue.

Sadly, this approach doesn't work for a long-lasting API call to EA COM-Object like 'repository.SqlQuery()', which, in my case, may need minutes to complete. During the time to complete the method call, the main thread with the GUI is blocked by the BackgroundWorker. After the call, the main thread can run until the following API call to COM occurs.

In the meantime, I've googled and tested a bit.

Using the EA COM-Object (Repository) runs in a STAThread, which essentially states that this is a thread-unsafe call.

The BackgroundWorker is a MTA thread. The MTA background thread blocks the main thread until the call is finished to ensure that the thread-unsafe COM object will not cause any harm.

That's what I have understood.

The solution could be:
Making an own STAThread as a background thread.

I made a little test and confirmed the blocking of the main thread and the thread types (main: STAThread, background: MTA).

It all looks a little complicated and unpredictable (Thread handling, ????)

Best regards,



Can a long-running EA API SQL (repository.SqlQuery(sql))) be put in the background of the C# AddIn? During running this SQL, the AddIn GUI should be responsive for other tasks.

I have tried the BackgroundWorker. The BackgroundWorker works fine for not EA API calls. However, in the case of the API call 'repository.SqlQuery(sql)', it blocks the AddIn until the call is finished.

For other tasks, which may include short EA API Calls, the BackgroundWorker works fine. For example, I use it to load model content while starting the AddIn.

STA Threads may be a solution. But does anyone have experience with such background work?

Thanks and Best Regards,


I think I have found the issue.

I have to hide the DiagramLink. Deletion doesn't work.

This is done to make it easyly possible to let reappear a Diagramlink.


I tried to delete DiagramLinks and it seems not to work. The deletion of DiagramObjects work as expected.

Any idea?

Thanks and best regards,


for (int i = dia.DiagramLinks.Count - 1; i >= 0; i = i - 1)
                        dia.DiagramLinks.DeleteAt((short)i, true);
for (int i = dia.DiagramObjects.Count - 1; i >= 0; i = i - 1)
                        dia.DiagramObjects.DeleteAt((short)i, true);


Thanks for your valuable questions. My revised question:

- EA 15.2 Build 1555
- PCS Version 4.2.66
- DB MySQL, connected via PCS to EA (no direct access to MySQL from EA, only via PCS)
1. Timeout
- Some queries are sometimes leading to TimeOut (around 60 seconds)
- Import large packages lead to a timeout (around 60 seconds)
2. Rename Package: Slow GUI, fast Script
- If I rename a package with the EA GUI it takes about 2 seconds
- If I rename a package with JScript from within EA it changes it immediately

EA works fine except for the above-described issues with large Repositories and some big queries. In smaller Repositories, there are no issues. It looks as if the issue only appears in situations with a great load. In the evening it often runs smoothly.

Thanks and best regards,


Pages: [1] 2 3 ... 65