keyReleased keyPressed problem

Hi people,

so, I am experiencing a strange beviour with the com.jogamp.newt.event.MouseListener

Under some special condition, very hard to explain, I do not get the right event triggering

For example, I want the combination ctrl+o to open the explorer. Most of the time I get this:

keyPressed 17
keyPressed 79

17 is ctrl, 79 o. The println is just at the begin of the corresponding method. I am using a jFrame, that contains a jPanel where I have attached the newtCanvasAwt from my glWindow. I created a class that implement both the key and mouse listener from the com.jogamp.newt.event and I added both to the glWindows throught the corresponding methods addMouse/KeyListener()

Everything fine. But sometimes I get instead this

keyPressed 17
keyReleased 79
keyReleased 17
keyReleased 79

I found this
http://forum.jogamp.org/keyreleased-might-be-have-a-bug-td4027319.html

but it has nothing to do with my case, I also btw experienced keyReleased/KeyPressed if keeping pressed the same button. I inserted a check on the isAutoUpdate() but nothing changed.

Any idea?


Edit: I noticed another thing, when this problem occurs is because previously I didnt get all the keyReleased that I should have obtained

for example

keyPressed 17
List of pressed inputs
ctrl
keyPressed 79
List of pressed inputs
ctrl
o
keyReleased 17
2014.10.08, 16:44:32  [INFORMATION]  Open a project ...
2014.10.08, 16:44:32  [INFORMATION]  Opening file chooser for load.
2014.10.08, 16:44:33  [INFORMATION]  User clicked 'cancel' in file chooser dialog.
List of pressed inputs
keyPressed 17
List of pressed inputs
ctrl
keyReleased 79
keyReleased 17
keyReleased 79

Here you can see I press first ctrl, then o and then the explorer opens. But there is a problem, I didnt get the o keyReleased before opening the dialog (keyReleased 79). The next time I press again the combination I do not get the o keyPressed, but I get the o keyReleased twice, like the missing keyReleased was somehow queued somewhere and not it gets triggered.. ??

On 10/08/2014 04:39 PM, elect [via jogamp] wrote:
> Hi people,
>
> so, I am experiencing a strange beviour with the
> com.jogamp.newt.event.MouseListener

KeyListener ?

you mean 'isAutoRepeat()' of NEWT KeyEvent ?

So you are saying, you experience an auto-repeated 'CTRL-O'
from AWT, but the NEWT KeyEvent shows them as being
not auto-repeat?

~Sven

Sven Gothel wrote

KeyListener ?

Yeah, sorry, I meant the keyListener

Sven Gothel wrote

you mean 'isAutoRepeat()' of NEWT KeyEvent ?

So you are saying, you experience an auto-repeated 'CTRL-O'
from AWT, but the NEWT KeyEvent shows them as being
not auto-repeat?

~Sven

No, isAutoRepeat() was just a little parentesis that changed nothing, I try to be clearer

Take a look to this output

keyPressed 17                                             (keyPressed - ctrl)
List of pressed inputs
ctrl
keyPressed 79                                             (keyPressed - o)
List of pressed inputs
ctrl
o
keyReleased 17                                           (keyReleased - ctrl)
2014.10.08, 16:44:32  [INFORMATION]  Open a project ...                                            (the fileChooser is opened)
2014.10.08, 16:44:32  [INFORMATION]  Opening file chooser for load.
2014.10.08, 16:44:33  [INFORMATION]  User clicked 'cancel' in file chooser dialog.          (I pressed esc to close it, then I will press again ctrl+o combination)
List of pressed inputs
keyPressed 17                                             (keyPressed - ctrl)
List of pressed inputs
ctrl
keyReleased 79                                           (keyReleased - o)
keyReleased 17                                           (keyReleased - ctrl)
keyReleased 79                                           (keyReleased - o)

As you can see, before the fileChooser is opened, a keyReleased-o is missing. When I press again the combination, only the keyPressed-ctrl will be triggered, no keyPressed-o. Moreover there is a double keyReleased-o.
The printlns are the first one to be called

