Duplicate command drop-down when dropping nestable widget from palette [message #699862] |
Fri, 22 July 2011 09:55  |
Eclipse User |
|
|
|
Hi,
I have an ECore model with a type that may contain another object of it's own type. I got my gmfmap set up such that these elements can be nested to arbitrary depth on the canvas. The pop-up balloon let's me nest the elements to a depth of 2.
Following that I can pick and drop the element from the palette. Here is where it gets tricky, as the palette tool presents two identical options when you drop. One of them will work for nested elements. The other one works only when dropping on the canvas itself. If I pick the right one, I can nest the elements to any depth. (First option is for dropping on canvas, second is for nesting.) I'm trying to get these options to show up only in the right context, or to at least be distinct in UI. Any suggestions for where to look or what I can override?
In case it helps, the model and 2.2 mappings are here:
github.com/UNC-Libraries/Curators-Workbench/tree/master/crosswalk-gmf/model
An aside:
This model represents metadata mappings to XML elements and is used in the Curator's Workbench software here:
github.com/UNC-Libraries/Curators-Workbench
Any suggestions on this driving problem are definitely welcome. The GMF stack has been terrific for this. The intent is to enable visual programming that maps metadata migration to an XML schema.
many thanks,
Greg
|
|
|
|
|
|
|
|
Re: Duplicate command drop-down when dropping nestable widget from palette [message #876373 is a reply to message #699862] |
Thu, 24 May 2012 09:27  |
Eclipse User |
|
|
|
It is several months later, but I wanted to post the real reason for this issue, which I recently discovered. The problem was with unusual prompts when dropping elements from the palette onto the canvas.
I was thrown off the trail here because the problem only presented in a particular element that was nestable. Hence I thought that the creation policy was having trouble resolving the "create unspecified type request" into the right notational model, instead prompting the user.
Well, the real reason that the standard creation edit policy could not resolve the unspecified type creation request was that I had EditHelperAdvice involved. My advice on this element was returning a before and after creation command for the element in question. It was returning a command in a way that did not distinguish between the two notational models available. In other words, it returned advice even when the real "type specified" edit command was unexecutable or non-existent. This seems to have confused the edit policy enough to make it prompt the user to make the choice.
My fix was to make the creation advice sensitive to the container on offer and only return a non-null advice command result when the request is specific to the given context.
I think this is something that might be added to the edit helper advice docs. It was hard for me to make the connection between advice I thought would be discarded and the impact this had on the resolution of the creation request.
thanks,
Greg
|
|
|
Powered by
FUDForum. Page generated in 0.09009 seconds