error when using api to delete a diagram link

[arose]

I'm developing an EA addin using VB6, and have encountered an apparent bug when attempting to delete a diagramlink.  The call the triggers the error is:

Set moCurrentDiagram = moCurrentRepository.GetCurrentDiagram()
...
'Delete some diagram object
...
For i = 0 To moCurrentDiagram.DiagramLinks.Count - 1
    'if (link meets certain criteria) then
        'THIS CALL TRIGGERS THE ERROR
        moCurrentDiagram.DiagramLinks.DeleteAt i, True
    'end if
Next i
moCurrentDiagram.DiagramLinks.Refresh

These calls produce the same error:
        moCurrentDiagram.DiagramLinks.DeleteAt i, False
        moCurrentDiagram.DiagramLinks.Delete i

The repository is a MS SQL database, and the error displayed in a msg box is "Microsoft OLD DB Provider for SQL Server [-2147217900]  Invalid column name 'true'."

I can inspect the contents of the t_diagramlinks table to see the results of API calls and user actions.

Using the EA GUI, the deletion of a diagram object causes the appropriate t_diagramlink rows to be deleted when the diagram is saved.

Using the API call, the appropriate rows in table t_diagramlinks are not deleted as they are when using the GUI.

When the call is made when using an EAP file repository, there is no msgbox to indicate the error, but the resulting behavior in the diagram suggests that the same error is occuring.  For this reason, and the text of the error message, I suspect that the error is in the implementation of the API.

The error occurs in both of the versions I have installed: 7.1.827, and 7.0.817

Any suggestions?

[«Midnight»]

The only thing that comes to mind is to ensure that the index is a 16-bit integer. Since you are using VB6 this is likely the case.

Send in your project - both a sample EA project and your VB6 file if at all possible - to Sparx support. Use the Registered Users support so you can attach the files. Click the Registered Users link at the top of any forum page, then follow the Bug Report link.

I was doing something similar in 817 and did not see the problem. When I think back it is quite possible the only links I deleted were either 'real' connectors, or consequences of removing diagram objects. Neither would be likely to trigger your error.

Please let us know what Sparx has to say.

David

[thomas.kilian]

What about letting the index go downward instead of up? I know it should also work up here but who knows.

[arose]

Thanks for the suggestions.  I plan on sending the VB project to Sparx.  Running the loop from count to 0 makes no difference.  Using datatypes integer and long both cause the same error.

BTW, further investigation reveals that for an EAP file repository, the API deleteat call hides the rows (sets ishidden = true), rather than deleting them.

[«Midnight»]

Here's a long shot...

Are you using Jet 3.51 or Jet 4.0? By "using" I mean the EA setting. If you're not using Jet 4.0 - or if you are not sure - then open the Tools | Options | General dialog and check the appropriate box. You'll have to exit and restart EA before this takes effect, but it will become the default from then on.

Don't worry, this will not damage any of your current work.

If you changed to Jet 4.0, do you still have the problem?

David

[arose]

Yes, the problem is the same using Jet 4.0.  The diagram links are hidden instead of being deleted.  It shows up clearly using a model search query like this (assuming only one diagram).

select b.start_object_id, b.end_object_id, a.*
from t_diagramlinks a
  left join t_connector b
  on a.connectorid = b.connector_id
order by b.start_object_id, b.end_object_id

[«Midnight»]

Actually, this might be working OK.

EA has a habit of automatically adding all links between elements on diagrams. By that I don't mean all defined diagram links, I mean that EA goes and hunts for any connectors between the elements that appear on the diagram, and adds them if they are not already depicted.

My guess - and this is backed up by some experience in handling diagrams on the fly through automation - is that EA is marking the diagram links as (somehow) invisible, which could be done by 'declaring' them to be deleted. Thus, EA has a record of the diagram link for that particular link and diagram, which says "don't show this one." Therefore EA won't show the link, and nor will it 'helpfully' add a new copy when it notices the connector between the elements.

If this is the case - and I suspect it is - then as long as the diagram link disappears from your diagram (and stays that way) then everything is OK.

David

[arose]

Well, there is the rub.  

Deleting elements from a diagram using the user interface actually removes the diagram link rows from t_diagramlinks, whether in an EAP file (using 3.5 or 4.0) or in an MSSQL repository.

Deleting the elements from a diagram using the API requires that one delete the diagramobjects and the diagramlinks using the .deleteat method.  The t_diagramobjects rows are deleted, but the t_diagramlinks rows are not.  Instead they have the "ishidden" column value set to true.

There are side effect of this.  

If one uses the api to delete elements from a diagram, and then runs diagram layout, and then adds the deleted elements back onto the diagram, the corresponding diagramlinks do *not* appear, since they are hidden.

If one then makes them visible using the Diagram->Visible Relations dialog box, one finds that the links retain the original geometry they had when deleted.

So, the main thing for me is that the API doesn't produce behavior that matches the built-in behavior, at least in this case. ...OR I'm not using it correctly.

[«Midnight»]

I suspect you are using it correctly, or at least you are not using it incorrectly.

EAUI or perhaps EAUAPI. Or just inconsistency. But in the last case at least that's consistent.

 :-?  I'm so confused...

[arose]

Hey David,

I appreciate your replies.  If there is one thing that takes more effort than working through tricky issues that one encounters, it is to working through someone else's explanation of *their* issues.

Anyway, I still plan to send the project to Sparx in the near future.

Allan

[«Midnight»]

Thanks Alan,

I absolutely agree; send the project to Sparx by all means. First and foremost, they cannot improve this kind of thing if we don't tell them.

And keep in mind that I could be wrong in my interpretation. That's not meant to imply anything about your description of the problem, which was quite clear. It is simply a reflection on my reasoning.

Whether my interpretation is correct or not, the issue still remains. At the very least it seems a bit fragile the way things are now. At worst the apparent inconsistency between how the API and UI 'remove' a diagram link is bound to come back and bite us somewhere down the line. This appears not so much a problem waiting to happen, as a one that has already occurred, and we're all just waiting to see how bad things get.

Please do post back to tell us what happens with Sparx.

All the best,
David

[arose]

The Sparx team has responded to this bug with the following emails:

-------------------------
The issue is DiagramLink.DeleteAt has invalid SQL for certain DBMS types. This issue has been resolved internally and will be found in the next build of EA.
-------------------------
and:
-------------------------
The tests will be run against all supported EA DBMS.
-------------------------

So this is excellent news!

[«Midnight»]

Absolutely!

Thanks for doing the leg work on the bug report.

David

[arose]

A final note on the DiagramLinks.DeleteAt API call...

The bug was finally fixed in EA 7.1.832.  So as of that build, making this API call actually does delete the specified row in the t_diagramlinks table.

Allan

[«Midnight»]

Thanks for closing this loop Allan,

This was one of those areas that had me worried we'd have to develop some kind of custom workaround.

David