Handler is being ignored: Why?

[Paul Dupuis]

Dar,

Thanks. Helpful suggestions.

1) Checking "the frontscripts" and "the backscripts" (by putting them in
the msg) shows only 1 instance of the script of the button in question
inserted.
2) Stepping through the "thisCommand" script line by line executes as
expected right up to the call to "thatCommand" which it steps OVER,
rather than INTO, using the "Step into next statement (F11)" of the
debugger (that's the Weird behavior I have never seen before!)
3) the actual "thatCommand" is a handler called "qtSetSelection" which
set up the properties of a player object for playback of a specific
clip. I don't think that name conflicts with any built in command. There
is certain no such entry in the dictionary. The 2 arguments are the
start and end times of that clip.

This handler has been working for sometime, so obviously, some change
somewhere in the code base recently had broke it. The problem is the
code base is around 100,000 lines of code. Nothing in recent changed
touched either of the specific handlers in question. What was changed
recently was the code that loads various libraries and back (and front)
scripts on startup. Yet, when I look at the "backscripts" the script of
the correct object is present. That was why I asked if the order of
loading backscripts can matters? In fact, by setting breakpoints in
other handlers in backscript in question, i can see that other routine
in the same script (but not qtSetSelection") get called from other
handlers just fine which seems to reenforce that the startup routine is
inserting the script into the backscript correctly.

What has me stumped is why the debugger would step over a handler and
not into it. If the handler doesn't exists in the message path, the
debugger throws an error. If the handler exists, it should step INTO it
and show me the first line of that handler. The only time I think I have
seen such behavior is if "Suppress Messages" has been set in the IDE (or
lockMessages set to true), but I checked lockMessages and it was false
just before the call to qtSetSelection.

> 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
>> 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
>
> _______________________________________________
> 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
>