Windows via Parallels quirk?

Deploying to Windows? Utilizing VB Script execution? This is the place to ask Windows-specific questions.

Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller

stam
Posts: 1521
Joined: Sun Jun 04, 2006 9:39 pm
Location: London, UK

Re: Windows via Parallels quirk?

Post by stam » Fri Sep 16, 2022 2:49 pm

Hi Jeff, re: your concern about differing behaviour between mac and win.

I tried to post this a few days ago but my code contained the string "cmd./.ctrl" (without the dots), and the forum kept failing telling me it couldn't find the page every time I tried to post!. It turns out when you include this string (without the dots), it causes the forum to return 404. Who knew... LiveCode support figured it out, but now idea how ;)

I had tried to post this as an example of using combination of keyDown and keyUp handlers, and which would likely obviate the need for flushEvents. This is a modification of my previous stack, maybe it will be helpful. The code registers and processes the key press on keyDown, and responses with user feedback in the keyUp message.

Code: Select all

local sKey -- assigning a value to this makes the stack ignore subsequent key-presses
local sResult -- store the result
constant kAllowedNums = "1,2,3,4"
constant kAllowedControlKeyCombos = "1,2,5"

on keyDown pKeyName
     if sKey is not empty then exit to top -- ensures only 1st keyDown is acted on - until initKey is run
     if pKeyName is in kAllowedNums and commandKey() <> "down" then 
          put pKeyName into sKey -- correct answer
     else if pKeyName is not in kAllowedNums and commandKey() <> "down" then
          put "Wrong answer!" into sKey -- wrong answer
     end if
     pass keyDown
end keyDown

on keyUp pKeyName
     if pKeyName is in kAllowedControlKeyCombos and commandKey() = "down" then -- check for command or control key combos
          put "c-" & pKeyName into sKey
     end if
   -- process result
     if sKey = "Wrong answer!" then -- do stuff if wrong, but in this simple example it's the same action
          put sKey into field "keyPressed"
     else if "-" is in sKey then  --  based on my code this signifies cmd or ctrl-key combo - but in this simple example it's the same action
          put sKey into field "keyPressed"
     else // correct answer
          put sKey into field "keyPressed" -- action on success, would normally call a different handler
     end if
end keyUp

command initKey
     put empty into sKey -- this allow registering next key press
     put "<Nothing>" into field "keyPressed" of me -- reset interface, would normally call a different handler
end initKey
HTH
Stam

-- EDIT: Simon from LC has tracked down the issue with not being able to submit posts with the string "cmd/ctrl" in them to a security resection and he likely can tweak this. Yay ;)

jmk_phd
Posts: 176
Joined: Sat Apr 15, 2017 8:29 pm

Re: Windows via Parallels quirk?

Post by jmk_phd » Sat Sep 17, 2022 1:59 am

Stam (and all) –

Sorry to hear of the frustration it took to post your example code to the forum, but the fix that LC support implemented on your behalf will benefit everyone across this board. Thanks for that!

(1) As regards Win vs. Mac, I mentioned in my last post that when I created a bare-bones “proof of concept” script using the keysDown() strategy, it ran fine in the IDE, as a Mac standalone, and (via Parallels) as a Win standalone. This exonerated both Parallels and Windows itself as the problem. It suggested instead that the problem was not with the keysDown() strategy itself, but with some flaw in my actual fleshed-out app that caused both Win-via-Parallels and native Win – but still very curiously not Mac – to choke. (Obviously, it’s my responsibility to track down how my actual full script differed from this successful bare-bones proof-of-concept script.)

(2) The same success cannot be said of the “proof of concept” variation included in the posted stack that employs keyUp as an alternative. Whether in the IDE, Mac standalone, or Win standalone (via Parallels), this alternative fails because when the same response key is pressed twice in rapid succession – notably, the problem that I first reported back in May/June – the keypress for the currently displayed item registers as accurate, but then immediately causes the following item to be recorded as false even prior to any new keyboard input. (Instead, it displays a faulty result and jumps to display the item after that.) Numerous attempts to include some variation of the suggested keyDown – or, as suggested in the past, to insert some delay before checking the response – have made no difference.

