Key-cmds in Win standalone

[jmk_phd]

Upon completing a much simplified redesign of my freeware cross-platform (Mac/Win) music app, I’ve encountered a vexing problem that affects only the Windows standalone. (The stack works flawlessly in the IDE on my Mac and as a Mac standalone, but thankfully I acquired a cheap refurbished PC last year in order to catch just such problems on Windows.)

There are three radio-btn groups, each of which controls the value of a corresponding mainstack custom prop. Clicking any button (a) changes the value of the corresponding prop, and (b) triggers a routine that alters the graphics to match the new configuration of the three custom props.

This *seems* to work okay for both standalones – although I don’t understand why in Windows a radio-btn label is sometimes framed with a dashed border – but I’d rather provide users key combinations to avoid the clumsy mouse/trackpad.

Wary of sending a mouseClick message to a radio-btn, my key combinations just (a) highlight the appropriate radio-btn, (b) change the value of the corresponding custom prop, and (c) trigger the routine to update the graphics.

All fine for the Mac standalone, but for the Windows standalone the key combinations sometimes fail to work – and worse, disable any other key combination from working until I’ve manually clicked a few radio-btns.

I’ve already done what I hate doing – namely, complicating the original simple code in the hope of a fix. (In this case – long story – identifying the platform and branching accordingly.) To no avail.

(I recall on a previous project having had to try clearing some queue of key presses, but no idea whether some such needs to be implemented specifically for a Windows standalone.)

Inasmuch as the problem is evident only with the Win standalone, I’m not sure what to provide anyone curious to check this out. Inasmuch as it’s freeware, I could just zip the entire stack (minus the audioclips that bloat the standalones). I’m very careful to comment my code extensively, but that still seems too much to ask.

So I’m hoping instead that something about dealing with coded keyboard shortcuts in a Windows standalone will ring a bell with someone.

Thanks much as always!

jeff k

[SparkOut]

On Windows the screen navigation by keyboard works with the tab key, and LiveCode will move selection from control to control in the order of its layer to the next higher layer - if that next control has traversalOn set to true (and some other criteria like field lockText status). I think you might be seeing the selection highlight with your dashed border.
Making a selection of the highlighted choice by keyboard is normally by pressing the spacebar (or sometimes Enter/Return).
If you provide the stack I would be willing to take a look. I make no promises about when I will be in a situation that I can do that though.

[jmk_phd]

Thanks, SparkOut, for educating me as to how Windows users typically navigate and select controls – and that the dashed border in Windows is actually a feature that identifies the currently focused button.

Per your instructions, I did find that I can tab through the radio btns across the three btn groups, using the spacebar to select the currently focused button. But it’s a rather tedious and inefficient procedure: For example, getting from first btn of the first radio group to the last btn of the third group requires 22 tab-key presses before making the desired selection with the spacebar. Who wouldn’t simply reach for the mouse/trackpad instead?

I'd hate to make that the only alternative for Windows users, while Mac users have the luxury of custom cmdKey combinations.

