QB64.org Forum
Active Forums => QB64 Discussion => Topic started by: SMcNeill on December 29, 2020, 01:47:55 pm
-
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.
-
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.
-
Here's how it basically works:
LINE (5, 5)-(115, 20), &HFF000000, BF
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. :)
-
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.
-
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.
-
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.
-
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.
-
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?
-
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...
-
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.
-
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.
-
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).
-
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?
-
No visual indication would be confusing.
-
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. ;)
-
Your call.
-
Let me know how the latest works. It's a compromise solution -- no pop-ups, but it changes the status area (where OK would normally sit), to instead present the status to PRESS ANY KEY TO INSERT _KEYHIT/_KEYDOWN CODE. We're not really reacting with anything, so I don't think a whole input box would be necessary just to capture a single keypress, but the change to the status below seems like a suitable visual cue to the IDE's status, in case your cat hits CTRL-K while you go grab a soda or something and you wonder where the heck the cursor went.
If it needs further tweaking, I'll work on it tomorrow. I'm going to head on off for the night, as I've got an early day of worthless testing to do at the doctor's tomorrow morning. ;)
-
In DOS EDIT (and thus QBasic) ^K is "set bookmark" (and ^Q is "goto bookmark"). These commands wait for you to enter the number of the bookmark you want to set/goto by putting a "^K" etc. in the bottom right just to the left of the line number indicator. Perhaps a small piece of text on the bottom line indicating the IDE is awaiting further input would be less intrusive but still helpful?
-
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. ;)
Thats why I usually hit Ctrl-C twice just in case. I'm guessing doing the same in this instance would cause undesirable results?
-
In DOS EDIT (and thus QBasic) ^K is "set bookmark" (and ^Q is "goto bookmark"). These commands wait for you to enter the number of the bookmark you want to set/goto by putting a "^K" etc. in the bottom right just to the left of the line number indicator. Perhaps a small piece of text on the bottom line indicating the IDE is awaiting further input would be less intrusive but still helpful?
That's basically what it's doing now, though it's indicating where our normal status goes that it's waiting for an input.
[ This attachment cannot be displayed inline in 'Print Page' view ]
Or are you envisioning something else, and I'm just not visualizing it?
-
Thats why I usually hit Ctrl-C twice just in case. I'm guessing doing the same in this instance would cause undesirable results?
Hit CTRL-K twice, and it'd probably return put "100305k" or "100306k" on the screen for you. It'd return the key value of the next key hit (in this case CTRL, whichever one you hit), and then type the next character on the screen as normal (which would be "k", in this case). I don't think you want to get in a habit of double-tapping CTRL-K quick keycode inserts very much. :)
-
A ton of little tweaks were done on this, this morning, to try and get it to work flawlessly for us. There's more to inserting and proper positioning of text inside a line in the IDE than what you'd think! The way QB64 is structured, it tends to strip off leading and trailing spaces when saving a line of text, so it makes proper inserting of stuff a PITA. (Or at least, it seems that way at the moment, to me.)
I'm thinking things should work as we'd expect now, but if any of you brave folks want to download the last version from the repo or development build and test it out, it'd be appreciated. Feel free to report any glitches (in as much detail as possible so I can reproduce and fix them), ideas for improvement, or just general thoughts on the process, and I'll do what I can to look into anything brought up once I get back from the doctor's later this evening. ;)
-
So far this is amazingly helpful. Saves oodles of time and mouse wear. I calls it a keeper.
-
Message in the status area doesn't follow the interface colors; menu item in Help doesn't contain a hot key marker; Choosing the menu item engages the key detection but doesn't update the status area.
I feel mouse clicks should pass through and interrupt the listening loop.
You added an untracked temp qbx file in the latest commit, please avoid it.
-
Message in the status area doesn't follow the interface colors; menu item in Help doesn't contain a hot key marker; Choosing the menu item engages the key detection but doesn't update the status area.
I feel mouse clicks should pass through and interrupt the listening loop.
You added an untracked temp qbx file in the latest commit, please avoid it.
The status area changes colors? To what? I thought it was always white for the “OK”? Is it the same color as the main text on the screen?
The menu item in help doesn’t need a hot key modifer, does it? Who’s going to “Alt-H, find a hotkey in a list, press it”, when they can just CTRL-K? Not every menu item needs a hot key set for them.
I’ll dig into why clicking from the menu doesn’t update the display when I get back home again Monday. It should, since we just GOTO the same singular routine, but since it’s not, then I’ll need to dig into why it’s not.
As for the mouse, it’s best to ignore it completely. You don’t want people to hit CTRL-K, move the mouse and click elsewhere, then hit a key and expect it to go somewhere else. Usage should be kept as simple as possible: Hit CTRL-K, hit a key, it inserts the code at your cursor position. If users are expecting to hit CTRL-K, move mice, press buttons, print files, take screen copies of stuff, and then finally come back and hit a key, they’re using it wrong. Ctrl-k, hit a key, do the other stuff later — if you screw up, BACKSPACE or CTRL-Z is your friend.
temp qbx files should be listed in the .gitignore, so they’re not passed back and forth, just like the internal\temp folders are. Feel free to add them to the ignore list if you want, or else I’ll get to them as well, when I get home on Monday.
-
For good practice, add the hotkey to the menu.
You are printing with black background in the status area.
A mouse click as "cancel" measure is important, since just showing a message in the status area and locking mouse looks very bad for the end user - the whole IDE doesn't need to be locked. If you can't do it, I'll fix it once you're done with your tweaks.
Do not manually add qbx files.
-
For good practice, add the hotkey to the menu.
You are printing with black background in the status area.
A mouse click as "cancel" measure is important, since just showing a message in the status area and locking mouse looks very bad for the end user - the whole IDE doesn't need to be locked. If you can't do it, I'll fix it once you're done with your tweaks.
Do not manually add qbx files.
I won’t be at home for several days to make any changes, so fix it however you want, so it floats your boat. As long as I can hit a kay and insert its code into the IDE, I’m happy.
-
I'll wait for your tweaks to come to a halt so I can get back to pushing changes.
-
I'll wait for your tweaks to come to a halt so I can get back to pushing changes.
I’m done, as far as I know, except for whatever it is that’s not updating the display when clicked from the menu. I have no clue why it’s not working, at the moment, since it’s the menu code that we GOTO ehen we hit CTRL-K.
-
For good practice, add the hotkey to the menu.
Any suggestion on which key to highlight? “K” is already taken, and it seems odd to me to make something else a hotkey with CTRL-K as the fast combo.
You also might want to go back and add a hotkey to the remark options in the menu. Somebody apparently wasn’t applying good practice when they added those; none of the options have one — Toggle, Add, or Remove.
-
I've already fixed it. Please use git pull before you continue working (branch: https://github.com/QB64Team/qb64/tree/fix-ctrlk (https://github.com/QB64Team/qb64/tree/fix-ctrlk) - latest commits: https://github.com/QB64Team/qb64/commits/fix-ctrlk (https://github.com/QB64Team/qb64/commits/fix-ctrlk))