Goodbye stsMLXEditor

Mike Bonner bonnmike at
Mon Aug 31 00:55:39 EDT 2015

The script updates aren't actually being done with revXMLeditor. Set is
never done, its not due to the strict compile error or other errors I don't

If you set an object the a garbage script in the message box, the set
works, even if the script is non-functional.

I think I have the answer.. On osx or linux, adjust your editor settings so
that the process starts in the background. (IE append an & to the end of
the shell command).  shell is blocking, and the watchFilename call happens
AFTER the shell call, once you close the editor.  At which point it tags it
with the new time stamp, and starts monitoring it. Since there is no time
change, the script is never updated to the object, and it stays in
"watched" mode indefinitely.

On windows I had to cheat.  I commented out the watchFilename command that
occurs after the shell call, and added it right before the shell call in
the editor launch script.  While playing, I am simply using notepad.

put  "%s"  into tTmpFile
watchFilename tFilename, tMD5
put quote & "notepad.exe" & quote into tEditor
get shell( tEditor && tTmpFile)

It picks up tFilename just fine from the doEditScript when the "do" is done
but would probably work with tTmpFile too.

The commented out watchFilename is in the doEditScript handler.right near
the end.

  --watchFilename tFilename, tMD5
  log "OPEN:" && the long name of pID
end doEditScript

This still doesn't solve the issue of knowing when variables haven't been
declared, since setting obviously just doesn't do that check, but at least
it makes setting of scripts work.

If appending an & to the command works on linux/osx, let me know.

on windows, I _Think_ you can use "start program.exe" and which will end up
returning control to shell, but i'm not sure any more.  Too long since I've
commandlined in windows.

On Sun, Aug 30, 2015 at 9:13 PM, Kay C Lan <lan.kc.macmail at> wrote:

> On Mon, Aug 31, 2015 at 10:01 AM, Peter Haworth <pete at> wrote:
> >
> > If I get a chance, I will check out the sts plugin code and see if
> changing
> > it to check the result after setting the script fixes it.  Sounds like it
> > will.
> >
> > But then you have a Catch22 - I expect the result will be empty so your
> script will be set - but you still have your strict compilation error. In
> my Recipe stack, once I correct the basic error within the set script
> statement, click btn "one', and then I click on btn 'two' it does what it
> suppose to but if I open btn 'two's script and Apply I get a Compilation
> Error because 'y' was not declared.
> The real question is, how does sts know that there is a compilation error
> which stops it from setting the script, as experienced by you stating that
> your changes are NOT made, but sts doesn't have enough info to post you the
> error - which could be because part of the check also uses the result of
> setting the script but the result is empty so there is nothing to post?
> IMO this seems to be an Engine side problem, not an sts side problem. If
> the 'the result' of setting the script also caught Strict Compilation
> errors, then it would be easier to pass text in and out of scripts and pick
> up syntax errors.
> >
> > While we're talking about script errors, another pet peeve of mine is:
> > compilation stops after finding the first error.  Would really like to
> see
> > all errors flagged in whatever new Script Editor is coming down the pike.
> >
> > Yes, I commented that space taken up by the Errors Tab seems to be a
> waste
> as it only ever reports one error. If ALL syntax errors were reported the
> size of the Errors Tab would seem to be more sensible. Proceeding past the
> first error and continuing to check for more would seem to be a sensible
> enhancement request - it's how my TE works which is another thing I could
> add to my list of why I like my TE over the SE.
> _______________________________________________
> use-livecode mailing list
> use-livecode at
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:

More information about the Use-livecode mailing list