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" <p...@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 <p...@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@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@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