@Override
    public synchronized void keyPressed(KeyEvent ke) {
        System.out.println("keyPressed " + ke.getKeyCode());

So there is nothing blocking them, if you dont see it, they are not triggered..

On 10/09/2014 09:20 AM, elect [via jogamp] wrote: Events are coming from AWT, being transcoded to NEWT events right ?

Can you produce a small unit test reproducing this issue ?
(Copy one of ours and patch it please)

Please open a new bug report with your description
and said unit test - that would be very helpful.

Thank you.

~Sven

I am playing with the keybindings right now.

I have a jFrame containing a jPanel. I am referring to the input and action map of this jPanel. If I add the newtCanvasAwt it doesnt work, if I dont add it, it works. It seems the newtCanvasAwt is hiding somehow the jPanel..

ps: the jPanel is focusable

I am reading this page

http://jogamp.org/jogl/doc/NEWT-Overview.html

At the end it says: " The following example shows you how to use a fifo to pipe events from the EDT (listener) to the rendering loop. "

And in the TestParenting02NEWT.java, I see a while loop

 159         while (duration>0 && !shouldQuit) {
160             glWindow1.display();
161             glWindow2.display();
162             duration -= step;
163             x += 1;
164             y += 1;
165             // glWindow1.setPosition(x,y);
166             glWindow2.setPosition(glWindow1.getWidth()/2,glWindow1.getHeight()/2-y);
167             Thread.sleep(step);
168
169             while( null != ( event = eventFifo.get() ) ) {
170                 final Window source = (Window) event.getSource();
171                 if(WindowEvent.EVENT_WINDOW_DESTROY_NOTIFY == event.getEventType()) {
172                     shouldQuit = true;
173                 } else if(event instanceof KeyEvent) {
174                     final KeyEvent keyEvent = (KeyEvent) event;
175                     switch(keyEvent.getKeyChar()) {
176                         case 'q':
177                             shouldQuit = true;
178                             break;
179                         case 'f':
180                             source.setFullscreen(!source.isFullscreen());
181                             break;
182                     }
183                 }
184             }
185         }

Which is the difference between this and a keyListener?

I created a similar class implementing that keeps checking the keyEvent

public class InputListener2 implements Runnable {

    private int step = 1000;
    private NEWTEvent event;
    private NEWTEventFiFo eventFifo = new NEWTEventFiFo();
   
    @Override
    public void run() {

        while (true) {
           
            try {
                Thread.sleep(step);
            } catch (InterruptedException ex) {
                Logger.getLogger(InputListener2.class.getName()).log(Level.SEVERE, null, ex);
            }

            System.out.println(""+eventFifo.size());
           
            while (null != (event = eventFifo.get())) {
           
                System.out.println("in");
               
                if (event instanceof KeyEvent) {
                    System.out.println("keyEvent");
                    final KeyEvent keyEvent = (KeyEvent) event;
                   
                    switch (keyEvent.getKeyChar()) {
                        case 'q':
                            System.out.println("q");
                            break;
                        case 'f':
                            System.out.println("f");
                            break;
                    }
                }
            }
        }
    }
}

I start it as

Thread thread = new Thread(new InputListener2());
thread.start();

But the eventFifo.size() is always 0..

Ok, I made it easily replicable ^^

https://github.com/elect86/KeyListenerScenario

if you press ctrl+o, the fileChooser opens and you release them, but since the glwindow doesnt have the focus anymore it wont get the release events.

Now comes the problem, the ctrl modifier gets screwed.

Indeed if you close the fileChooser and then press whatever character or modifier (BUT ctrl) you get the corresponding keyPressed and keyReleased.

Instead if you close the fileChooser and press the ctrl modifier you wont get the ctrl keyPressed at all, just the ctrl keyReleased. If you press it a second time this time will work, ctrl keyPressed and ctrl keyReleased.

It is like the focus lost frozes temporarily the next keyReleased of the same modifier used in the last key combination, in this case the ctrl button..

I temporarily solved by using

KeyEvent ke

ke.isAltDown()
ke.isAltGraphDown()
ke.isShiftDown()
ke.isControlDown()