Old standalones work, IDE versions don't

[jmk_phd]

After a year spent developing a LC app for a colleague, I've returned to completing my own LC app. The problem is that a crucial routine -- identifying and processing a keypress -- no longer works in the IDE.

Here's the thing: Whereas each earlier standalone still runs just fine, the LC code file upon which it was based -- time-stamped as having been saved when the standalone was built -- no longer respond to the keypress routine when run in the IDE. I'm *sure* that the code worked fine in the IDE when the standalone was built.

I'm currently using LC Indy 8.1.9 (because I'm still running macOS 10.6.. I've attempted to run LC code files going back to versions of my app as far back as 2016 without success, even though the few corresponding standalones archived from that period do in fact work.

Although I've not figured out how to revert to previous versions of LC Indy, I did have on hand a copy of LiveCode Community 8.1.4 (June 2017), which probably was current when the most recent standalone that I have on hand was created. Again, whereas the standalone works, the LC code file from which it was generated does not when run in that Community version.

I'm hard-pressed to attribute the problem to version changes in LC, and utterly perplexed and frustrated to find a solution.

Any help would be much appreciated because I was hoping to make my app available to students in time for the fall semester.

Thanks, jeff

[dunbarx]

Hi.

I cannot see how the IDE stack can not work, but its standalone can.

Anyway, how are you handling that keyPress? RawkeyDown(up)? If so, are you sure you are passing that message to the engine after you are finished with it?

Craig Newman

[jacque]

A standalone built with an older engine will run because the compatible engine is embedded in it. When the stack is opened in a newer engine, any incompatibilities will show up in the IDE.

There have been very major changes in how text is processed, starting with LC 7. It would help to see the part of the script that is failing so we can identify where the incompatibility occurs. How does it identify and process keypresses?

You can download older engines here if you need to: http://downloads.livecode.com/

[dunbarx]

Ah,

What Jacque said.

I did not put together that you were using opening old stack in a new version of LC.

Craig

[jmk_phd]

Jacque --

As Craig noted, your explanation -- that an old standalone might still work because the contemporaneous engine had been embedded, whereas the same source stack file might fail when run in a newer (incompatible) version of the IDE engine -- makes perfect sense.

I was hoping that this would be the key to the solution, but I've reactivated my Indy licenses for 7.1.3 (when I began the project) and 8.1.6 (the last version used to create a standalone). Using either version, the stack files still fail to run as these had done previously.

Inasmuch as the keyUp routine worked fine in the past, I doubt that this is the source of the problem.

My only clue right now is that currently when I press a key, a stack script appears with that key value inserted into some odd position in the displayed script. Apparently, the stack displayed on screen is no longer the target of the keyUp message. Why this worked once, but is no longer the case, remains a mystery.

If I do click first on the image displayed on screen -- which I assume sets this as the target -- a keyUp is indeed recognized, and all seems okay. Why this is a problem now but not before is truly perplexing.

I will continue to investigate and will report back what I learn.

Thanks! jeff k

[dunbarx]

Can you set a breakpoint in the keyUp handler, and then see what object holds the script? It will be listed at the top of the SE. You can then insert another line asking for the topStack.

Craig

[jacque]

The defaultstack will receive the key press. It sounds like a script is open and is the current defaultstack. Are all scripts closed when you test it? If so, and a script opens spontaneously, what is the name of the script's stack in the title bar?

[jmk_phd]

Craig and Jacque --

Thanks so much for your feedback. I'm sure you're both right that the problem involves the message path (ignoring for now why this was never a problem in the IDE or standalones from a year ago).

In brief, here's the situation: The test displays an answer dialog to ask whether to begin the first subtest. If the user clicks "OK" the first test image is displayed in the frontmost window (card 2 of the mainstack, in which the script is located). However, there is no response to a keypress unless I first click on that window. Upon doing that one-time click, the app responds appropriately until the end of the series of images that constitute the subtest. Each time a new dialog to begin the next subtest is displayed, I must again click on that window once before a keypress will register.

Per Craig's suggestion, I've set a breakpoint in the keyUp handler. It's not triggered unless I've already done a click on the frontmost window. (Similarly, I've inserted a "beep" in that handler, which isn't triggered either unless the foremost window has been clicked.)

Although I hate inserting kludges to work around bad programming, I did try sending a "mouseUp" to the frontmost window in order to simulate an actual click. It didn't work.

Per Jacque's suggestions, I've used the message box to identify the current defaultStack and target while running the app. As intended, the defaultStack is the main stack and the the target is card 2 of that stack (in which the relevent handlers are located). One surprise is that after using the message box to check these properties, I must again click the frontmost window in order to resume registering keyUp events. (As noted above, one click on the front window after a new subtest alert is displayed is otherwise sufficient to enable the keyUp routine.)

I will continue to experiment with modifications to the code in order to make this work, but any and all insights are appreciated.

Thanks.

jeff k

[jacque]

The message box sets the defaultstack to the topstack, so that may not be the best way to find out. It sounds like the defaultstack is either still the dialog (could be a bug) or is being directed to one of the IDE stacks or elsewhere.

You may be able to work around it by adding an instruction just before you show the first image. If the script is in the card:

Code: Select all

set the defaultstack to the owner of me

Adjust as needed to specify the stack reference.

[dunbarx]

This raises an interesting point.

How can we find out the defaultStack in a running handler, especially where the dynamicPaths might be true?

And might this be an issue here?

Anyway, would it always be as simple as inserting a line:

Code: Select all

put the owner of this card into tCurrentDefaultStack

Craig

[jacque]

I'm not sure that's much different from just "get the defaultstack". Or for a boolean, maybe "get the defaultstack is the topstack".

[dunbarx]

Jacque.

Been a long time since I had to think about the dynamic path, but isn't is so that if one navigates to another stack with the dynamicPaths "true", the defaultStack (the "current" stack) may not be the "originating" stack"?

Because, when on that remote card, the overall message path is modified, enhanced with that new card.

Not sure I said that well.

Craig

[jacque]

It's not just the dynamic path, any "go" command is supposed to update the defaultstack. The exceptions depend on the mode of the target stack.

[jmk_phd]

Jacque and Craig --

Thanks so much for your replies. I've tried inserting a "set the defaultStack..." at various points in the script, none of which has enabled the app to perform properly as it had done a year or so ago. (It's currently still necessary to click once on the frontStack with the displayed image before keyUp messages are recognized. The same must be done once after each subsequent answer dialog is displayed.)

Taking a hint from Jacque's long-shot speculation that there might be a bug in the "answer" dialog, I'll try substituting a mock "answer" dialog by adding to the frontStack card items that can be shown/hidden in place of the built-in "answer" dialog. My hope is that because these belong to the frontStack, clicking on an embedded button will identify this as the defaultStack.

I'm at wits end, poking around in the dark, but will report in a day or so whether this strategy works. It's so disheartening that my code used to work just fine a year or so ago.

jeff k

[jacque]

Immediately after an answer command, try adding these lines to the handler:

Code: Select all

toplevel the owner of me
set the defaultstack to the owner of me

This again assumes the script is in the card. If you can post a relevant handler that includes an answer command, we might spot something.