Windows via Parallels quirk?

[dunbarx]

Stam.

My first "arc" (perhaps a bit flip, but Windows does that to me) was "delays with a Windows gadget". Is that not the title, and point of the thread? I am serious; am I misunderstanding?

Craig

[stam]

It's not "delays with a Windows gadget" - the specific issue is regarding Parallels - running a Windows PC in emulation - effectively running a whole PC inside a Mac window.

It may well be the case this works fine on Windows machine, but running the built app in an emulator is exposing some weakness.

The question is: is the weakness due to the emulator or due to the code?
Does that make sense?

[jmk_phd]

Stam (and all) --

In answer to your question, I did build a Windows standalone of your keyDetection.livecode stack and ran it in emulation via Parallels. Not at all to my surprise, it worked just fine and seems to avoid the two pitfalls that befell previous iterations of suggested scripts that employed keyUp -- namely, responding improperly to overly-long keypresses and/or to two keypresses in quick succession.

This suggests at least that Parallels has a problem handling key events when using the keysDown() strategy, and not with your simpler and more elegant keyUp code.

Of course, only running my .exe natively on an actual Windows PC will confirm whether the problem is with Parallels or with some quirk in the LC Windows standalone that does not occur with the macOS standalone. (Frankly, my bet is on the former: that the .exe will run just fine on an actual Windows PC.)

Still, I will try a major rewrite of the code employing Stam's strategy, just to see what happens. The lines provided that handle control-key combinations are irrelevant, but I'll have to figure out where to insert his "command initKey" that clears the decks for a new item -- which, unlike "on so-and-so" and "function so-and-so", is something new to me. This all may take a couple of days, but I do promise to report back here.

jeff k

[jmk_phd]

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.

I truly appreciate your very generous offer to try out the Windows standalone. There's no issue regarding proprietary information, inasmuch as the demo version is available as an anonymous download that displays only the first two subtests. (A registration key that unlocks the full test is available only to persons who can document that they are licensed clinical neuropsychologists.)

It is a rather hefty 15 Mb .msi installer file -- code-signed to avoid those nasty warnings -- and initiating the actual test does involve choosing "New Test..." from the menu and filling in a dialog with (even fictitious) name, DOB, and level of education.

Of course, I'm pleased to show it off, but I'm very reluctant to accept such a favor when I really should be doing the right thing by just getting a Windows PC to troubleshoot it myself. Still, here's a download link:

https://newpsyc.com/NewCat_Win_v1.20.msi

jeff k

[richmond62]

This reply of mine has NOTHING to do with the supposed problem with Windows.

But it has a lot to do with a feeling that something might be overly complicated.
-

[jacque]

I'll have to figure out where to insert his "command initKey" that clears the decks for a new item -- which, unlike "on so-and-so" and "function so-and-so", is something new to me.

The "command" keyword is a synonym for "on" at present, it was introduced as a developer aid to distinguish between system messages and private ones. You can swap the two keywords without any negative effects.

[SparkOut]

I'm not sure what to have expected but I downloaded your .msi file (after firstly having the site blocked by Malwarebytes, and then Windows Defender blocking the download and then on installing the digital signature was not trusted and then Avast! blocked it from installing and then after installing Avast! blocked it from running) and ran the test (at least the available two stages).

Malwarebytes warning

I tried a few different things to test the keyboard responsiveness, mostly just pressing the number key 1-4 and legitimately completing the test.
When I tried a very quick (correct) keypress it sometimes failed to respond and needed just a little longer to register that I had selected a choice.
When I tried simulating a trembly press and rapidly made repeat depressions of the key, it "somewhat successfully" prevented progressing to the next slide, and if I then let the key up without further presses, the feedback was displayed correctly. There *were* times that I was busy pecking the key and it progressed anyway.
If I pressed an incorrect key (a letter, for instance) and let go, that response was ignored and the slide waited for a valid keypress in the range 1-4 OK.
If I held down multiple keys (1-4 and other invalid keys) then let the rest go but maintained keypress to have only the correct key down, then released, I got "wrong" feedback.
If I quickly held down a key while the feedback was being displayed, the test moved onto the next slide and maintained the keypress so that when I let go and changed to the correct key, the answer was recorded as incorrect.

[stam]

If I’ve understood correctly then, this isn’t an issue with the emulator? Sounds similar like what Jeff was describing using Parallels?

[jacque]

I just wrote a very short script that seems to do what you want, but given the amount of discussion here I may be missing something. If you could post your 2-card test stack I could implement my script and see if it works. I don't have a Windows machine but the script is so short that I expect it should work even in an emulator.

