Home » Eclipse Projects » Standard Widget Toolkit (SWT) » Shell Control Drag-Move
| Shell Control Drag-Move [message #450734] |
Thu, 17 February 2005 08:43  |
 Terry Corbet
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Because my application's Shell has special style [trim] requirements, I
have had to implement my own method for letting the user drag the window
to a new location on the Display. With the help of many of the
suggestions and samples available I almost have the desired behavior.
There is, however, one difference between my implementation and the
behavior on a Windows platform. On Windows, if you place the pointer in
the Title and press the left mouse button there is a perceptible delay
before the outline of the window appears. Thus, if the user should press
the left mouse button in the Title, but then not perform a dragging
gesture, the result would be a 'non-event'. [On SuSE with KDE, by the
way, there is no such delay -- as soon as you press the mouse, the outline
appears.]
While this is certainly not a life-threatening problem, I would really
like to know whether or not anyone has simulated the Windows behavior by
introducing some delay between the handling of the Mouse Down and the
Mouse Move events. Since there is some non-trivial set-up and tear-down
for handling the window re-location operation, it is, I think, worthwhile
to be able to recognize a 'non-event' if the buttom press turns out not be
be tied to a dragging of the window.
My guess is that there is some sort of 'time-state' machine in the native
Windows implementation. Clearly the low-level event handler takes on some
responsibility for distinguishing between a 'click' and a 'double-click'
and the difference is, I think, merely a question of the delay interval.
But if Mouse Down is never reported to my listener until the
'double-click-time-interval' has been passed, I would think that would be
about the right amount of time for my processing logic. Thus, if it
worked that way, I would know when receiving the Mouse Down event that a
finite delay has already occurred, so doing the set-up is worthwhile. If,
however, the low-level event handler inserts no delay, is it my
resonsibility to sense and handle a 'non-event' in case the user does not
begin dragging the window after a Mouse Down?
|
|
|
| Re: Shell Control Drag-Move [message #450851 is a reply to message #450734] |
Fri, 18 February 2005 15:26  |
Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
Ok, without code, it's hard to know whether you are talking about a delay in
the native mouse down and dragging behavior on Windows (ie. when you click
on the title of a shell) or your implementation of dragging. If you had a
small stand alone example that showed the difference, we could determine
whether this is a bug/feature or just platform behavior.
"Terry Corbet" <tcorbet@ix.netcom.com> wrote in message
news:cv1lg7$2u8$1@www.eclipse.org...
> Because my application's Shell has special style [trim] requirements, I
> have had to implement my own method for letting the user drag the window
> to a new location on the Display. With the help of many of the
> suggestions and samples available I almost have the desired behavior.
>
> There is, however, one difference between my implementation and the
> behavior on a Windows platform. On Windows, if you place the pointer in
> the Title and press the left mouse button there is a perceptible delay
> before the outline of the window appears. Thus, if the user should press
> the left mouse button in the Title, but then not perform a dragging
> gesture, the result would be a 'non-event'. [On SuSE with KDE, by the
> way, there is no such delay -- as soon as you press the mouse, the outline
> appears.]
>
> While this is certainly not a life-threatening problem, I would really
> like to know whether or not anyone has simulated the Windows behavior by
> introducing some delay between the handling of the Mouse Down and the
> Mouse Move events. Since there is some non-trivial set-up and tear-down
> for handling the window re-location operation, it is, I think, worthwhile
> to be able to recognize a 'non-event' if the buttom press turns out not be
> be tied to a dragging of the window.
>
> My guess is that there is some sort of 'time-state' machine in the native
> Windows implementation. Clearly the low-level event handler takes on some
> responsibility for distinguishing between a 'click' and a 'double-click'
> and the difference is, I think, merely a question of the delay interval.
> But if Mouse Down is never reported to my listener until the
> 'double-click-time-interval' has been passed, I would think that would be
> about the right amount of time for my processing logic. Thus, if it
> worked that way, I would know when receiving the Mouse Down event that a
> finite delay has already occurred, so doing the set-up is worthwhile. If,
> however, the low-level event handler inserts no delay, is it my
> resonsibility to sense and handle a 'non-event' in case the user does not
> begin dragging the window after a Mouse Down?
>
|
|
|
| Re: Shell Control Drag-Move [message #450865 is a reply to message #450851] |
Fri, 18 February 2005 18:22 |
Terry Corbet
Messages: 14
Registered: July 2009 |
Junior Member |
|
|
Thank you for the reply. I was about 20 minutes into an explanation of
my problem with annotations to snippets of the relevant code when I
discovered the answer to my own question. The bottom line is that I
need to 'avoid the overhead of attempting a shell move' if, in fact, no
movement is required. My mistake was that I performed the 'set up' for
the move in the mouseDown callback instead of putting it in the
mouseMovement callback inside a 'first Time' condition. That way if
the user depresses the button in the widget that is acting like the standard
title bar in my application, but then just does a release without having
introduced any motion, the 'outline for movement' will never appear.
The behavior of the 'low-level' event handler in discriminating between
single-click and double-click based on an elapsed interval cannot be
responsible for what I see in a native Windows application and my
simulation with the SWT widgets.
It seems like I ought to make a public apology for wasting the forum's time
with a question that I could have answered with more code review and
testing, but instead of that apology, I just want to add -- for public
view --
my thanks for the availability of the service. Another set of eyes looking
at
code is always good; sometimes just another set of neurons and synapses
asking 'what and why' is just as good. So thanks again for the reply and
questions.
"Steve Northover" <steve_northover@ca.ibm.com> wrote in message
news:cv51n9$al8$1@www.eclipse.org...
> Ok, without code, it's hard to know whether you are talking about a delay
in
> the native mouse down and dragging behavior on Windows (ie. when you click
> on the title of a shell) or your implementation of dragging. If you had a
> small stand alone example that showed the difference, we could determine
> whether this is a bug/feature or just platform behavior.
>
> "Terry Corbet" <tcorbet@ix.netcom.com> wrote in message
> news:cv1lg7$2u8$1@www.eclipse.org...
> > Because my application's Shell has special style [trim] requirements, I
> > have had to implement my own method for letting the user drag the window
> > to a new location on the Display. With the help of many of the
> > suggestions and samples available I almost have the desired behavior.
> >
> > There is, however, one difference between my implementation and the
> > behavior on a Windows platform. On Windows, if you place the pointer in
> > the Title and press the left mouse button there is a perceptible delay
> > before the outline of the window appears. Thus, if the user should
press
> > the left mouse button in the Title, but then not perform a dragging
> > gesture, the result would be a 'non-event'. [On SuSE with KDE, by the
> > way, there is no such delay -- as soon as you press the mouse, the
outline
> > appears.]
> >
> > While this is certainly not a life-threatening problem, I would really
> > like to know whether or not anyone has simulated the Windows behavior by
> > introducing some delay between the handling of the Mouse Down and the
> > Mouse Move events. Since there is some non-trivial set-up and tear-down
> > for handling the window re-location operation, it is, I think,
worthwhile
> > to be able to recognize a 'non-event' if the buttom press turns out not
be
> > be tied to a dragging of the window.
> >
> > My guess is that there is some sort of 'time-state' machine in the
native
> > Windows implementation. Clearly the low-level event handler takes on
some
> > responsibility for distinguishing between a 'click' and a 'double-click'
> > and the difference is, I think, merely a question of the delay interval.
> > But if Mouse Down is never reported to my listener until the
> > 'double-click-time-interval' has been passed, I would think that would
be
> > about the right amount of time for my processing logic. Thus, if it
> > worked that way, I would know when receiving the Mouse Down event that a
> > finite delay has already occurred, so doing the set-up is worthwhile.
If,
> > however, the low-level event handler inserts no delay, is it my
> > resonsibility to sense and handle a 'non-event' in case the user does
not
> > begin dragging the window after a Mouse Down?
> >
>
>
|
|
|
| Re: Shell Control Drag-Move [message #451019 is a reply to message #450865] |
Mon, 21 February 2005 17:00 |
Steve Northover
Messages: 1636
Registered: July 2009 |
Senior Member |
|
|
Don't worry about it. The power of the snippet strikes again.
"Terry Corbet" <tcorbet@ix.netcom.com> wrote in message
news:cv5bp2$slo$1@www.eclipse.org...
> Thank you for the reply. I was about 20 minutes into an explanation of
> my problem with annotations to snippets of the relevant code when I
> discovered the answer to my own question. The bottom line is that I
> need to 'avoid the overhead of attempting a shell move' if, in fact, no
> movement is required. My mistake was that I performed the 'set up' for
> the move in the mouseDown callback instead of putting it in the
> mouseMovement callback inside a 'first Time' condition. That way if
> the user depresses the button in the widget that is acting like the
standard
> title bar in my application, but then just does a release without having
> introduced any motion, the 'outline for movement' will never appear.
> The behavior of the 'low-level' event handler in discriminating between
> single-click and double-click based on an elapsed interval cannot be
> responsible for what I see in a native Windows application and my
> simulation with the SWT widgets.
>
> It seems like I ought to make a public apology for wasting the forum's
time
> with a question that I could have answered with more code review and
> testing, but instead of that apology, I just want to add -- for public
> view --
> my thanks for the availability of the service. Another set of eyes
looking
> at
> code is always good; sometimes just another set of neurons and synapses
> asking 'what and why' is just as good. So thanks again for the reply and
> questions.
>
> "Steve Northover" <steve_northover@ca.ibm.com> wrote in message
> news:cv51n9$al8$1@www.eclipse.org...
> > Ok, without code, it's hard to know whether you are talking about a
delay
> in
> > the native mouse down and dragging behavior on Windows (ie. when you
click
> > on the title of a shell) or your implementation of dragging. If you had
a
> > small stand alone example that showed the difference, we could determine
> > whether this is a bug/feature or just platform behavior.
> >
> > "Terry Corbet" <tcorbet@ix.netcom.com> wrote in message
> > news:cv1lg7$2u8$1@www.eclipse.org...
> > > Because my application's Shell has special style [trim] requirements,
I
> > > have had to implement my own method for letting the user drag the
window
> > > to a new location on the Display. With the help of many of the
> > > suggestions and samples available I almost have the desired behavior.
> > >
> > > There is, however, one difference between my implementation and the
> > > behavior on a Windows platform. On Windows, if you place the pointer
in
> > > the Title and press the left mouse button there is a perceptible delay
> > > before the outline of the window appears. Thus, if the user should
> press
> > > the left mouse button in the Title, but then not perform a dragging
> > > gesture, the result would be a 'non-event'. [On SuSE with KDE, by the
> > > way, there is no such delay -- as soon as you press the mouse, the
> outline
> > > appears.]
> > >
> > > While this is certainly not a life-threatening problem, I would really
> > > like to know whether or not anyone has simulated the Windows behavior
by
> > > introducing some delay between the handling of the Mouse Down and the
> > > Mouse Move events. Since there is some non-trivial set-up and
tear-down
> > > for handling the window re-location operation, it is, I think,
> worthwhile
> > > to be able to recognize a 'non-event' if the buttom press turns out
not
> be
> > > be tied to a dragging of the window.
> > >
> > > My guess is that there is some sort of 'time-state' machine in the
> native
> > > Windows implementation. Clearly the low-level event handler takes on
> some
> > > responsibility for distinguishing between a 'click' and a
'double-click'
> > > and the difference is, I think, merely a question of the delay
interval.
> > > But if Mouse Down is never reported to my listener until the
> > > 'double-click-time-interval' has been passed, I would think that would
> be
> > > about the right amount of time for my processing logic. Thus, if it
> > > worked that way, I would know when receiving the Mouse Down event that
a
> > > finite delay has already occurred, so doing the set-up is worthwhile.
> If,
> > > however, the low-level event handler inserts no delay, is it my
> > > resonsibility to sense and handle a 'non-event' in case the user does
> not
> > > begin dragging the window after a Mouse Down?
> > >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Thu Apr 25 21:50:10 GMT 2024
Powered by FUDForum. Page generated in 0.03308 seconds |
] 
Search
Help
Register
Login
Home
