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
1
Automation Interface, Add-Ins and Tools / Re: Get SysML values per API
« on: March 11, 2025, 01:23:30 am »
Hi,

the SysML values are stored in:
- t_object, column=runstate

How I found it:
- Make a small model
- Make a Value with a unique name like 'xxxx'
- Native export (Publish menu)
- find the string like 'xxxx'

Good luck,

Helmut
 

2
Automation Interface, Add-Ins and Tools / Get SysML values per API
« on: March 11, 2025, 12:43:39 am »
Hello,

I try to get the SysML values per API. In the GUI I can access them via DiagramObject Context, Feature, Set property value.

How can I access the per API or per table. I searched the tables like t_xref, objectproperties, t_attribute, t_taggedvalues,... with a simple model containing one Part and one Value of the part.

Any idea?

Thanks,

Helmut

3
Hello,

on a Diagram I show a Property/Part as a DiagramObject with an image assigned to it.

Now I want to show a small text string beneath/beside the DiagramObject. The best would be the value of a TaggedValue but any related information would do.

I have experimented a bit with visualizing compartments. They are visualized as labels. Too much information.

I just want a small text.

Do you have an idea? Dynamic Diagrams? Or?

Thanks,

Helmut

4
Thanks a lot.

I think I have got the picture.

Best regards,

Helmut

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

Thanks,

Helmut


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

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

See:
https://tablacus.github.io/scriptcontrol_en.html

Good luck,

Helmut


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

8
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:
https://github.com/Helmut-Ortmann/EnterpriseArchitect_hoReverse

9
Hello,

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?

Thanks,

Helmut


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

The error seems to be known and confirmed by SPARX:
- https://sparxsystems.com/forums/smf/index.php?topic=46571.0
    Best regards,

    Helmut

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

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.

Helmut

13
Hi,

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,

Helmut

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

Helmut




15
Hello,

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,

Helmut

Pages: [1] 2 3 ... 65