Debugging and 'go cd x of stack y'

[Fjord]

Hi,
I'm trying to debug a handler that basically takes parameters 'cdName' and 'stackName'. It does a few controls and eventually if everything is OK, does

Code: Select all

go cd cdName of stack stackName

I'm trying to debug my app and whenever the debugger reaches that instruction the debugger dies and the Livecode goes back to the IDE. I tried setting breakpoints at different places before this instruction. I also tried setting a breakpoint after that instruction but it's never reached.
Is that normal?
(MacOS 11.7.10, LC 9.6.11)

[stam]

Hi,
I'm trying to debug a handler that basically takes parameters 'cdName' and 'stackName'. It does a few controls and eventually if everything is OK, does

Code: Select all

go cd cdName of stack stackName

I'm trying to debug my app and whenever the debugger reaches that instruction the debugger dies and the Livecode goes back to the IDE. I tried setting breakpoints at different places before this instruction. I also tried setting a breakpoint after that instruction but it's never reached.
Is that normal?
(MacOS 11.7.10, LC 9.6.11)

Not quite clear what you're after - from personal experience it's often helpful setting breakpoint in the first line of the handler (or the calling handler) and then stepping through line-by-line to see what's going on...

Alternatively, you should try a Try/Catch block?
You can look it up in the dictionary, but broadly it is of the form:

Code: Select all

try
   <code to try>
catch <errorVariable>
   <code to act on if the try code fails>
end try

[dunbarx]

whenever the debugger reaches that instruction the debugger dies and the Livecode goes back to the IDE.

What? The debugger releases control midstream by itself? It stops, er, debugging and just exits back to the IDE? This should ONLY happen if you press CMD-Y or the "Stop debugging" button at the top of the SE (the blue square button).

I suppose you could pull the plug on your machine as well.

Are we sure the description of what is happening is correct?

Craig

[dunbarx]

Rereading, and with a hint from Stam, how are you entering the debugger in the first place? With a breakpoint (either an explicit line of code or a red dot)?

Craig

[richmond62]

I suppose you could pull the plug on your machine as well.

Time to wag my finger at you: sarcasm: naughty person!

[richmond62]

I just knocked together a stack with 3 cards (erm: I recycled it from an earlier exercise) and gave each card the same dropDown menu:
-

-
All rather difficult why that should crash anything.

Not helped by trying to find the debugger:
-

-

[dunbarx]

Richmond.

What is the relevance of your stack?

The OP is struggling (I think) with peculiar debugger behavior.

Craig

[richmond62]

What is the relevance of your stack?

Initially it was to look at moving to a card in a stack, as per the OP's script.

[Klaus]

Bonjour Francois,

can you please post the complete script?

Maybe there is something else going on, a simple "go cd xyz of stack zxy"
should not crash or something.

Best

Klaus

[jacque]

We need to know the values of cdName and stackName.

[richmond62]

We need to know the values of cdName and stackName

I would assume (dangerous business) that they are the names of cards in stacks that are currently open . . .

Although I wonder if stackName is the name of a stack other than the one in which the code resides whether that won't throw a 'bluey' as cards from another stack cannot be shown in the originating stack's window.

[Klaus]

But he did NOT write:

Code: Select all

go cd x of stack y in window of THIS stack

[dunbarx]

Guys and gals.

How would any of that kick out a running debugger? The worst that could happen is that an error is thrown, and the debugger halts.

I am suspecting that the word "debugger" is not what we think it is.

Craig

[SparkOut]

Inconceivable!

Oh, um. Yes, very conceivable.

Can you

Code: Select all

answer "go cd" && cdName && "of stack" && stackname 

just before the actual "go" statement.

That will show what the command causing the crash looks like and we can go from there.

[jacque]

Guys and gals.

How would any of that kick out a running debugger? The worst that could happen is that an error is thrown, and the debugger halts.

I am suspecting that the word "debugger" is not what we think it is.

I think he means an error occurred that stops the debugger. The reason we need to know the values of the variables is because if he's using anything but the short name, an error will occur when LC tries to parse "stack stack thisStack" or "card card thisCd".