Home » Eclipse Projects » GEF » How to properly handle drag / move targeting
| How to properly handle drag / move targeting [message #176987] |
Tue, 12 April 2005 17:58  |
Eclipse User |
|
|
|
Originally posted by: Craig.OfficeExtend.com
I am building a screen design application using GEF. I have a design
surface that parents "screen" objects which then parent various kinds of
widgets (labels, edit boxes, etc.). The widget parts obey the normal GEF
semantics when dragging; e.g., within a parent is a "move" while to a new
parent is "orphan / add", etc. The screens, however, may only be parented
by the background "design" parent.
I would like to cause all drag requests on a screen to become "moves" on
their parent "design" part even when the usual target edit part would
normally be another screen or widget. What's the best way to accomplish
this? Edit policy? Custom drag tracker?
In case this is less than clear, I'll restate. When I drag a screen around
currently the cursor changes from normal to "disallow" depending upon the
target of the drag. I would like to redefine this operation so that any
drag of a screen part will return a target of the overall "design", not any
particular widget the mouse cursor happens to be over. I assume this will
cause all drags of a screen object to become "moves".
|
|
|
| Re: How to properly handle drag / move targeting [message #177042 is a reply to message #176987] |
Tue, 12 April 2005 18:35  |
| Eclipse User |
|
|
|
Originally posted by: christian.sell.netcologne.de
that sounds like the same issue I raised in my question titled "prevent
child figures from capturing mouse" lately. I tried policies and custom
drag tracker, with no success yet.
I'll keep an eye on this topic.
Craig Fransen wrote:
> I am building a screen design application using GEF. I have a design
> surface that parents "screen" objects which then parent various kinds of
> widgets (labels, edit boxes, etc.). The widget parts obey the normal GEF
> semantics when dragging; e.g., within a parent is a "move" while to a new
> parent is "orphan / add", etc. The screens, however, may only be parented
> by the background "design" parent.
>
> I would like to cause all drag requests on a screen to become "moves" on
> their parent "design" part even when the usual target edit part would
> normally be another screen or widget. What's the best way to accomplish
> this? Edit policy? Custom drag tracker?
>
> In case this is less than clear, I'll restate. When I drag a screen around
> currently the cursor changes from normal to "disallow" depending upon the
> target of the drag. I would like to redefine this operation so that any
> drag of a screen part will return a target of the overall "design", not any
> particular widget the mouse cursor happens to be over. I assume this will
> cause all drags of a screen object to become "moves".
>
>
>
>
|
|
|
| Re: How to properly handle drag / move targeting [message #177059 is a reply to message #176987] |
Tue, 12 April 2005 19:15 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Your non-diagram containers should not identify themselves as targets when
the diagram children are being dragged around. See getTargetEditPart() in
your container editpolicies. If the request is moving around one of the
top-level children, return NULL as the target. The result is that GEF will
keep hit testing deeper until the diagram editpart is hit and that will be
the target. Since the target is the current parent, the tacker will use a
move request.
"Craig Fransen" <Craig@OfficeExtend.com> wrote in message
news:d3h2ka$52j$1@news.eclipse.org...
>I am building a screen design application using GEF. I have a design
> surface that parents "screen" objects which then parent various kinds of
> widgets (labels, edit boxes, etc.). The widget parts obey the normal GEF
> semantics when dragging; e.g., within a parent is a "move" while to a new
> parent is "orphan / add", etc. The screens, however, may only be parented
> by the background "design" parent.
>
> I would like to cause all drag requests on a screen to become "moves" on
> their parent "design" part even when the usual target edit part would
> normally be another screen or widget. What's the best way to accomplish
> this? Edit policy? Custom drag tracker?
>
> In case this is less than clear, I'll restate. When I drag a screen
> around
> currently the cursor changes from normal to "disallow" depending upon the
> target of the drag. I would like to redefine this operation so that any
> drag of a screen part will return a target of the overall "design", not
> any
> particular widget the mouse cursor happens to be over. I assume this will
> cause all drags of a screen object to become "moves".
>
>
>
>
|
|
|
| Re: How to properly handle drag / move targeting [message #177172 is a reply to message #177059] |
Tue, 12 April 2005 21:11 |
| Eclipse User |
|
|
|
Originally posted by: Craig.OfficeExtend.com
Ok, newbie alert, but as I watch my getTargetEdit requests coming in on the
edit policies during this process, I don't see a way to identify the
"request is moving around one of the top level children". I see
getTargetEditPart for "selection" requests.
What does a request look like where children are being drug around (hmm,
that sounds bad!)?
"Randy Hudson" <none@us.ibm.com> wrote in message
news:d3h743$c57$1@news.eclipse.org...
> Your non-diagram containers should not identify themselves as targets when
> the diagram children are being dragged around. See getTargetEditPart() in
> your container editpolicies. If the request is moving around one of the
> top-level children, return NULL as the target. The result is that GEF
will
> keep hit testing deeper until the diagram editpart is hit and that will be
> the target. Since the target is the current parent, the tacker will use a
> move request.
>
> "Craig Fransen" <Craig@OfficeExtend.com> wrote in message
> news:d3h2ka$52j$1@news.eclipse.org...
> >I am building a screen design application using GEF. I have a design
> > surface that parents "screen" objects which then parent various kinds of
> > widgets (labels, edit boxes, etc.). The widget parts obey the normal
GEF
> > semantics when dragging; e.g., within a parent is a "move" while to a
new
> > parent is "orphan / add", etc. The screens, however, may only be
parented
> > by the background "design" parent.
> >
> > I would like to cause all drag requests on a screen to become "moves" on
> > their parent "design" part even when the usual target edit part would
> > normally be another screen or widget. What's the best way to accomplish
> > this? Edit policy? Custom drag tracker?
> >
> > In case this is less than clear, I'll restate. When I drag a screen
> > around
> > currently the cursor changes from normal to "disallow" depending upon
the
> > target of the drag. I would like to redefine this operation so that any
> > drag of a screen part will return a target of the overall "design", not
> > any
> > particular widget the mouse cursor happens to be over. I assume this
will
> > cause all drags of a screen object to become "moves".
> >
> >
> >
> >
>
>
|
|
|
| Re: How to properly handle drag / move targeting [message #177180 is a reply to message #177172] |
Tue, 12 April 2005 22:26 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
You want to ignore selection requests. Those happen all the time for things
like popups or selection feedback.
Filter using Request.getType(). The types are defined in RequestConstants.
"Craig Fransen" <Craig@OfficeExtend.com> wrote in message
news:d3hduk$ltg$1@news.eclipse.org...
> Ok, newbie alert, but as I watch my getTargetEdit requests coming in on
> the
> edit policies during this process, I don't see a way to identify the
> "request is moving around one of the top level children". I see
> getTargetEditPart for "selection" requests.
>
> What does a request look like where children are being drug around (hmm,
> that sounds bad!)?
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:d3h743$c57$1@news.eclipse.org...
>> Your non-diagram containers should not identify themselves as targets
>> when
>> the diagram children are being dragged around. See getTargetEditPart()
>> in
>> your container editpolicies. If the request is moving around one of the
>> top-level children, return NULL as the target. The result is that GEF
> will
>> keep hit testing deeper until the diagram editpart is hit and that will
>> be
>> the target. Since the target is the current parent, the tacker will use
>> a
>> move request.
>>
>> "Craig Fransen" <Craig@OfficeExtend.com> wrote in message
>> news:d3h2ka$52j$1@news.eclipse.org...
>> >I am building a screen design application using GEF. I have a design
>> > surface that parents "screen" objects which then parent various kinds
>> > of
>> > widgets (labels, edit boxes, etc.). The widget parts obey the normal
> GEF
>> > semantics when dragging; e.g., within a parent is a "move" while to a
> new
>> > parent is "orphan / add", etc. The screens, however, may only be
> parented
>> > by the background "design" parent.
>> >
>> > I would like to cause all drag requests on a screen to become "moves"
>> > on
>> > their parent "design" part even when the usual target edit part would
>> > normally be another screen or widget. What's the best way to
>> > accomplish
>> > this? Edit policy? Custom drag tracker?
>> >
>> > In case this is less than clear, I'll restate. When I drag a screen
>> > around
>> > currently the cursor changes from normal to "disallow" depending upon
> the
>> > target of the drag. I would like to redefine this operation so that
>> > any
>> > drag of a screen part will return a target of the overall "design", not
>> > any
>> > particular widget the mouse cursor happens to be over. I assume this
> will
>> > cause all drags of a screen object to become "moves".
>> >
>> >
>> >
>> >
>>
>>
>
>
|
|
|
| Re: How to properly handle drag / move targeting [message #177195 is a reply to message #177180] |
Tue, 12 April 2005 23:00 |
| Eclipse User |
|
|
|
Originally posted by: Craig.OfficeExtend.com
I can ignore those, but I traced out the requests to the console and find in
the case where I drag the child on top of another child I get a slew of
selection requests with "last button pressed = 0" followed by a selection
request with last button = 1, which is then immediately followed by an "add
child" request. Conversely, if I drag the part over the background I get
the slew of button=0 selection requests, a button=1 selection request,
followed immediately by a "move".
It looks to me like somebody has already made the decision about whether
this is an "add child" scenario or a "move" scenario before asking me about
my getTargetEditParts.
"Randy Hudson" <none@us.ibm.com> wrote in message
news:d3hiaf$r84$1@news.eclipse.org...
> You want to ignore selection requests. Those happen all the time for
things
> like popups or selection feedback.
> Filter using Request.getType(). The types are defined in
RequestConstants.
>
>
> "Craig Fransen" <Craig@OfficeExtend.com> wrote in message
> news:d3hduk$ltg$1@news.eclipse.org...
> > Ok, newbie alert, but as I watch my getTargetEdit requests coming in on
> > the
> > edit policies during this process, I don't see a way to identify the
> > "request is moving around one of the top level children". I see
> > getTargetEditPart for "selection" requests.
> >
> > What does a request look like where children are being drug around (hmm,
> > that sounds bad!)?
> >
> > "Randy Hudson" <none@us.ibm.com> wrote in message
> > news:d3h743$c57$1@news.eclipse.org...
> >> Your non-diagram containers should not identify themselves as targets
> >> when
> >> the diagram children are being dragged around. See getTargetEditPart()
> >> in
> >> your container editpolicies. If the request is moving around one of
the
> >> top-level children, return NULL as the target. The result is that GEF
> > will
> >> keep hit testing deeper until the diagram editpart is hit and that will
> >> be
> >> the target. Since the target is the current parent, the tacker will
use
> >> a
> >> move request.
> >>
> >> "Craig Fransen" <Craig@OfficeExtend.com> wrote in message
> >> news:d3h2ka$52j$1@news.eclipse.org...
> >> >I am building a screen design application using GEF. I have a design
> >> > surface that parents "screen" objects which then parent various kinds
> >> > of
> >> > widgets (labels, edit boxes, etc.). The widget parts obey the normal
> > GEF
> >> > semantics when dragging; e.g., within a parent is a "move" while to a
> > new
> >> > parent is "orphan / add", etc. The screens, however, may only be
> > parented
> >> > by the background "design" parent.
> >> >
> >> > I would like to cause all drag requests on a screen to become "moves"
> >> > on
> >> > their parent "design" part even when the usual target edit part would
> >> > normally be another screen or widget. What's the best way to
> >> > accomplish
> >> > this? Edit policy? Custom drag tracker?
> >> >
> >> > In case this is less than clear, I'll restate. When I drag a screen
> >> > around
> >> > currently the cursor changes from normal to "disallow" depending upon
> > the
> >> > target of the drag. I would like to redefine this operation so that
> >> > any
> >> > drag of a screen part will return a target of the overall "design",
not
> >> > any
> >> > particular widget the mouse cursor happens to be over. I assume this
> > will
> >> > cause all drags of a screen object to become "moves".
> >> >
> >> >
> >> >
> >> >
> >>
> >>
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 11:23:48 GMT 2024
Powered by FUDForum. Page generated in 0.03562 seconds |
] 
Search
Help
Register
Login
Home
