IAC for Livecode standalones

Neville Smythe neville.smythe at optusnet.com.au
Wed Apr 13 22:58:27 EDT 2022


When developing my recent utility I have thought it could be useful if other users could access the output from some of its features, in other words inter-application communication. Stacks can do this if the utility is running in the IDE but not when run as a standalone.

Now a Mac fully-featured app is encouraged to implement AppleScript access. It appears LC has a couple of features for helping to implement AS, (send to program and reply) but implementing AC in an LC standalone still looks to be even more complicated than in Xcode, where it so painful than most apps don’t bother: you have to set up a separate event handler and create the AS dictionary, and the AS  language itself is abstruse to say the least — but how fantastically useful are those apps like Excel which do the implementation well! LC appears to have nothing for VB for Windows and I have no idea how to to do it myself on Windows. And of course there is nothing for Linux (go away and write your own sockets implementation at both ends!!)

How cool would it be if LC standalones could easily talk to each other, at least when running on the same platform, which is where AppleScript and VB live! It certainly is possible, I have done at least one half of it running scripts in an LC app from a shell interface, connecting via sockets; but the learning curve for the coding was high.

[Remote IAC raises knotty problems of implementation (secure login or Html POST?) and heightened security problems - though LC actually already does Remote Debugging which is related but not quite the same as normal IAC usage; for example with Remote Debugging you can run any script remotely unless it is password protected, quite the opposite of what you want IAC access to do. And it only works from the IDE source]

I don’t know if this idea has been raised before, but I reckon all it should need for a very LC-style implementation would be:

In the target app,  expose a handler by simply marking it as public. And preferably provide a manifest describing the usage and input/output.That’s it. No dictionary resource files, no coding.

In the source app I'm guessing one would only have
    Open application “foo” for IAC with credentials “its me"  -> an access id and array of handlers and their manifests
    Dispatch “myhandler” to application “foo” with <parameters> -> the result or error if not handled for timed out
    Close application pAccessId

The engine would handle finding the LC app, connecting to a socket automatically opened on launch if the app has a public handler, getting user authorisation [Allow Always? On Launch? On Request?] and swapping certificates, and then data transfer. I leave this part as an exercise for the reader


Neville




More information about the use-livecode mailing list