[jmk_phd]

SparkOut –

I apologize for the download problem. I did try it myself before posting the link for you and got only the typical “isn’t commonly downloaded” warning (because either the file or the newly-renewed Sectigo certificate hasn’t yet earned “reputation”).

In any case, you anticipated every variation on keypress behavior that I could’ve hoped you would try. I am grateful beyond words for your time and effort.

As regards your findings:
(1) The misbehavior you report is very similar to what prompted me back in May/June to post the question (in the Beginners forum) about trapping keypress messages, which ultimately led me to scrap keyUp in favor of the keysDown() strategy that proved to work flawlessly when run on a Mac.
(2) That you ran the Windows standalone on a PC apparently lets the Parallels emulator off the hook.
(3) I’d always simply trusted that if a LC standalone worked as expected on the macOS platform, the corresponding build for Windows would work just as well – essentially shifting responsibility onto LC to ensure that this is the case. A sober reminder that it is my responsibility as a programmer to confirm that any cross-platform app intended for publication be tested natively on the corresponding hardware.
(4) Obviously, the keysDown() strategy needs to be scrapped in favor of something along the lines of Stam’s recent example. Although various similar suggestions proposed in reply to my previous May/June thread failed one or more of the tests that SparkOut just tried, perhaps some difference in Stam’s straightforward code – perhaps his “initKey” command – is the “secret sauce.”

Of course I will report back. Although the actual code must handle various conditions not present in Stam’s “proof of concept” model, I don’t think that it will be too difficult to implement – and I will test it out first.

Thanks again to SparkOut and Stam and everyone.

jeff k

P.S. @stam -- Yes, as mentioned above, the problem is apparently with the Windows standalone, and not with Parallels.

@jacque -- Thanks for your kind offer (and for your valuable replies both to this and to the previous May/June thread), but I recommend wait-and-see until I've tried implementing some version of Stam's code.

[jacque]

My script is very similar to stam's so you're in good hands.

[jmk_phd]

No surprise (to me) that a first attempt to substitute keyUp for keysDown failed: Not because I expect a problem with the keyUp strategy, but only because the script requires processing more than just whether a keypress was "correct." So I 've already anticipated that more experimenting and tweaking of the code is needed to get it right. (BTW, the test items are all displayed on a single card -- only the SVG image and designated correct response change from item to item -- which possibly complicates employing the keyUp command in the card script.)

Apart from that, revisiting the LC dictionary entry for keyUp reminded me of the following comment at the end:

"Cross-platform note: On Mac OS systems, the keyUp message is sent after any keyDown handlers finish executing, whether or not the key has been released. On Unix and Windows systems, the keyUp message is sent when the key is released.... To test whether a key is actually being pressed, use the keysDown function."

As I recall, this -- somewhat cryptic -- qualification was in part what tipped the balance back in June to adopt Craig's keysDown() strategy.

Here's the thing: The Mac standalone employing keysDown() has been confirmed repeatedly to work *flawlessly* by me and a few other Mac users, even as SparkOut has confirmed convincingly that the Windows standalone does not.

While utterly speculative at this point, I'm open to consider branching the code to accomodate both Mac and Win platforms -- keysDown() for Mac and keyUp for Windows. Still, this seems like skating on thin ice, potentially vulnerable to any change in a future version of LC.

jeff k

[stam]

Hi Jeff, I can’t see the real effect of this on Mac, but may be wrong.
Also haven’t tested to see if differences on Win.
But even so, why not detect if answer correct or not on on keyDown, blocking further meyDown messages as in my previous example and act on keyUp?

To me it seems unlikely that two codebases will be needed for this…

S.

[jmk_phd]

