KeyDown(KEY_ESCAPE) Fails

Using polled input under Linux KeyDown(KEY_ESCAPE) dose'nt work at all.

other keys seem to stick after being held down and stop working also?

Const WINDOW_WIDTH=640
Const WINDOW_HEIGHT=384

Local wx=(GadgetWidth(Desktop())-WINDOW_WIDTH)/2
Local wy=(GadgetHeight(Desktop())-WINDOW_HEIGHT)/2
Global main_window:TGadget = CreateWindow( Title$,wx,wy,WINDOW_WIDTH,WINDOW_HEIGHT,Null,WINDOW_TITLEBAR | WINDOW_CLIENTCOORDS)
Global canvas:TGadget=CreateCanvas(0,0,WINDOW_WIDTH,WINDOW_HEIGHT,main_window)
SetGraphics CanvasGraphics(canvas)

ActivateGadget canvas

CreateTimer(10)

enablepolledinput()

While WaitEvent()

	Select	EventID()

		Case EVENT_WINDOWCLOSE
			End

		Case EVENT_TIMERTICK

			If KeyDown(KEY_LEFT)
				SetClsColor Rnd(255),Rnd(255),Rnd(255)
				Cls
				Flip
			EndIf

	EndSelect

End While

.

James, thanks for the reply. Not what I wanted to hear! Windows and Mac versions of the code work perfectly but Linux is again different?

Here is the modified code that gives suprise results. Hold a key down and watch the debug output. Where are the EVENT_KEYUP's coming from?

Const WINDOW_WIDTH=640
Const WINDOW_HEIGHT=384

Global hit[1024]

Function MyKeyDown( key:Int )
	Return HIT[Key]
End Function

Local wx=(GadgetWidth(Desktop())-WINDOW_WIDTH)/2
Local wy=(GadgetHeight(Desktop())-WINDOW_HEIGHT)/2
Global main_window:TGadget = CreateWindow( Title$,wx,wy,WINDOW_WIDTH,WINDOW_HEIGHT,Null,WINDOW_TITLEBAR | WINDOW_CLIENTCOORDS)
Global canvas:TGadget=CreateCanvas(0,0,WINDOW_WIDTH,WINDOW_HEIGHT,main_window)
SetGraphics CanvasGraphics(canvas)

ActivateGadget canvas

CreateTimer(10)

'enablepolledinput()

While WaitEvent()

	Select	EventID()

		Case EVENT_WINDOWCLOSE
			End

		Case EVENT_KEYUP
			DebugLog "KEY UP"
			Select EventData()
				Case KEY_LEFT
					HIT[KEY_LEFT]=0
			End Select
			
		Case EVENT_KEYDOWN
			DebugLog "KEY DOWN"
			Select EventData()
				Case KEY_LEFT
					HIT[KEY_LEFT]=1
			End Select

		Case EVENT_TIMERTICK

			If MyKeyDown(KEY_LEFT)
				SetClsColor Rnd(255),Rnd(255),Rnd(255)
				Cls
				Flip
			EndIf

	EndSelect

End While

.

PLEASE! PLEASE! PLEASE! Someone READ! my posts and PLEASE! TRY! the source under ***LINUX***.

> In your example, holding a key down prints "KEY DOWN" and nothing happens until I release, which prints "KEY UP". Are you getting something different?

YES, if I were getting what you had described there would be no problem. The EVENT_KEYUPs I am seeing are not coming from a KEY being released because I am holding the key down. I still see EVENT_KEYUP when a key is being held down?

PLEASE tell me where I can find the LINUX keyboard reading code and I will attempt to fix it myself.

I don't believe that my english is this poor. And yes I am feeling very perturbed about the lack of support.

Since 1.03 or something you should be getting one keydown, a whole bunch of keyrepeat's and a keyup message, are you on ubuntu gnome or something else? This may also be something that is broken in fltk, sorry I can't test right now.

To help debug try adding a

debuglog currentevent.tostring()

just after waitevent()

Skid,

I am using SuSE 10.1.

The debug data I get back when holding the "up arrow" down and on a single press is.

KeyUp: data=38, mods=0, x=417, y=-3, extra =""

and gtk or kde?

if you want to try something add

		case FL_KEYDOWN:
		case FL_UP:

at line 620 of fltkmaxgui.mod/fltkglue.cpp which might stop it eating arrow keys and the escape key due to it maybe thinking you are wanting to navigate between gadgets or something, it's just a guess but build modules and see...

also a dump of the events you do get would be interesting, try other keys besides arrows and escape, you may get better results...

1. Added case statements to fltkglue but made no change.

2. SHIFT, CTRL, ALT, BREAK... produce keydown only.

3. ESC produces nothing at all.

4. brl.fltkmaxgui produdes keyup events when holding key down.

5 bah.gtkmaxgui produces keydown events when holding keys down.

oops that shoul be fl_keyup not fl_up above

6. If I add EVENT_KEYREPEAT to the equasion. Windows reports them correctly. Linux fails to get any repeats but seems to express them as keyup events instead. Unless using GTK it expresses them as keydown events.

in system.linux.c @ line 91

if ( xeventhandler ){
ifxeventhandler(xevent))return;
}

swallows all the Esc key presses not allowing any to fall through into the switch statement.

Sorry one more guess, will be getting my linux box back tomorrow hopefully, try at fltkmaxgui.mod/fltkglue.cpp[620]:

		case FL_SHORTCUT:
		case FL_KEYDOWN:
		case FL_KEYUP:

which should have the fltk canvas ignore all shortcuts keys of which Escape is unfortunately one.

Just tried the above code change. No key presses at all with those mods applied.

Did notice that the escape key does generate a KEYUP event but no KEYDOWN

Sounds like we've got ourself's a bug!

Using Nigels code above, If I press and hold a key all I get are KEY UP Messages. I have to actually press on a key to get a KEY DOWN message.

I know it's late but I wanted to confirm that it doesn't work properly under Ubuntu either.

Skid,

what events am I meant to be raising when someone holds down a key?
A single keydown followed by a list of key repeats ?

If that's the case I guess the gtk mod needs fixing.

Brucey,

EVENT_KEYREPEAT would seem the most usefull to be generated by a key being held down? GTK seems to return the opposite to FLTK ie it repeats EVENT_KEYUP for a hold.

Brucey, FLTK is not quite up with the play either regarding this. Will have a play this weekend.

Yay... latest GTK mod now does the following :

EVENT_KEYDOWN
EVENT_KEYREPEAT ... (repeating)
EVENT_KEYUP

..amongst other fixes (see HERE for more details.)

GTK working well now thank's Brucey!