Repository.WriteSelectableOutput()

[Uffe]

Hello,


Repository.WriteOutput() takes an ID which EA passes to Add-Ins in EA_OnOutputItem[Double]Clicked().

In an AddIn-less situation, it would be useful to be able to write output which links to an element or diagram, but which is handled by the EA client. This would simply need to call Repository.ShowInProjectView() (and quash any exception thrown). Possibly the text itself should be underlined, signalling that it allows interaction.

Repository.WriteSelectableOutput(string Name, string Output, object Item)
    Writes text to a specified tab in the System Output window, and associates the text with an item which can be selected in the project browser.
    Accepted object types are Package, Element, Diagram, Attribute, and Method.
    Parameters:

• Name: String - specifies the tab on which to display the text
• Output: String - specifies the text to display
• Item: Object - the object to highlight

There. I've even written the documentation for you.


/Uffe

[Geert Bellekens]

+1

Geert

[Paolo F Cantoni]

+1

Geert

Wot they sed...

Paolo

[Eve]

In an AddIn-less situation, it would be useful to be able to write output which links to an element or diagram, but which is handled by the EA client.

The reason why that isn't done already is because there's no way for EA to know what type of thing is referenced.

On the other hand, you can trivially write a modeled add-in that implements those functions.

[Uffe]

In an AddIn-less situation, it would be useful to be able to write output which links to an element or diagram, but which is handled by the EA client.

The reason why that isn't done already is because there's no way for EA to know what type of thing is referenced.

This doesn't quite make sense. If EA can resolve the object type in Repository.ShowInProjectView(), why not here?
But whatever, make it a GUID instead of an Object, and try the five types of object listed. Solved.

On the other hand, you can trivially write a modeled add-in that implements those functions.

Nothing is "trivial" with the documentation in the state it's in, but more to the point, model Add-Ins are counter-indicated in multi-project setups. Having the client handle context-tagged output from a script would work regardless of deployment model.

/U