LiveCode Forums.

I have a function which sometimes works and sometimes
doesn't.

The problem is a repeat loop...

repeat with r = 16 to 36.

The error occurs on the first iteration of the loop.

The value of r is somehow changed - to 15 - so the loop
is exited.

This happens even when I add a line before to put 16 into r.

Other functions which have the same code work as expected.

What's up here???????

We won't be able to determine we what's happening in the handler until you post the full handler.

Richard

I've never needed to figure out "handlers".

Can you explain or direct me to an explanation?

Hi RossG,

I've never needed to figure out "handlers".

post your LiveCode script with the while loop

Paolo

Neurox66 wrote:Hi RossG,

I've never needed to figure out "handlers".

post your LiveCode script with the while loop

Paolo

The while loop is OK sometimes.
Usually after the first run it goes wrong.

The first stack I've had which crashes LC and
the stand-alone.

I'll try adding this code to the Explicator stack and
see if it crashes.

Also...
After ten years using LC (from Rev 3) it's occurred to me
that it would be very convenient if, when compiling a stack,
a copy of it was saved with the .exe.

Is there a setting or a way to do this?

Made some progress on this.

the loop...

repeat with x = 16 to min(sCount,36)

Somehow sCount wasn't what it should have been.
Should be between 16 and 200(say).
It was reduced to 2, so naturally the loop failed.

Now I have to find where this change is occurring
which brings me to my next question.

Had a look for info about using the Watch Window but
can't figure out if I can set it up to tell me when sCount
is being changed.

I expect it's possible.

Some clues would really be appreciated.

Ross.

I think it was Richard who said we need to see the entire handler before we have any hope at all of helping you.

He was correct.

Craig Newman

Would still like to know how I can watch a variable
so that the stack stops when it changes as I now
have an array which "disappears" at some point
after it's been initialized.

A fairly usual facility in all the programming languages
I've used.

Ross.

What does stepping through each line of a handler in the debugger not do for you? Breakpoints, soft or hard, or watchpoints for that matter, may be placed anywhere.

Another big advantage and feature of the LC debugger is that array variables are visible as the handler proceeds

Craig

Craig

Tried all the usual but as usual I'd found a new way
to confuse LC.

I'd declared the array as global but when I added it
to the list I'd separated it from the previous global
with a "." instead of a ",". Took a bit of finding
what with these hi-res monitors and low-res eyes.

Must try harder but as usual a post here seemed to
solve it nicely!

Thanks again for your attention.

"Low-res eyes" -- lol. That's me too. I'm stealing that.

Due to advances in display technology the human eye
can't discern any difference between the latest
display resolution and the previous one so in
fact we all have "low-res" eyes now.

Waiting for the bionic eye implant before I
get a new monitor.

RossG wrote:I'd declared the array as global but when I added it
to the list I'd separated it from the previous global
with a "." instead of a ",".

I'd used Andale Mono for years, and many others for years before, and I found that they often made the descending tail on the comma too small to be readily distinguished from a period.

No more. I came across Ubuntu Mono a few years ago, one of the few monospaced fonts that understands its role in coding and makes the comma very easily distinguishable from a period.

The Ubuntu font family is available for free as open source, downloadable here:
http://font.ubuntu.com/