There are 3 btn-groups:
Group1 (Family) has 4 btns, triggered by Opt+Cmd+[1-4]
Group2 (Mode) has 7 btns, triggered by Cmd+[1-7]
Group3 (Tonic) has 12 btns – corresponding to the 12 notes of the musical scale, with the naturals (white notes: c-d-e-f-g-a-b) triggered by Cmd+[letterkey] and the accidentals (black notes: c#-d#-f#-g#-a#) triggered by Opt+Cmd+[letterkey]

By the way, my first design employed Shift+Cmd+[letterkey] for accidentals, which seemed entirely intuitive because an accidental is a half-step above its neighbor. When this failed in the Win build, I changed this to Opt+Cmd+[letterkey], but found that in the Mac build Opt+Cmd+c instead displayed the taskbar. So currently I first identify the platform and then branch to employ Shift+Cmd (Mac) and Opt-Cmd (Win).

What’s truly strange is that in the Windows build the cmdKey combinations seem to work fine for the first two groups, and even for the naturals in the third group. But once I use the cmdKey combination for an accidental (i.e., Alt+Ctrl+[letterkey] on a Win keyboard), *all* cmdKey combinations – and even navigating via tab key – cease responding and only begin working again after I’ve manually clicked on a few different buttons.

I will build a new stack with just the button groups and (per your clue) just play around with changing various button properties until I find something that works.

Thanks much for your reply.

jeff k

[SparkOut]

Mmm, you might be using key combinations that have other uses in Windows. https://www.computerhope.com/shortcut.htm this might be helpful as a jumping off point, there are a lot of permutations linked for different situations to check through. I still don't mind helping if I see the stack or a cut down version.

[jmk_phd]

Yes, I'd considered that possibility (after discovering that Opt+Cmd+D could not be used on the Mac because this would only display the Mac taskbar). But I've looked up each problematic key combination on the convenient website https://defkey.com that maintains a database of all programs employing a given combination. None of these is used by the Windows OS.

I've just made a stack that includes only the btn groups and the script used to hilite these so I can experiment with the btn properties. I'll report back if I discover something useful.

Although it would be a hassle, I suppose I could install LC on the Windows laptop to see what happens with these in the IDE.

[jmk_phd]

For what it’s worth, I did promise to post an update here after experimenting with a bare-bones stack that included only the three radio-btn groups for which I wished to employ custom commandKey combinations, along with three fields to monitor the respective custom property set by each.

Savvy forum members have demonstrated here many times the value of this strategy to isolate/troubleshoot problem code. It’s certainly true.

Anyway, I must have misunderstood an entry in the LC dictionary that reads, “If a radio button’s or checkbox’s hilite is true, the radio button or checkbox option is selected.”

This did always seem to be the case on a Mac – that is, setting the hilite of a grouped btn served also to make it the selected btn. But apparently not in Windows.

As truly ugly as is the dashed border around the label of a selected radio-btn in Windows, it was at least a clue that hiliting a different btn in the group via script did *not* change the selection itself. (For example, if one happened to hit the spacebar, the btn with the dashed border – not the btn hilited – would be triggered.)

The solution that seems to be working (so far) for both the Mac and Windows standalones is to have each custom commandKey combination instead send a click to the location of the targeted radio btn, which both hilites and makes it the selection. That in turn triggers the btn script irrespective of whether the “click” was actual or virtual.

Although probably of little value to anyone else, happy to share the final working version of this TestKeyCmds stack.

jeff k

P.S. I did install LC 9.6.11 on the PC just in case the debugger might shed some light on why earlier versions of the stack were failing occasionally when built as a Windows standalone. On one occasion the commandKeyDown handler yielded a pKey value of 65513 – which strangely resembles a raw keyCode of the sort that I’d learned about for a previous project, but which I can’t identify. No matter, as long as the current version of my test stack is working.

[SparkOut]

Good that you have a working solution. I confess to being somewhat intrigued and have a curiosity to see your test stack to understand what you see and how that matches what I would expect the typical behaviour to be on Windows. Not that there's any urgency or necessity, of course.

[jmk_phd]

Thanks so much for the insight you’d provided regarding Windows, which is still essentially alien to me. (I really must get a copy of “Windows for Dummies.”)

I’ve attached the latest “TestKeyCmds.livecode” stack. To see the Mac vs. Win issue that I’ve wrangled with, I suppose that you’d need to build and compare the respective standalones (which is really quick for this bare-bones stack).

Compared to previous attempts, I’ve thankfully not yet been able to break the Windows standalone of this version. (The Mac version never was a problem.) But do let me know if it breaks for you.

At my end, the next tricky step is to incorporate this new code into the actual much more complicated app. Although the finished app will be distributed as freeware, the time spent on this was a valuable adventure in programming.

TestKeyCmds.livecode.zip

(5.26 KiB) Downloaded 121 times

jeff k

[jmk_phd]

Upon incorporating the aforementioned code into the actual program, the shortcut keys all worked fine when tested on the old refurbished Windows 10 laptop I’d purchased last year to test Win standalones.

So no problem. Right?

Yet the Danish musician who inspired the app has reported that while most of the shortcuts did work for him as expected, this was not the case for the Alt+Ctrl+[1-4] shortcuts.

Although I can’t reproduce the problem on my Win 10 laptop, the fact that the shortcuts employing Shift+Ctrl+[letterkey] did work for him suggests that perhaps I can substitute Shift+Ctrl+[1-4] as an alternative.

(I’ve asked him to let me know whether by chance he’s using Windows 11, just to rule out that as a possibility.)

I’m trying to get this resolved before my current Windows signing certificate expires in May. With my only commercial app going nowhere, the new $300/yr cost of renewing this can’t be justified to support only a freeware app.

jeff k