I have an applescript applet that talks to back & forth with a liveCode stack.
It works fine running with the IDE but breaks after being saved as a standalone and redirecting the do script scriptText to the standalone.app. It does however respond to the normal system wide default AppleScript commands (open & quit). Going in the other direction works fine, I can execute scripts in the AppleScript applet from the LiveCode standalone with do as applescript. It seems Apple's Script Editor does not see "do script" as valid for the standalone, but it compiles fine when pointed at the LC IDE.
I know this has broken in the past, could it be broken again? Is the (rather sparse LC) AS dictionary not being copied to the standalone?

Hmm, may have been related to trying to do a custom signature / info.plist for my app (because I wanted this app to run in the background and not show in the Dock)
OSAScriptingDefinition & key TestStack.sdef was missing from the Standalone .app's info.plist, once I added that the script compiled in Apple's Script editor... still didn't work, then I rebuilt the standalone and now it's working as expected.
Was pulling what's left of my hair out for a day on that one! Shwew!

That should have been fixed. What version are you using? I’ll dig up the PR and check that nothing has changed.
----
Edit:

Just checked... in DP11 the .sdef file is in the standalone app but is getting stripped out for some reason. The .plist file is also missing the key needed to reference the file. The first key is already there, but the second needs to be added. If you don't specify a .sdef file or specify one that is missing, then you get no dictionary support. The app can still respond to events, you just need to dispatch them using the special code (I'd have to look up the specifics, but I think they are here in the forums).

I finally read your second post correctly... Yes, defining a custom plist could cause an issue. What you need to ensure is present are the keys listed above. And also that the terminology.sdef file is located in the Resources folder which is in the same spot as the plist in the app (App/Contents/Resources).

Yes I had already had those files in my resources folder, updated to match the binaries name, and the keys set correctly in the plist (plus extra keys I added)

I don't know what it was but Apples Script Editor wasn't seeing it as valid keywords and refused to compile "do script" for the script that pointed to my standalone stack on the AppleScript side, but did recognize them for the "tell" scripts that pointed to the IDE/Stack. Perhaps it was because I was editing those files after building the standalone? I pointed the standalone settings to my edited .plist, rebuilt, and it's all good now!

I'm doing some pretty fun / hairy experiments, mixing LiveCodeScript, AppleScript and Cocoa-AppleScript (AppleScriptObjC). Somehow I missed it when AppleScript became that powerful, why didn't anyone tell me!
I'm building a customizable NSStatusMenu Cocoa-AppleScript that communicates with my stack.app that's embedded in it's bundle. Already hit some gotcha's though where an AppleScript triggers a LCS Script that triggers another AppleScript... aaaaand CRASH! Fun!

I wish the "do as AppleScript" in LC supported scripts with cocoa-AppleScriptObjC mixed in, it doesn't seem to work (which is why my project is really 2 Apps that appear to be one, working together in the background). I see that SuperCard recently added an AppleScript() function that can handle cocoa infused scripts. It would be awesome if LC could do that, or just update existing capabilities...but working full-on on LiveCode Builder is probably better for LiveCode's future anyway.

By the way you might be able to get it to work without the plist edit & .sdef file by using the raw Apple Event code for "doScript" in the standalone, which is «event miscdosc» . It seems doing this bypasses the Script Editors checking for it.

Hello from France
I come here after using LC 6.6.2 to compile a little app that only needs to do one thing when launching the runtime, aka running a 5 lines AppleScript (from a field) to mount a distant FTP server and quit, and i see that this bug is not corrected since version 7 !
Of course the scripts runs fine in the IDE, but nothing happens in the runtime compiled with LC Indy 9.0.0
In LC 6.6.2, no problem, expected that the runtime is 32 bits, and i need a 64 bits to be used in HighSierra and above.
I've tried adding the "terminology.sdef" in the Resources folder of the runtime, and adding the Sripting definition file name in the Info.plist of the runtime, without success.
I abandoned LC for FileMaker because lots of things where not working, and i see years later that in fact LC is still very buggy, and this is really despairing because as a long term user of HyperCard, i prefer the OOP model of LC than FileMaker.

I don’t think this is a bug. Allowing arbitrary script execution in any stand alone built with LiveCode is a potential security issue. The IDE does support responding to Apple events.

I’m a little unclear as to what you are trying to do though. This issue has nothing to do with an app being able to issue AppleScript commands. It only impacted the ability of an app to respond to them.

My problem is simple: i can compile my AppleScript to a classical app with Apple Script Editor, but even using the "execute only", the script can be partially read because it is not correctly encrypted.
So the idea is to use LC to run this script during the "startup" handler placed in the stack script, and quit immediately. Exactly the same way as the AppleScript app.
But what can be done in less than a minute using the Apple script editor and works perfectly using LC 6.6.2 is impossible to do since LC 7.

create a mainstack and paste this in the stack script, run it in the IDE, and it works.
Next compile the runtime and constate that nothing happens (even with all inclusions for Mac)

OMG, using a sub-script works in the runtime, even without the pMode param.
"Mille fois merci" like we say in France, Many thanks, you saved my journey !
But WTH why using a sub-script and not a simple script, mystery…

OMG, using a sub-script works in the runtime, even without the pMode param.
...But WTH why using a sub-script and not a simple script, mystery…

It is indeed a mystery, since I didn't use a subscript (handler) when I was testing this. Brian is very much more thorough than I though.

This is OSX 10.6.5,, Lc v8.1.9, highest I had available to test in. I had no problem invoking the test script as you laid it out, see for yourself.

As you can clearly see, no subscript (handlers) were required other than the defaults, and obviously you can do this in the latest Lc versions, not just 6.x (although I use that series a LOT so I don't blame others for doing so)

Oh, I knew that Brian
Here was my take on what he was saying, and why my post reads as it does -

ekami starts off with "It is a bug"
- I really doubt, much like you, that it is a bug per se, however, even if I were inclined to believe it is a bug, I think I'd do a bit more testing and ask opinions before declaring it so... um... rudely I guess. I mostly passed on pointing that out, since english isn't his native language, but I still think it was premature at best.

Runs in IDE but not standalone
- could be a ton of reasons for this, I didn't find one.

Because your code had one, ekami has (I believe) the mistaken impression you need a sub-handler to get it to work.
- I didn't think a sub-handler was required, I was testing my theory, the button is just something that makes it easily repeatable is all.

Complimenting you on being more thorough than I
- Well, it is true, why not say it

Hope that clarifies the "whys", I could be completely off on some or all of my assumptions, no mice were harmed in the writing of this post, blah blah blah

*Edit - I was wrong on one of my assumptions, the startUp or preOpenStack as you pointed out would require the sub handler to be written. I'm still testing through the others, but that is for later.

*Edit 2 - corrected point one and three for clarity, Paul's post that started the thread was not the intended reference.

Last edited by bogs on Fri Apr 27, 2018 3:29 am, edited 1 time in total.