Windows via Parallels quirk?

[jmk_phd]

Back in June, a forum member provided me a wonderful solution to a problem involving keyboard input that worked flawlessly in the IDE and in the macOS standalone.

The app worked essentially as follows:
(1) A geometric figure is displayed on screen.
(2) The user is required to respond by pressing one of four keys (1, 2, 3, or 4).
(3) The program waits until a keysdown() function = <> "" -- i.e., a non-empty list of key codes of pressed keys.
(4) The contents of the list is evaluated and the keypress is flagged either as correct, incorrect, or invalid (i.e., neither any single one of those four number keys).
(5) The program waits until keysdown() = "" -- i.e., until no key is being pressed -- then alerts the user as to whether the response was correct or incorrect.

The IDE and Mac standalone versions work flawlessly, but when the Win version is run via Parallels, about half the time the target response key must be pressed two or three times -- or more often simply held down for about as long -- before the feedback alert is triggered.

I suspect that this is due to some kind of latency problem inherent in the Parallels emulation that does not occur when a Win standalone is run natively on a Windows PC.

I know that I really ought to rent or purchase a Windows PC in order to test whether my app works as intended on that platform, but -- being on a shoestring budget, with no promise that my app ever will earn a dollar -- I've opted instead to employ Parallels for testing.

The solution is obviously to test the Win standalone instead on an actual Windows PC. In that case, my experience is just an alert to other LiveCode developers not to rely upon testing an app via Parallels or similar methods of virtualization.

jeff k

[FourthWorld]

I don't know if it'll make a difference, but it may be worth trying a second emulator, and the best in my experience is free and open:
https://www.virtualbox.org/

[richmond62]

I don't know where you live, but round here, for people who have no shoelaces one can pick up a second-hand PC for about 50 Euros.

[stam]

I don't know if it'll make a difference, but it may be worth trying a second emulator, and the best in my experience is free and open:
https://www.virtualbox.org/

Free and open it may be, but in my experience VirtualBox is not better. Both VMWare Fusion and Parallels are faster on my system. Both offer free trials, so not hard to check what works fastest for you. It may be difficult to discern speed differences in “normal” operation, but try a more demanding app (games are a good measure of this as they often include a “frames per second” as measure of performance).

Having said that, it seems unlikely the issue described is due solely to emulation. I suspect optimisation of code would eliminate this problem. I vaguely remember a thread similar to this and remember thinking it should be done differently….

Maybe the OP could post the code and/or a link to the previous thread?

[richmond62]

I vaguely remember the thread

Aha: so this has been discussed before?

Certainly mucking around with keysDown just now proved a bit confusing.

Perhaps because keysDown looks as rawKey codes, and not what is marked on one's keyboard.

Frankly I would dump keysDown and just use keyDown.

[SparkOut]

Original discussion: https://forums.livecode.com/viewtopic.php?f=7&t=37044

[stam]

I don't know how much of the issue is due to the keysDown() and how much is actually putting the app into a state of waiting for keypress to act on - seems inefficient to me.

As I understand the requirements:
- A limited number of keys will be accepted as key presses (eg numbers 1 - 4)
- only the first keypress should be acted on, the rest should be ignored
- key combos should be detected as well

Having toyed around i bit i quickly realised that key combos using the option key are error prone as these resolve to a different char at low level, depending on keyboard mapping. You can detect the option key being down, but the key returned on keyDown/Up won't be what you expect... eg pressing option-k on mac will remove as optionKey() = "down" and "˚" on Mac using UK keyboard map.

You can of course account for this, but you would need to code it so that what appears to be option-K is actually interpreted as option-˚ by livecode. But of course this will be different for different OS's and keyboard mappings - so best avoided i think! On the plus side, i finally learned how to get the ˚ char

I put together a stack that fulfils the above requirements - I'd be interested to know if the OP still finds this non-functional using an emulator...

2/3 of the code is for detecting the key combos - can be much shorter if that's not required. Unless there is a requirement to parse for both command and control key combos on Mac, you could simplify this further to just the commandKey as this resolves to controlKey on non-Mac OS's.
The code is all in the card script:

Code: Select all

local sKey
constant kAllowedNums = "1,2,3,4"
constant kAllowedControlKeyCombos = "command 1,control i,control 2"

on keyUp pKeyName
     local tChars, tCommands
     if sKey is not empty then exit keyUp -- this will prevent further entry until initKey below is run
     if pKeyName is in kAllowedNums and commandKey() is not "down" and controlKey() is not "down" then 
           put pKeyName into sKey -- this will prevent more key presses being registered
          // do stuff here if permitted number pressed without a modifier
          put sKey into field "keyPressed"
          //
          exit keyUp
     end if
     
     --- DETECT KEY COMBOS   -- alt/option combos are not accounted for, as these resolve to a differeNt char rather than keyCombo at low level ---
     repeat with x = 1 to the number of items of kAllowedControlKeyCombos
          put word 1 to -2 of item x of kAllowedControlKeyCombos into item x of tCommands -- get the combo key
     end repeat
     repeat with x = 1 to the number of items of kAllowedControlKeyCombos
          put the last char of item x of kAllowedControlKeyCombos into item x of tChars -- get the keys of the key combos
          if pKeyName = item x of tChars then
               switch item x of tCommands // command or control both valid on mac, both become control on Win
                    case "command"
                         if  commandKey() = "down" then
                              put "Command-" & pKeyName into sKey
                              // do stuff here
                              put sKey into field "keyPressed"
                              //
                              exit keyUp
                         end if
                         exit keyUp
                         break
                    case "control"
                         if  controlKey() = "down" then
                              put "Control-" & pKeyName into sKey
                              // do stuff here
                              put sKey into field "keyPressed"
                              //
                              exit keyUp
                         end if
                         break
               end switch
          end if
     end repeat
