[SOLVED] Key events blocking mouse events?

Scripting Issues
1

Hello
I have a problem with DirectObject. I want to create an objects that tracks the state of some mouse buttons and keyboard keys. State is “pressed” or “not pressed”. So I derived from DirectObject and registered for mouse button 1 (up and down) and right shift key (up and down).

Now what puzzles me is this: If I press down the right shift key and hold it down then I am no longer able to receive “mouse1” events (mouse button 1 down), only “mouse1-up”. The following script demonstrates this effect:

import direct.directbase.DirectStart
from direct.showbase.DirectObject import DirectObject

class Controler( DirectObject ):

    def __init__( self ):
        self.mouse = [ 0, 0, 0 ]
        self.key = [ 0, ]

        self.accept( 'mouse1', self.setMouse, [ 0, 1 ] )
        self.accept( 'mouse1-up', self.setMouse, [ 0, 0 ] )
        self.accept( 'rshift', self.setKey, [ 0, 1 ] )
        self.accept( 'rshift-up', self.setKey, [ 0, 0 ] )

    def setMouse( self, button, value ):
        print '---> mouse ', button, value
        self.mouse[ button ] = value

    def setKey( self, key, value ):
        print '---> key ', key, value
        self.key[ key ] = value

ctrl = Controler( )
run( )

Is this behavior to be expected, a bug, or am I too tired to see the error in my code? I am using Panda3D 1.3.2 Windows distribution, without modifications.

enn0x

2

Hmm… two minutes after posting I found out that if I register for normal keys like “m” or “q” then I don’t get this strange behavior. Only keys like “rshift”, “rcontrol” fail.
enn0x

3

By default, shift, control, and alt are set up as “modifier” buttons. This means that while you are holding down one of these buttons, the event generated in response to other button presses will be prefixed by the modifier button name, e.g. “shift-mouse1” instead of just “mouse1”.

You can disable this behavior if you want, by doing something like:

base.mouseWatcherNode.setModifierButtons(ModifierButtons())

Incidentally, whenever you are surprised that you do not get an event you expect, it’s usually a good idea to turn on message debugging:

messenger.toggleVerbose()

This will show each message that is actually being generated, and would have shown you “shift-mouse1”, making it much easier to see what’s going wrong.

David

4

Thank you very much, this solves my problem.

I still don’t know which way to go, disabling modifier buttons or watching for modified events, but turning on message debugging is something I will do from now on :slight_smile:

enn0x

5

Is this expected to work in Panda 1.2.3?

I have a situation where I use Ctrl+N to pop up a different window and then close it (so panda misses the control-up message). Once this window is close, panda acts as if the control key is still down even when it’s up, until I press it again. This persists despite me forcing the “control-up” message (and the “lcontrol-up”,“time-control-up”, and “time-lcontrol-up” messages) by hand at the right time and despite me replacing the base.mouseWatcherNode’s modifierButtons with an empty one (using the code path recommended in this thread). Despite these things, I keep getting "control-"messages instead of normal ones. If this isn’t supported behavior in Panda 1.2.3, is there something else I can do to just stop paying attention to the ctrl modifier?

Thanks,
Aaron

6

We’ve had variants of this bug from time to time in the past. Are you running in Windows or Linux?

Try:

mods = ModifierButtons(base.buttonThrowers[0].getModifierButtons())
mods.buttonUp(KeyboardButton.control())
base.buttonThrowers[0].setModifierButtons(mods)

to force the button up explicitly.

David

7

Thanks for the reply.

This worked beautifully (once I got the actual node from base.buttonThrowers[0] with .node()). I’m curious, do you know why the retrieval of base.buttonThrowers[0] would work, but doing the same thing to base.mouseWatcherNode failed?

Thanks again, this was a huge help :slight_smile:

Aaron

8

It is the ButtonThrower object that is responsible for sending messages like “control-n” and “n-up” in response to keypresses, and for monitoring the state of the shift, control, and alt keys with respect to those events. The MouseWatcher object, on the other hand, is responsible for monitoring the state of the control key as it influences the trackball or whatever, but not for generating event names.

It was actually my mistake to recommend calling only mouseWatcherNode.setModifierButtons() in the above post; the correct fix is to call it on both the mouse watcher and the button thrower.

David