(3) Full disclosure: Although keysDown() does not suffer the same problem as do the keyUp or keyDown/keyUp strategies, all of these fail in one respect: If one presses two valid keys (1-4) simultaneously – one correct and the other not – a difference of microseconds determines which key is recognized as the response. (I’ve not yet figured out how to prevent this probably rare occurrence.)

Finally, in trying to implement the keyUp/keyDown alternatives suggested recently by Stam and back in May/June by other forum members, I may well have erred somehow in adapting these to the requirements of my program. (Can’t use “exit to top” in a keyDown or keyUp, for example, so I use “wait until…” the script variable set therein – used to flag a valid response – is not empty before checking the result.)

Thanks as always for everyone’s help. Still, my best shot at getting this far-behind-schedule app ready seems to be making that disparaged keysDown() work as well as it does cross-platform in the bare-bones proof-of-concept script.

jeff k

jmk_phd
Posts: 176
Joined: Sat Apr 15, 2017 8:29 pm

Re: Windows via Parallels quirk?

Post by jmk_phd » Mon Sep 19, 2022 10:01 pm

I’m pleased (and relieved) to report that the latest rewrite of my app is running without a glitch as a Windows standalone in emulation via Parallels.

Having assumed (wrongly) that if a Mac standalone ran flawlessly, so too would the Windows counterpart, my first guess was that the problem involved Parallels. But when forum member SparkOut kindly tested the Win version on an actual PC and encountered similar problems, this let Parallels off the hook.

With the Win .exe now running fine via Parallels, it’s tempting to assume that it will run without a glitch on an actual PC. But the first lesson learned here is that all such assumptions are dubious, so I must rent a PC to test the new .exe before its publication.

Yes, I am still employing keysDown() to identify the user’s response to the current test item: Despite more than several attempts, the conventional keyUp/keyDown strategy failed to prevent quick successive keypresses from registering as responses to subsequent items.

However, forum members’ suggestions and examples did encourage me to create the simplest possible “proof of concept” script to ensure that its logic was sound, before reinserting into that framework the complicating code needed to handle the various options and procedures.

I did adopt the habit years ago to comment my code scrupulously, but this app has been in development off-and-on for about seven years (or if one counts its ill-fated inception as a Mac-only Prograph app, actually 25 years). So I attribute the apparent success of the current version largely to having rewritten the problem code from the ground up with the benefit of the input, examples, and inspiration of forum members.

Thanks again to all!

jeff k

SparkOut
Posts: 2677
Joined: Sun Sep 23, 2007 4:58 pm

Re: Windows via Parallels quirk?

Post by SparkOut » Tue Sep 20, 2022 7:12 am

I can test the new app on Windows again for you too.

jmk_phd
Posts: 176
Joined: Sat Apr 15, 2017 8:29 pm

Re: Windows via Parallels quirk?

Post by jmk_phd » Tue Sep 20, 2022 9:52 pm

SparkOut --
Thanks for your generous offer. You set us on the right track by documenting that the keypress issue I'd reported initially was not an artifact of emulation via Parallels, but rather that the Windows standalone itself was somehow less responsive than its Mac counterpart built using the previous version of the stack.
Although the new rewrite does run fine via emulation -- and so presumably when the Win standalone is run natively on a PC -- the lesson learned is that this isn't a sure thing until actually tested on a PC. The app includes numerous features that either are not possible or too onerous for you to check (e.g., the copy-protection scheme to register/unlock the full test and the options designed to facilitate its use in research). It's ultimately my responsibility to ensure that these features work cross-platform as intended.
Checking local businesses, I've found that a relatively cheap refurbished Win 10 PC can be purchased for about the same price ($200 US) as renting a high-end (Win 11 compatible) PC for a single month. I assume that even a PC too old to upgrade from 10 to 11 will still be good enough to confirm that the app works as intended.
It's a gamble, of course -- mine is a very niche market, which aims to sell to cash-strapped neuropsyc grad students for < $40 what is otherwise available only from commercial publishers for well over $500 -- but the worst I can imagine is providing an app that does not work as promised.
Best,
jeff k