end keyUp

command initKey
     put empty into sKey
     put "<Nothing>" into field "keyPressed" of me
end initKey

[richmond62]

Looking at point #4, there should be no need to look at keys down as the OP is trying to trap single keys pressed.

[stam]

...
(3) The program waits until a keysdown() function = <> "" -- i.e., a non-empty list of key codes of pressed keys.
...
(5) The program waits until keysdown() = "" -- i.e., until no key is being pressed -- then alerts the user as to whether the response was correct or incorrect.

Hi Jeff,
No need to check keysDown() - the example i posted above fires on keyUp and responds only to the first key press, ignoring the rest (and as far as i can tell should do what you're doing). As you're waiting until the keysDown() is empty to respond to the user, this is effectively the keyUp message - not sure why you can't just use that...

Since you have an emulator running would be interested to know if you still have problems with running the stack i posted above - if yes then it is very likely to be the emulator, but if not, it's the keysDown() based code...

S.

[jmk_phd]

Thanks for everyone's replies.

I hesitated posting this question because the strategy of employing keysDown() proved to be so very controversial (as evident here, as in the original thread that @SparkOut kindly tracked down and identified).

Like most forum participants I was very skeptical of the keysDown() strategy when it was proposed, inasmuch as the conventional -- and nearly always prudent -- wisdom is to employ the more straightforward keyUp() that I too had relied upon initially.

But, believe me, I tried every suggested tweak using keyUp() -- which included inserting a brief delay or flushing the event queue of errant keypresses -- and found that nothing other than the keysDown() strategy worked reliably in all situations (e.g., with the overly long or impulsively quick repeated keypresses likely to be encountered when the program is used with the targeted population of neurologically-impaired test respondents).

And, apart from the fact that keysDown() returns raw keycodes -- which necessitates monitoring for both keyboard and keypad raw codes -- this actually simplified my script by dozens of lines without any adverse impact upon its responsiveness.

So I know that when run on a Mac the program works *flawlessly* both in the IDE and as a macOS standalone. My assumption was that -- this being the case -- it should work similarly when the Windows standalone runs natively on a Windows PC.

Obviously, the only way to confirm this definitively is to run the app on an actual PC, so as to rule out the possibility -- in my guess, the likelihood -- that the problem encountered when running it via Parallels is due to a quirk in how the latter handles key events.

None of my acquaintances uses Windows, so I will try to rent a PC and report back here on what I learn. If, as I expect, the Windows standalone works just fine, it will be a cautionary lesson not to rely upon an emulator when testing cross-platform versions of our LiveCode apps.

Inasmuch as my app will be available for both Windows and macOS, it is really a non-issue -- apart from testing -- that it does not work properly in emulation.

jeff k

[stam]

Hi Jeff,

Personally i find it hard to believe such convolution is required for such a seemingly simple task.

I am curious - did you test the stack I posted here? Does it not do what you requested? Does it work in emulation?

S.

[SparkOut]

As someone who a) has Windows machines and b) not in any professional or social sphere to have any reason to disclose your proprietary information, if you're trusting enough to hand over your proprietary information, I'd be happy to test your Windows standalone.

[dunbarx]

Stam.

I will wait until the OP works with your stack. He would be a much better tester than I.

The original solution exploited the fact that "keysDown()" is a function, where all the other "keyWhatevers" are messages. It may be that using a message, and I agree surely the "right" way, will do what the OP wanted. But many have tried and failed, including me. And I recall that my last offering with the keysDown function still needed work.

Let's wait and see. I would be very interested in how using a message effectively was missed in the earlier threads.

Craig

[dunbarx]

We all have to remember that there are two arcs here. One is about delays with a Windows gadget and the other is whether using the "keyUp" message, or any of its relatives, can do what the OP originally wanted, as opposed to the "keysDown() function..

Craig

[stam]

We all have to remember that there are two arcs here. One is about delays with a Windows gadget and the other is whether using the "keyUp" message, or any of its relatives, can do what the OP originally wanted, as opposed to the "keysDown() function..

Craig

Craig, the only 'arc' you didn't mention was the main one... The thread is titled "Windows via Parallels quirk?" and Jeff is issuing warnings about using emulators. To the extent that he is going out to rent a windows box.

Personally i must say i'm not at all invested in whether he uses keysDown() or any other message, and neither am i invested in whether this works properly on a 'proper' windows box, although would be glad for him if it did...

I'm more interested to hear whether the stack i posted fails the emulator or not. If Jeff is correct in issuing warnings and even the stack i posted fails, then this is probably something that should be reported and he is right to warn the community. To me it seems more likely to be a coding issue, but it's impossible for us to tell.

I can't check myself, as i long ago had to ditch my Win partitions and emulators, as laptops have a fixed amount of storage. As he clearly has Parallels up and running, it would be a simple test to run the stack. Of course the stack also has to do what he wanted it to do. Hence the 3 questions in my previous post...
Let's see if we get a response...