Hi Leandro,
A drag is just a mouse move with buttons pressed, its not a mouse
button event so generating multiple button events would be
inappropriate. There are seperate mouse button press and release
events for this.
For 1.0 the mouse button support during drag will have been incidental
to the implementation of cloning of events, and probably just so
happened to work in way that was convinient for your application
usage, rather than anything tied down by design.
For 1.1 its difficult to know what to do, as a mouse drag event
doesn't isn't uniquely associated with a mouse button, its only really
appropriate to use the button mask with drag events as this captures
all the buttons that are pressed, using the button value won't ever be
reliable.
The only question is whether we should implement some form of
backwards compatibility to the way that 1.0 was working. I don't
recall what 1.0 did, my guess is that used the button of the last
pressed mouse button. If this is the case then we'd need to cache the
last button pressed in EventQueue.
Robert.
On 7/12/06, Leandro Motta Barros <[EMAIL PROTECTED]> wrote:
On 7/12/06, Robert Osfield <[EMAIL PROTECTED]> wrote:
> Hi Leandro,
>
> On 7/12/06, Leandro Motta Barros <[EMAIL PROTECTED]> wrote:
> > I compiled it cleanly under Linux, and noticed just one problem when
> > using an 'osgGA::GUIEventHandler' and handling DRAG events. When I
> > call 'getButton()', it is not returning any of the mouse button
> > constants ('LEFT_MOUSE_BUTTON' and the like). For other mouse events,
> > this works.
> >
> > Is this a bug or the behavior changed for some reason?
>
> Just looking at the code in src/osgGA/EventQueue.cpp, the method that
> generates the drag event is EventQueue::mouseMotion(float x, float y),
> and it internals checks the accumulated button mask to determin it the
> motion is a drag or a move.
>
> While the code has the correct button mask it won't neccesarily know
> what button should be associatedwith the event. If only one button is
> pressed in the button mask then it'll be obvious, but what if there is
> more than one button pressed?
Humm... I see. I noticed this because we have some code relying on the
button pressed while dragging, and this has broken with OSG 1.1. So,
it seems that OSG 1.0 had some rule to define which button to report.
A can think of the following possible "fixes" for this:
1) If multiple buttons are pressed, generate one "drag" events for
each button pressed. I have barely skimmed through, but this seems to
require larger changes to the event handling code.
2) Define "priorities". For example: if both the left and right
buttons are pressed, report that a drag for the left button (I guess
OSG 1.0 did something like this). This is pretty simple to implement,
and would be good enough for my needs.
If option 2 is OK, I can implement it and submit the patch.
Cheers,
LMB
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
