Handler is being ignored: Why?

[Paul Dupuis]

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
>