Proposed IDE Change CTRL-K (Keycode)

[SMcNeill]

So, in my personal version of QB64, I’ve sat down and added a quick command for Keycode.  Much like the ASCII chart, it’s included in my Help menu, and has a CTRL-K quick key combo to pop it up.  Once you’ve popped up the screen, it twiddles its thumbs for 1 second, doing nothing (a _DELAY 1 pause), giving you time to let go of any unwanted keys, and then after that it accepts your next keypress and enters that keycode into your IDE.

For me, this is a godsend for saving time and looking up codes on the web.  All I need is CTRL-K, wait a sec, hit left arrow, and 19200 pops up where my cursor is, in the IDE.  CTRL-K, pause a sec, hit CTRL, and 100305 or 100306 goes into the IDE.

It’s a shortcut combo to automatically insert keyhit codes into the IDE.


If you guys want, I can easily add the code into the repo for everyone else to enjoy, as I currently use it.  If nobody else likes the idea, I can simply keep it in my personal version.  If somebody has a different behavior, idea, or need (such as a toggle to swap between keyhit, inp, and devices codes), let me know and I’ll see about adding such features before pushing them into the repo.

Let me know what you guys think, and want, and I’ll look into adding the change into the repo when I get back home after taking care of mom this week.

[johnno56]

Sounds like a great idea... May I offer a 'slight' modification? Perhaps a a short 'audio' response, say about 0.5 secs, after ctrl+k? Might help cure the, "Did I press ctrl+K or not?". You know how programmers can be so easily distracted?... lol. Right?... Ok. How "I" can be so easily distracted... *sigh*

Just a thought.

[SMcNeill]

Here's how it basically works:

Code: QB64: [Select]

1. DO
2.     k = _KEYHIT
3.     IF (_KEYDOWN(100305) OR _KEYDOWN(100306)) AND (k = ASC("k") OR k = ASC("K")) THEN PRINT GetKeyCode
4.     _LIMIT 30
5. LOOP UNTIL k = 27
6.  
7.  
8.  
9.  
10.  
11.  
12.  
13. FUNCTION GetKeyCode
14.     tempimage = _NEWIMAGE(240, 120, 32)
15.     w = _WIDTH * _FONTWIDTH
16.     h = _HEIGHT * _FONTHEIGHT
17.     d = _DEST
18.     s = _SOURCE
19.     _DEST tempimage
20.     DO
21.         k = _KEYHIT
22.         _LIMIT 30
23.     LOOP UNTIL k = 0
24.     DO
25.         CLS , &HFF000077
26.         k = _KEYHIT
27.         IF k > 0 THEN k$ = STR$(k)
28.         LINE (5, 5)-(115, 20), &HFF000000, BF
29.         _PRINTSTRING (5, 5), "Keycode: " + k$
30.         tempHWimage = _COPYIMAGE(tempimage, 33)
31.         _PUTIMAGE (0, 0)-(w, h), tempHWimage
32.         _LIMIT 30
33.     LOOP UNTIL k$ <> ""
34.     _DEST d
35.     _SOURCE s
36.     _FREEIMAGE tempimage
37.     GetKeyCode = ABS(k)
38. END FUNCTION

Pop-up a quick input screen, get a keypress, return the value of the keypress.

Use CTRL-K to trigger the routine, then hit any key.  It's that simple, more or less.  :)

[OldMoses]

I think this guy sums up my feelings on this subject.

Perhaps it might be handled like the color sliders for _RGBA32(  --> Hit shift+ENTER etc. etc.
Only it would manifest  like _KEYDOWN( --> hit desired key for code.

[SMcNeill]

Perhaps it might be handled like the color sliders for _RGBA32(  --> Hit shift+ENTER etc. etc.
Only it would manifest  like _KEYDOWN( --> hit desired key for code.

I’m not certain that syntax would be so desirable.  Let’s say I want to allow an user to assign an key for a command.  LEFT might be ASC(“A”), or it might be the left arrow....   How would you type IF _KEYDOWN(LEFT) THEN....??  Wouldn’t that L give you its keycode, in your example?

CTRL-K works as a quick insert command, and doesn’t pop up automatically to interfere with any typing you’re trying to do.

[OldMoses]

You're right, I thought of that a while after I posted. CTRL-K would be better. At any rate, I'm in favor of the idea.

[SMcNeill]

Pushed an initial test change into the IDE, so if anyone is wanting to test it out, grab the latest version of the development build (or a copy from the github repo), and give it a go.

CTRL-K should now pop-up a quick screen which basically just says "KEYCODE: 0", as a visual cue that you're waiting for a key hit (as per johnno65's idea above for user feedback, though I chose a visual cue rather than an audio one).  As soon as that screen pops, and you let go of CTRL-K, the IDE then waits for you to press any key thereafter, and it quickly inserts that keyhit/keydown code into your program at wherever the print cursor is currently at.

One note:  I've got this tossing a blank space into the program by default both before and after the quick insertion.  Are folks OK with this basic behavior, or would you guys prefer for me to strip off those leading/trailing spaces?  Personally, I like the extra whitespace before and after an auto-insert like this, as it helps me keep track of what I've just did, but I'll understand if others prefer to just insert the value without the auto-spacing including.  Just let me know what you guys prefer, and I can tweak to the preferred style.

[FellippeHeitor]

tempHWimage doesn't seem to have been freed.
Please check that the menu item will have a hot key (# before the desired letter).
The hardware image overlay flickers in the current implementation. Do you get any flickering?

[SMcNeill]

I wasn’t seeing any flickering, but I’ll check into it, as it’s obvious from your video you were.  Why the hardware image doesn’t keep rendering itself over the software screen, is a mystery to me.  I’m digging...

[FellippeHeitor]

You might wanna consider using a regular textbox so it fits with the rest of the interface as well. Might be something like the Math box, or even a copy of the idemessagebox sub with custom input.

[SMcNeill]

You might wanna consider using a regular textbox so it fits with the rest of the interface as well. Might be something like the Math box, or even a copy of the idemessagebox sub with custom input.

I was being lazy.  :P
To be honest, I prefer it without any sort of pop-up.  I like the simple idea of just CTRL-K, release, hit key, insert code.  Is a pop-up really necessary, in this instance?  The moment we hit a key, we insert its code.


Flickering was due to lack of a DISPLAY statement, which makes sense.  Hardware images show and free themselves as soon as _DISPLAY is called (which is why theres no freeimage for the handle).  I’m thinking that should be gone now.

[FellippeHeitor]

I still get the flickering after the latest commit.

tempHWimage still doesn't seem to have been freed.
Also, please check that the menu item will have a hot key (# before the desired letter).

[SMcNeill]

I still get the flickering after the latest commit.

tempHWimage still doesn't seem to have been freed.
Also, please check that the menu item will have a hot key (# before the desired letter).

Hardware images show and free themselves as soon as _DISPLAY is called (which is why theres no freeimage for the handle).  As for the flickering, it’s got me baffled at the moment.  I’m not seeing it, and I have no idea why you are either.  Removing that screen may be for the best, completely.  Is it honestly needed?

[FellippeHeitor]

No visual indication would be confusing.

[SMcNeill]

No visual indication would be confusing.

Why?  It’s not confusing without a visual confirmation that CTRL-C copied text.  There’s no pop-up “Text copied, hit ENTER”.  :P

You’d get the visual feedback the moment you hit a key, in the form of its code appearing in the IDE.  ;)