trigger on drop of pattern on diagram ?

[Danny F]

How does an add-in gets triggered when a pattern is dropped on a diagram ?

When I drop for example a GOF Pattern on a diagram I don't get an EA_On..... event called.
NONE ?

thanks in advance (again   )

[qwerty]

I just guess, you found a bug - to be reported.

q.

[KP]

I would say it's correct behaviour. Patterns are XMI, and we can't have broadcasts being triggered in the middle of an XMI import, they need to be atomic (as much as possible).

[qwerty]

Hmmm. Isn't the drop itself atomic? I mean if you drop an element, this is not an atom. You are mixing up things here.

q.

[KP]

All I'm saying is that if a pattern creates 4 new elements, you shouldn't expect to trigger 4 EA_OnPostNewElement broadcasts (nor EA_OnPostNewDiagramObject, EA_OnPreNewElement, EA_OnPreNewDiagramObject). You don't get it for XMI imports, so shouldn't get it for pattern imports either. Maybe there is a need for an EA_OnPreDropPattern and EA_OnPostDropPattern?

[qwerty]

Or you mimic the On*Element to represent a pattern as a special kind of element.

To me it would it would feel natural if any drop onto a diagram would trigger a On*DiagramElement. Be it a single or multiple elements, a picture, some text from the pasteboard (can you do that to create a text element?) or a pattern which will also create a number of new elements (for each of which an On*NewElement should be triggered - so YES, I expect that for orthogonality sake). I hope you don't argue with performance since we're talking about a handful of events here.

Just my point of view.

q.

[Eve]

First, my belief is that a user doesn't need to know that a pattern is special necessarily, let alone that it's xmi. Therefore I would expect some notifications to be sent. I imagine doing broadcasts of all post new elements, add to diagram and modify (for merged elements) after the internal process is finished. However, I wouldn't want to broadcast "pre" events because of the negative impact that could cause if an add-in wanted to block something.

Slightly contradictory point of view, and I'm not sure if it's feasible from our end but it sounds like the best solution to me (at the moment).

[qwerty]

First, my belief is that a [highlight]user[/highlight] doesn't need to know that a pattern is special necessarily...

Just one final note: it's not really a user receiving the broadcast but a programmer (or the program written by a programmer). Whilst users expect a silent behavior the program they are using, programmers expect a chatty behavior - the more, the better.

q.