EA_OnPreNewDiagramObject doesn't like creating new diagram objects

[Ian Mitchell]

I have an addin which is responding to the EA_OnPreNewDiagramObject event.
What I'm trying to do is to intercept this event, and, in some conditions, not create the diagram element which the user has chosen, but add some other diagram objects instead. (all very logical, in context of the addin..honest).
The basic event handling works well: returning 'true' lets EA create the element in the diagram, and 'false' stops it.
So far, so good.
What EA is quite unhappy about is adding the alternate diagram elements to the diagram, in the middle of handling this event, which I guess I should expect, as it might really confuse EA...
Has anyone tried to do this?
I suppose I'd like to somehow remember what alternative objects I'd like to create, finish dealing with the EA event,  then do my own thing afterwards.
But how to get control back into my addin to create the alternative objects?

[Paolo F Cantoni]

I don't have experience handling events, but can you same the diagram during the event?

If so, that might "settle" EA and allow the other objects to be created.

What error do you get returned?

Paolo

[Ian Mitchell]

The behavior is proving hard to pin down.
I can now seem to add new Diagram Objects, but now EA is ignoring the 'false' return to the event, so i get the old element (e.g. of type 'UML::Risk' which I don't want) AND the new one - which is a small improvement.

At the point where I pass the 'false' back to the event call, EA pops up a dialog which says

'Unknown/Illegal base type Risk
'Command: UML::Risk

...and does not delete the 'Risk' element. Same for most other element types.
BUT
If user tries to create an element of e.g. <<User>>Requirement, then it's all fine.
Some quite strange stuff going on here....

@Sparx - perhaps you could comment on what is allowed when responding to this event? What's creating the above error ?

[Geert Bellekens]

Well, UML::Risk doesn't exist, so that explains why he complains about it.
Now why EA thinks it being asked to create this type of element is another question. Might be due to a bug.

Anyway, if you are not able to create new diagramObjects in the event itself, you could remember that fact in your add-in and try to create them in the next event that comes up. That's probably going to be one if the "Context" events (EA_OnContextItemChanged)

Other option might be to start a new thread thread and return control to EA.
Then in the new thread, maybe wait a bit until you can be reasonably sure EA has handled the event, and then add the diagramElements  from this new thread.

Big downside of the latter approach is that it opens up a whole new can of worms. It took me quite a while to get all of the multi-threading related errors out of the EA Naviator 

Geert

[Ian Mitchell]

Hmmm.
I was thinking multi-threading thoughts as well, but as you say @Geert, we know what's in that can.
But I think I'll have a go....
Ok - that seems to work. But i'm not proud of myself. Thanks @Geert

[Geert Bellekens]

Hmmm.
I was thinking multi-threading thoughts as well, but as you say @Geert, we know what's in that can.
But I think I'll have a go....
Ok - that seems to work. But i'm not proud of myself. Thanks @Geert

Cool. If it works, it works doesn't it?

Geert

[Ian Mitchell]

A revision to this issue - my approach did not work. I think that was just a race condition which made it work most of the time, but not always, so I don't recommend this approach.
The only way I finally got this to work was to not allow the thread of control (which started with the EA event) to make any changes to the diagram.
I did this by creating a modeless dialog (the one where the user gets to choose what they want to do), which has the effect of going back to the EA event with a good return value, and with the diagram still intact.
The modeless dialog then starts work again when the user decides to do something, and it's there that I make changes to the diagram - deleting stuff we don't want, and adding stuff we do, using the normal API functions which work fine.
My lesson here is that these EA events are sensitive to changes in the EA 'thing' they are reporting on, which isn't a total surprise, but it might be good if @Sparx added a tiny warning to the API documentation which alerts users to this.
I will now go for a lie down.

[Paolo F Cantoni]

A revision to this issue - my approach did not work. I think that was just a race condition which made it work most of the time, but not always, so I don't recommend this approach.
The only way I finally got this to work was to not allow the thread of control (which started with the EA event) to make any changes to the diagram.
I did this by creating a modeless dialog (the one where the user gets to choose what they want to do), which has the effect of going back to the EA event with a good return value, and with the diagram still intact.
The modeless dialog then starts work again when the user decides to do something, and it's there that I make changes to the diagram - deleting stuff we don't want, and adding stuff we do, using the normal API functions which work fine.
My lesson here is that these EA events are sensitive to changes in the EA 'thing' they are reporting on, which isn't a total surprise, but it might be good if @Sparx added a tiny warning to the API documentation which alerts users to this.
I will now go for a lie-down.

(my emphasis)
I KNOW the feeling!

Happy Friday, Ian!

Paolo