Handler is being ignored: Why?
dsc at swcp.com
Fri May 23 15:19:56 EDT 2014
Could you have experimented with using front and left an old version there?
Could “do a bunch of stuff” return?
Is “thatCommand” built-in?
On May 23, 2014, at 1:09 PM, Paul Dupuis <paul at researchware.com> wrote:
> I have a command "thisCommand" that calles a 2nd command "thatCommand"
> which is in a btn script inserted as a backscript. So
> on startup
> -- some stuff
> insert script of btn "thatCommandButton" of stack "myBackscripts" into
> -- some more stuff
> end startup
> btn "thatCommandButton" contains
> on thatCommand pArg1, pArg2
> -- some stuff
> answer pArg1 && pArg2
> end thatCommand
> and finally my main script
> on thisCommand
> -- do a bunch of stuff
> thatCommand arg1, arg2
> -- more stuff
> end thisCommand
> The symptom I am running into is that "thisCommand" never calls
> "thatCommand" I can set a breakpoint in the debugger and step line by
> line. When it gets to "thatCommand arg1, arg2" it steps right over it
> (like it was a singel statement rathet than a handler that it should
> step into) instead of INTO it and the command is never invoked. That
> seems to imply that it recognizes that the handler "thatCommand" is
> defined but is not executing it. I have checked to make sure that
> lockMessages is false. I have put the backScripts into msg to verify
> that the script is present in the backscripts. If I replace thatCommand
> with a fake handler name, LC throw a proper handler "not found error"
> Does the order backscripts are inserted matter? thisCommand is actually
> also in a backscript that is inserted BEFORE the script containing
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the Use-livecode