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 |
Albert Hofkamp Messages: 41 Registered: August 2009 |
Member |
|
|
Hello,
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 )
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
@Override
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)) {
return;
}
.... // 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.
@Override
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);
continue;
}
if (cf instanceof LocationMarkerToggleFeature) {
markedCbe = new ContextButtonEntry(cf, cc);
continue;
}
}
// 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.
|
|
| | | |
Goto Forum:
Current Time: Wed Sep 25 17:18:27 GMT 2024
Powered by FUDForum. Page generated in 0.04026 seconds
|