Skip to main content

Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » Graphiti » Making parent features available for the child(How to make the parent features work "through" a child shape?)
Making parent features available for the child [message #1069637] Tue, 16 July 2013 09:38 Go to next message
Albert Hofkamp is currently offline Albert HofkampFriend
Messages: 41
Registered: August 2009

I have been pondering about parent and child shapes, and how to make them look as behaving in the same way, preferably in a nice way in the Java code.

Concretely, I have a location with a name. The location is a rounded rectangle labeled with OUTER (it's the outer container shape), and the name is a child shape of the container and has a NAME value in its properties. The name is a Text element.

The location does not contain much other things, so the rectangle is only a little bit bigger than the text.
Feature-wise, both shapes are very different, you can delete the location but not the name. The location has some custom features as well, which also appear as domain-specific context buttons (Great idea by the way!).
The name can be (direct)edited (it's not working right yet, but let's keep that for another day Smile )

Now when you run this editor, when the mouse is at the location, you see the context buttons, and in the menu you get the custom features. The location however is only a few pixels, the majority of the area is covered by the name. When you move the mouse onto it, the context buttons disappear. In other words, the buttons flash on and off while moving around in the location (a user doesn't really consider the name to be different enough to perceive it as natural behavior).

I managed to get the custom features working for the name by adding them for the name as well, ie in the execute method
   public void execute(ICustomContext context) {
       PictogramElement[] elms = context.getPictogramElements();
       if (elms == null || elms.length != 1) return;

       String val = pes.getPropertyValue(elms[0], LOC_ELEMENT);
       if (val == null) return;

       Shape outer = (Shape)elms[0];
       if (val.equals(NAME)) {
           outer = outer.getContainer();
       } else if (!val.equals(OUTER)) {

       .... // Use outer as the shape to work on.
I ask what shape I have, and if I get the NAME shape, I get its parent (which is OUTER).
To the user, it looks like the entire location has this custom feature.

For the context buttons however this trick fails. See the comments with a XXX.
    public IContextButtonPadData getContextButtonPad(IPictogramElementContext context)
        IContextButtonPadData data = super.getContextButtonPad(context);
        if (data == null) return null;

        PictogramElement pe = context.getPictogramElement();
        String val = pes.getPropertyValue(pe, LOC_ELEMENT);
        if (val == null || !val.equals(OUTER)) return data;

        // XXX Here I can do the shape trick like above, to make "pe" always point to the OUTER shape.

        setGenericContextButtons(data, pe,
                                 CONTEXT_BUTTON_DELETE | CONTEXT_BUTTON_UPDATE);

        // Initial state toggle context button.
        CustomContext cc;
        cc = new CustomContext(new PictogramElement[] {pe});
        IContextButtonEntry initialCbe = null;
        IContextButtonEntry markedCbe = null;
        ICustomFeature[] cfs = getFeatureProvider().getCustomFeatures(cc);
        for (int i = 0; i < cfs.length; i++) {
            ICustomFeature cf = cfs[i];
            if (cf instanceof LocationInitialToggleFeature) {
                initialCbe = new ContextButtonEntry(cf, cc);
            if (cf instanceof LocationMarkerToggleFeature) {
                markedCbe = new ContextButtonEntry(cf, cc);

        // XXX But here the custom features get added to the original context through 'data'.
        // XXX If that context is a NAME, it has no chopbox anchor, so the engine cannot
        // XXX draw the context buttons at the right place.

        List<IContextButtonEntry> cbs = data.getDomainSpecificContextButtons();
        if (initialCbe != null) cbs.add(initialCbe);
        if (markedCbe != null) cbs.add(markedCbe);

        return data;
It was a nice experiment, but I can see why it fails.

This naturally leads to the question of how to achieve that context buttons do not flash on and off just by moving the mouse around at what users perceive as one location.

Reflecting on this question, one possible direction would be if I can say "for this feature, skip NAME, but go to the parent OUTER instead".
It would also make the somewhat hacky shape fix unnecessary. No idea whether you can do this.

Another direction may be that my shapes are wrong. Perhaps I should not want to have a NAME covering most of OUTER. On the other hand, even with a small name, when moving the mouse to a context button from a sufficiently big location, but passing the small name during the move, the context button suddenly disappears. I have even had the case where the context buttons were not reachable because I had put the name at the very top of the parent container.

Re: Making parent features available for the child [message #1070201 is a reply to message #1069637] Wed, 17 July 2013 12:45 Go to previous messageGo to next message
Michael Wenz is currently offline Michael WenzFriend
Messages: 1927
Registered: July 2009
Location: Walldorf, Germany
Senior Member

usually, for texts you could also use an inactive shape instead of an active

But in general you are right, there should be some kind of mechanism for the
context button pad to switch the base GA. We have such mechanisms already in
place for e.g. selection, but it seems to be lacking for the context button
pad. I think we should add an appropriate hook method to the tool behavior
provider as there are methods e.g. to influence selection.

Would you file an extension bug for this?

Regards and thanks,
Re: Making parent features available for the child [message #1071155 is a reply to message #1070201] Fri, 19 July 2013 13:04 Go to previous messageGo to next message
Robert Brodt is currently offline Robert BrodtFriend
Messages: 811
Registered: August 2010
Location: Colorado Springs, CO
Senior Member

Hi Albert,

I'm having a similar issue and also have a need for a hook method that provides an alternate selection (similar to the Tool Behavior Provider's getSelection() method). Have you already filed a bug report for this?

Re: Making parent features available for the child [message #1084962 is a reply to message #1071155] Mon, 12 August 2013 09:06 Go to previous message
Albert Hofkamp is currently offline Albert HofkampFriend
Messages: 41
Registered: August 2009
Filed an enhancement request:
Previous Topic:Use one create feature for different elements
Next Topic:Display additional information only in Editor
Goto Forum:

Current Time: Wed Aug 04 08:33:08 GMT 2021

Powered by FUDForum. Page generated in 0.02303 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top