SparkOut
Posts: 2677
Joined: Sun Sep 23, 2007 4:58 pm

Re: Windows via Parallels quirk?

Post by SparkOut » Wed Sep 21, 2022 7:18 am

Can you ever have too much testing?
It certainly wasn't anything arduous for me, and I'd happily do the same checking as before.

jmk_phd
Posts: 176
Joined: Sat Apr 15, 2017 8:29 pm

Re: Windows via Parallels quirk?

Post by jmk_phd » Thu Sep 22, 2022 12:53 am

@SparkOut --
I truly welcome your experience with this revision. So far the only difference noted between the Mac standalone and the Win standalone via Parallels is a delay in feedback of what seems to me to be a trivial half a second or so, which I'm attributing to extra processing that must be done between keypress and feedback. I've got to code-sign the .exe and create a new .msi installer first -- and hopefully figure out why you got those scary download warnings despite the signing certificate being valid.
Update (9-24-22): New installer available at the same URL as before: https://newpsyc.com/NewCat_Win_v1.20.msi
The location is temporary, as the official subdomain is password-protected until ready to go public. Avast doesn't object to the download. Windows Defender recognized the signing certificate and (obviously) simply cautioned that (for now) it's not commonly downloaded. (I've had to download other apps over a dozen times to gain "reputation.") Yet to try it natively on the refurbished PC laptop bought for that purpose, but it now behaves as intended via Parallels.

@Richmond--
Just ran across your 2016 forum thread "Mapping keyCodes cross-platform" (https://forums.livecode.com/viewtopic.php?t=27649) to which no one apparently responded by posting the maps you'd solicited. Inasmuch as the keysDown() strategy I've employed involves raw keyCodes, these would've been very helpful. (It's surprisingly difficult to find this info via a web search.) Although your Dropbox link no longer works, I grokked the rationale of your "Keyyer" strategy, so it's a simple matter to generate a list of raw keyCodes by simply pressing the keys in sequence:

Code: Select all

local sCode

on rawKeyDown pCode
   put pCode into sCode
end rawKeyDown

on keyUp pKey
   put pKey && "=" && sCode into field "RawKeycode"
   wait 1 seconds
   put field "RawKeyCode" & return after field "KeyListField"
   put empty into field "RawKeycode"
   put empty into sCode
end keyUp

I've done this on my Mac, and (out of necessity) having just purchased an old refurbished Windows PC to test my app natively, I will run this script again upon installing LC for Windows to spot any differences.

@Stam --
A belated thanks for providing your sample scripts. These reminded me of the value of script constants -- once known but over the years forgotten -- which really helped to simplify my code, and for prompting me to rethink how best to include a command-key combination to enable a clinician to terminate a test if/when it's apparent that the client fails to comprehend its requirements.

jeff k

jmk_phd
Posts: 176
Joined: Sat Apr 15, 2017 8:29 pm

Re: Windows via Parallels quirk?

Post by jmk_phd » Wed Sep 28, 2022 3:22 am

First, apologies to SparkOut in case he was awaiting a go-ahead to test the latest Win version of the app. I'd simply edited my previous post, unaware that this would not alert anyone that the update was available.

Anyway, so far the trials I've run on the newly-purchased refurbished Win PC confirm that the latest Win standalone does now perform just as well as did the original Mac standalone. So no longer will I assume that even if the Mac standalone runs fine does this ensure that the same will be true of the Win standalone (whether run natively or in emulation.)

Of course, I suppose this implies also that really I/we ought to be testing even the Mac version with each new version of the macOS, as well as with new versions of Windows.

jeff k

richmond62
Livecode Opensource Backer
Livecode Opensource Backer
Posts: 7762
Joined: Fri Feb 19, 2010 10:17 am
Location: Bulgaria

Re: Windows via Parallels quirk?

Post by richmond62 » Wed Sep 28, 2022 11:57 am

I am sorry I deleted those stacks.

Here they are: https://www.dropbox.com/sh/wjhe94y7fal6 ... G2ETa?dl=0

Post Reply

Return to “Windows”