New Diagram Type from Add-In

[dhait]

The SysML addin creates a set of new diagram types in the "New Diagram" dialog box.

How is this accomplished using the Add-In API?
Specifically, what objects/methods are used to add new diagram types to the system?

[«Midnight»]

I'm guessing here, but perhaps the diagram is stereotyped.

Another possibility - which could also work in concert with stereotypes - is that the add-in is intercepting a broadcast event and displaying a custom dialog, then turning off the EA dialog processing. That would give you the additional diagram types regardless of the means by which they were implemented.

David

[dhait]

Meaning no disrespect, but there's got to be a better (i.e., more definite) answer than this!

If you stereotype a "UMLDiagram", it doesn't work.
Neither does "DiagramFrame".

I'm also guessing it's not a custom dialog, because it looks EXACTLY the same as the "Add diagram..." dialog.

No, there must be some hook somewhere that we don't know about .... yet.....

[«Midnight»]

Like I said, it was a guess. The BPMN add-in seems to identify its diagrams via a stereotype, so I took a stab.

Try exporting a package containing a couple of diagrams, one each for SysML and 'simple' UML to XMI - remembering to check the option to include diagrams of course - and inspecting the stream referring to the diagrams. See if you can find an obvious difference.

If you do, that's a spot to work from while we wait for Sparx to handle this. Please do let us know what you discover.

[dhait]

Thanks for the idea.  Interesting results.....

   The SysML Block Diagram is exactly the same as the Class Diagram in the XMI file, except the SysML diagram has the extra TaggedValue "StyleEx" with value "MDGDgm=SysML::BlockDefinition".

  In the API docs, it says that StyleEx is "Not Currently Used". (and that it's an Integer field!)

[«Midnight»]

That's not the only small "oops" in that area of the documentation. As for it not being used, Sparx slowly populates a few of these fields between major releases. This gives them a way of extending functionality without breaking older models.

The last time they actually had to break things was (I believe) around the 3.6 to 4.0 transition. Personally, I think we're coming close to another such mark, but I'd not want to hazard a guess whether it would be as early as 7.0. Who knows.

In the meantime, my suggestions are as follows:

Submit a bug report on the documentation error; Sparx needs to keep this up to date.

You can probably test and set this field to handle your current automation requirement. Testing should be easy, but you might have to set it through a direct database call rather than through the API. OLEDB or whatever will work; just make sure you don't lock the file when you open either channel. Be careful...

HTH, David