Is there a reason i cant record ctrl+j?

[STxAxTIC]

So this is something weird - I don't know if its my keyboard, or my system, or how im writing this code.... but for whatever reason, pressing Ctrl+J doesnt pick up, but Ctrl+L does.

I just need another set of eyes to look at it. This is simple to someone.

Code: QB64: [Select]

1. DO
2.     IF _KEYDOWN(100305) OR _KEYDOWN(100306) THEN ' Both control keys
3.         ctrl = 1
4.     ELSE
5.         ctrl = 0
6.     END IF
7.  
8.     kh = _KEYHIT
9.  
10.     IF kh = ASC("L") OR kh = ASC("l") THEN
11.         IF ctrl = 1 THEN PRINT "ctrl-";
12.         PRINT CHR$(kh)
13.     END IF
14.  
15.     IF kh = ASC("J") OR kh = ASC("j") THEN
16.         IF ctrl = 1 THEN PRINT "ctrl-";
17.         PRINT CHR$(kh)
18.     END IF
19.  
20. LOOP

[SpriggsySpriggs]

That is strange.

[STxAxTIC]

okay, so somehow code 13 has something to do with this?...

Code: QB64: [Select]

1. DO
2.     IF _KEYDOWN(100305) OR _KEYDOWN(100306) THEN ' Both control keys
3.         ctrl = 1
4.     ELSE
5.         ctrl = 0
6.     END IF
7.  
8.     kh = _KEYHIT
9.  
10.     IF kh = ASC("L") OR kh = ASC("l") THEN
11.         IF ctrl = 1 THEN PRINT "ctrl-";
12.         PRINT CHR$(kh)
13.     END IF
14.  
15.     IF kh = 13 THEN
16.         IF ctrl = 1 THEN PRINT "ctrl-";
17.         PRINT "j"
18.     END IF
19.  
20.     IF kh = ASC("J") OR kh = ASC("j") THEN
21.         IF ctrl = 1 THEN PRINT "ctrl-";
22.         PRINT CHR$(kh)
23.     END IF
24.  
25. LOOP
26.  

[STxAxTIC]

This captures it in smaller code:

Code: QB64: [Select]

1. DO
2.     PRINT "Press ENTER or Ctrl+J"
3.     DO
4.         IF _KEYHIT = 13 THEN EXIT DO
5.     LOOP
6.     PRINT "Good work.": PRINT
7. LOOP

[STxAxTIC]

Alright this was solved. It happens for a reason of some kind. Work-around shall be inkey$ to catch the J.

[FellippeHeitor]

CTRL+J translates into CHR$(10) for MS-DOS reasons. Read INKEY$ instead and look for CHR$(10) and you're golden.

Code: QB64: [Select]

1. PRINT "hit Ctrl+J:"
2. DO
3.     k$ = INKEY$
4.     IF k$ = CHR$(10) THEN PRINT " You did it."
5.     _LIMIT 30
6. LOOP