Hi everyone –
Sorry for the delay in posting an update, but I wanted to be sure that I had something to report worth reading.
I began by returning to the original May/June thread (https://forums.livecode.com/viewtopic.php?f=7&t=37044) in which I first raised the problem of trapping keypresses. At the time I’d been employing the conventional keyUp strategy and even mentioned setting a “flag” – which Craig noted was an “old-fashioned” programming term – to prevent registering multiple keypresses, but which is reminiscent of the initKey check that Stam recently recommended to accomplish the same.
Forum members offered many generous suggestions such as inserting at various points a “wait” or “flushEvents()” – and then of course the more controversial “keysDown()” alternative.
One important lesson learned from that discussion is the value of creating a bare-bones “proof of concept” script, shorn of any complexities that might inadvertently cause it to fail.
So I created a simple stack with two cards – one with a script employing the keysDown() strategy and the other employing keyUp. Tested each script in the IDE, then built standalones for macOS and to test (via Parallels emulation) in Windows.
Unlike my actual app that employed keysDown() – which failed for me running Windows via Parallels and for SparkOut on a Windows PC – the proof-of-concept keysDown() script worked fine on all counts, whether run in the IDE or as either a Mac or (via Parallels) Windows standalone:
(1) a typical keypress registered correctly;
(2) an invalid keypress (not keys 1-4) was ignored;
(3) an overly-long keypress did not affect the results; and
(4) a quick multiple keypress did not affect subsequent items.
However, the script employing keyUp failed as regards #4, irrespective of the environment or platform.
This failure may very well be due to a flaw or oversight in how I implemented keyUp in the script – which I found not quite as simple as including a function such as keysDown() – but I’ve had no success in tweaking the script using the suggestions proposed back in the May/June thread.
So here’s the code just for the keyUp version, along with a .zipped file with the two-card “proof-of-concept” LC stack. (The stack includes a simple dropdown menu to simplify switching between cards and quitting a standalone.)

Code: Select all

constant kItemList = "A,B,AB,ABAB,ABA,A,BBB,AA" -- list of test items
constant kAnswerList = "1,1,2,4,3,1,3,2" -- list of correct test answers
constant kValidKeys = "1,2,3,4" -- list of valid response keys
local sTestLength -- number of items on the test
local sCorrectAnswer -- correct answer for a given item
local sChosenKey -- chosen response to a given item
local sTotalScore -- running total of correct responses

on doPerformTest
   -- (1) Initialize the test
   doPrepTest
   -- (2) Show each test item in turn
   repeat with x = 1 to sTestLength
      -- (2a) Display this test item
      doShowItem x
      -- (2b) wait for a valid keyUp message
      wait until sChosenKey is not empty with messages
      -- (2c) check whether response was correct & give feedback
      doCheckResponse
   end repeat
   -- (3) Display final result
   doConcludeTest
end doPerformTest

on doPrepTest -- (1) Initialize the test
   put the number of items of kItemList into sTestLength -- number of items (x)
   put empty into field "ItemField" -- field that displays the item
   put empty into field "ItemNumberField" -- field that displays item number
   put empty into field "FeedbackField" -- field that displays feedback
   put empty into sChosenKey -- initialize flag to block repeated key input
   put 0 into sTotalScore -- running total of correct responses
end doPrepTest

on doShowItem pItemNumber -- (2a) Display test item
   -- parameter is the item number (x) to display and check
   lock screen
   put item pItemNumber of kItemList into field "ItemField" -- item to display
   put item pItemNumber of kAnswerList into sCorrectAnswer -- store correct answer
   put pItemNumber into field "ItemNumberField" -- just to ID which item is current
   put empty into sChosenKey -- initialize var to hold first valid response
   unlock screen
end doShowItem

on keyUp pKeyName -- (2b) Monitor for a valid keypress
   /* -- Note: this fails to prevent multiple keypresses
   local tEventDump
   put flushEvents("all") into tEventDump
   */
   switch
      case sChosenKey is not empty -- a previous valid keyUp occurred
         exit keyUp -- so don't allow any change
         break
      case pKeyName is not in kValidKeys -- i.e., not 1-2-3-4
         put empty into sChosenKey -- so this doesn't trigger response check
         exit keyUp
         break
      default -- this is the response to check
         put pKeyName into sChosenKey
         break
   end switch
end keyUp

on doCheckResponse -- (2c) Check response & show feedback
   if sChosenKey = sCorrectAnswer then
      put "Right" into field "FeedbackField"
      add 1 to sTotalScore
   else
      put "Wrong" into field "FeedbackField"
   end if
   wait 1 seconds -- allow user to read feedback
   put empty into field "FeedbackField"
end doCheckResponse

on doConcludeTest -- (3) Display final result
   put empty into field "ItemField"
   put empty into field "ItemNumberField"
   put sTotalScore && "correct out of" && sTestLength into field "FeedbackField"
   wait 1 seconds -- allow user to read result
   put empty into field "FeedbackField"
end doConcludeTest

KeyTrials_9-14.livecode.zip

(3.92 KiB) Downloaded 93 times

Thanks as always for your help.
jeff k

[jacque]

I haven't tried your script yet but I vaguely recall that flushEvents("all") isn't reliable. Since you only need to clear key presses, try flushEvents("keyUp") instead.