Modify connector PDATA retrieved via get_MiscData

[netripper]

Hi there,

I'm currently writing an add-in to automatically update the label geometry of connectors in sequence diagrams. I'm referring to the box around the label in the image below. The reason I'm trying to do this is described in another thread.


After lots of trial&error and checking database queries I found that the coordinates of the label box are relative to the coordinates of the connector. They coordinates I need to update are stored in PDATA5, which can be retrieved with get_MiscData(4).

Now I have a problem. I want to automatically update PDATA5, but there is no set_MiscData(..).

Is there any other way to update PDATA5? Or can I easily execute queries on the db manually in my add-in?

Thanks in advance.

[thomaskilian]

I guess if you're exactly knowing what you are doing then it should not be a problem to fuzz with the DB. However, you should ask for a formal PDATA support. The API is still back-dated...

[«Midnight»]

Yes, that's where it is stored.

The PDATA fields contain 'magic' data that EA uses for its own nefarious purposes. This is stuff that's been tacked on as EA evolves, and doesn't fit into the schema, which has not changed since EA 4.0.

So, the solution, then the caution. [Read them both, lest strange results be visited upon you.]

Yes, you can open the EA model via automation. You can do so while EA is running in the foreground on the desktop, or in the background as an invisible COM server. Call the Repository.ConnectionString to get the connection string EA is currently using. [Professional and Corporate editions of EA open models in shared access mode. If you write your own connection string (as I do) make sure you don't open the model in exclusive mode if you want to share it with an EA instance.]

The caution is that EA is also using these fields. What EA puts in these fields is mostly undocumented (thus 'magic'). Be very careful with them if you intend to change anything. Most of the time these are formatted strings, with different sections separated by a trailing semicolon. But this is not guaranteed, so inspect carefully before writing your data. Only modify the part you need, and leave the rest of the entries just as they are.

Finally, EA can change how these fields are used at any time. Make sure to test after each build - though you'll likely be OK if you followed the directions above and the release notes don't indicate any related functionality has been added, changed, or removed. Make absolutely sure to test fully after any version (major or minor) change!

HTH, David

[netripper]

Thanks David and Thomas for your input.

I have finished the plugin and solved my problem by communicating with the DB directly. I didn't have time to wait for Sparx to implement additional API calls. Furthermore we have a pretty strict policy about upgrading to newer software versions in the middle of a project.

Communication with the database was already handled by the Repository. It has the "Execute()" and "SQLQuery()" methods to query and to update the database, without having to make your own connection with the DB. The SQLQuery method simply returns XML with the resultset in it.

If anyone is interested, the add-in can be downloaded from my website (direct link). The source code will also be available there in a few days.

[«Midnight»]

Well done!

This is, of course, why those methods exist. They won't do everything you might want, but they clearly solved this one.

Issues with the PDATA fields are fairly common, so you've also done a good thing by making a solution available to the community at large. So...

Thanks! This really does mean a lot.

Might I suggest that you consider contributing the solution to the EA Wiki. The coordinates can be found as follows: Open the top thread in automation - the one that always 'sticks' in first place - and read the top post. The address of the EA Wiki is in the footer.

Thanks again,
David