For reference (http://www.physics.udel.edu/~watson/scen103/ascii.html):
 

[SMcNeill]

Just another example of _KEYHIT and _KEYDOWN being broken.  If you're coding for Windows, use my custom keyboard library instead.

[Pete]

That's why I call it _HITKEY. BASICally, INKEY$ rules!!!!

Pete

[SMcNeill]

That's why I call it _HITKEY. BASICally, INKEY$ rules!!!!

Pete

INKEY$ is just as bad.  Try the following, for example:

Code: QB64: [Select]

1. DO
2.     i$ = INKEY$
3.     IF i$ <> "" THEN PRINT ASC(i$, 1)
4.     _LIMIT 30
5. LOOP

Now hit I, CTRL-I, TAB, and CTRL-TAB.  What's the output that you're seeing?

73 (or 105, depending on caps lock or shift state)
9
9
(nothing)

Ctrl-I is the exact same as TAB -- regardless of capslock, or shift-status, and CTRL-TAB doesn't even exist at all.  It's absolutely impossible to generate a ctrl-tab keypress, or to designate the difference between SHFT-CTRL-I, CTRL-I, and TAB.

INKEY$ and _KEYHIT both fail to read multiple keypresses and combinations.  Fellippe's solution is only viable in this one singular instance.  Try to do the same with CTRL-M with INKEY$....  (Hint:  It's the 13th letter of the alphabet, so much like J is 10, M is going to be....  ???)   (Hint 2:  What's the value of the ENTER key?)

When you start looking at extended key presses, or reading all the various key combinations you can make with your keyboard, you're going to have to make your own input handler.  QB64's built in commands aren't up to the task.

[Pete]

QB has always had these "Mickey Mouse" challenges. Ctrl + Tab is certainly one of them, as INKEY$ On KEY, etc. are blocked from detecting this combination. INP(&h60) is the Mickey Mouse workaround, but it isn't perfect, as the status doesn't change until either both keys are released, or ctrl is held while a different key is pressed, before tab is pressed again. Also, you have to press ctrl first or write a more elaborate key handling routine....

Code: QB64: [Select]

1. DO
2.     _LIMIT 30
3.     DEF SEG = 0
4.     IF PEEK(1047) MOD 16 = 1 OR PEEK(1047) MOD 16 = 2 THEN shift% = -1 ELSE shift% = 0
5.     IF PEEK(1047) MOD 16 = 3 OR PEEK(1047) MOD 16 = 4 THEN ctrl% = -1 ELSE ctrl% = 0
6.     IF PEEK(1047) MOD 16 = 5 OR PEEK(1047) MOD 16 = 6 THEN ctrlshift% = -1 ELSE ctrlshift% = 0
7.     DEF SEG
8.     b$ = INKEY$
9.     IF ctrl% THEN
10.         IF INP(96) = 151 THEN
11.             PRINT "Ctrl + TAB"
12.             WHILE INP(96) = 151: _LIMIT 30: b$ = INKEY$: WEND
13.         END IF
14.     END IF
15. LOOP UNTIL b$ = CHR$(27)

Pete

[STxAxTIC]

If you're coding for Windows, use my custom keyboard library instead.

...

Fellippe's solution is only viable in this one singular instance.

Same same.

Until there is a single, universal solution to this, I see nobody having the cake and eating it too.

(i think qb64 programs should target every platform supported by the compiler. i can't really invest in windows-only anything.)

[SMcNeill]

QB has always had these "Mickey Mouse" challenges. Ctrl + Tab is certainly one of them, as INKEY$ On KEY, etc. are blocked from detecting this combination. INP(&h60) is the Mickey Mouse workaround, but it isn't perfect, as the status doesn't change until either both keys are released, or ctrl is held while a different key is pressed, before tab is pressed again. Also, you have to press ctrl first or write a more elaborate key handling routine....

Code: QB64: [Select]

1. DO
2.     _LIMIT 30
3.     DEF SEG = 0
4.     IF PEEK(1047) MOD 16 = 1 OR PEEK(1047) MOD 16 = 2 THEN shift% = -1 ELSE shift% = 0
5.     IF PEEK(1047) MOD 16 = 3 OR PEEK(1047) MOD 16 = 4 THEN ctrl% = -1 ELSE ctrl% = 0
6.     IF PEEK(1047) MOD 16 = 5 OR PEEK(1047) MOD 16 = 6 THEN ctrlshift% = -1 ELSE ctrlshift% = 0
7.     DEF SEG
8.     b$ = INKEY$
9.     IF ctrl% THEN
10.         IF INP(96) = 151 THEN
11.             PRINT "Ctrl + TAB"
12.             WHILE INP(96) = 151: _LIMIT 30: b$ = INKEY$: WEND
13.         END IF
14.     END IF
15. LOOP UNTIL b$ = CHR$(27)

Pete

@Pete -- Doesn't work.  Run it and hit CTRL-TAB, and then hit CTRL-I.   You have the exact same issue here that INKEY$ has.  You can't tell the difference in those two keypresses at all.

[Dav]

I was wondering, Is there a way to tap into glut's keyboard function to get keypresses?  Would there be any difference in doing that?   I was looking at the glut functions and can get glutGet and glutDeviceGet to work, but that's all I have experience with so far.  How much of glut functions can we access from QB64 code? (Im a newbie in that stuff...)

- Dav