Handler is being ignored: Why?

[Peter Haworth]

I've seen similar issues when the backscript flags a runtime error of some
sort, perhaps because arg1 or arg2 contains an unexpected value.

I would try putting the thatcommand handler into the same script as the
thiscommand handler then stepping into it to see what happens.

Pete
lcSQL Software
On May 23, 2014 9:21 PM, "Paul Dupuis" <paul at researchware.com> wrote:

> Devin,
>
> Thanks for the idea. I suppose it is possible there is a problem with
> the load of the backscript, however, other handlers in that specific
> backscript are available and work. We've been loading external stacks
> for some time succesfully as both library stacks or external stacks that
> have behaviors or both
>
>   put AppPath()&"Components/docQT.livecode" into tStack
>   if (there is a stack tStack) then
>     -- start using tStack -- if you want to load it as a library stack:
> remember 'libraryStack' and 'releaseStack' messages
>     if there is a button "PluginFrontScript" of cd 1 of stack tStack then
>       insert script of btn "PluginFrontScript" of cd 1 of stack tStack
> into front
>     end if
>     if there is a button "PluginBackScript" of cd 1 of stack tStack then
>       insert script of btn "PluginBackScript" of cd 1 of stack tStack
> into back
>     end if
>     dispatch "InitPlugin" to stack tStack -- may or may not be used, if
> not, it passes back to stub handler
>   else
>     answer "COMPONENTS ERROR: Failed to load Media Source Library."
>     quit
>   end if
>
> To date, we've had not problem with this model, but obviously, something
> has changed. I am stuck on why the IDE debugger would step over a
> handler when clicking the "Step into next statement (F11)" button.
>
>
>
> On 5/23/2014 4:00 PM, Devin Asay wrote:
> > Paul,
> >
> > Could it be that the ids of the controls in your backscripts stacks are
> not resolving properly? This causes problems with behaviors that are stored
> in other stacks. See http://quality.runrev.com/show_bug.cgi?id=8993
> >
> > Devin
> >
> >
> > 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
> >> back
> >>  -- 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
> >> "thatCommand"?
> >>
> >> _______________________________________________
> >> use-livecode mailing list
> >> use-livecode at lists.runrev.com
> >> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> >> http://lists.runrev.com/mailman/listinfo/use-livecode
> > Devin Asay
> > Office of Digital Humanities
> > Brigham Young University
> >
> >
> > _______________________________________________
> > use-livecode mailing list
> > use-livecode at lists.runrev.com
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
>
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>