Function called, doesn't answer!

[RossG]

I have a function which should run when the condition
is fulfilled i.e. sCount > 29.

For some reason it isn't called even though the condition is true.

Other functions called with the same condition do run as expected.

Any possible reason? I've checked all the usual things e.g. sCount is
global, function name OK etc. A break point set at this call doesn't cause a break.

[Ormente]

Ross, could you share your stack, or at least enough code for us to understand what's happening?

[RossG]

Ross, could you share your stack, or at least enough code for us to understand what's happening?

Thanks for your offer of help.
The code is "commercially sensitive" but if the problem
persists I'll make a clone without the real code.

Since I posted above I tried to find the problem by
re-organizing the calling order of the functions.
It worked - for a while until suddenly the calls to
several functions don't get processed.

One thing that makes it hard to find a coding error...
I'd changed some field names in one function which didn't
get called. It was almost as if the de-bugger (if it could
talk) was saying "Been there, it won't work. Why bother
going there again".

As they say "Even paranoids have enemies". Think I'm
getting close to thinking of the de-bugger as my enemy.

I'll try it all on my other computer just in case.

[Ormente]

I understand.

You said the test is true... but have you actualy put a breakpoint at the test site to be sure the result is as expected?
Have you tried to put other function call before and after the elusive function, in the same block "under" the test?

You certainly have a lot more experience that me here, since i'm a newbie, but are you sure the function "that should run" is reachable from the call site?
Have you tried to call it "by hand"?

in such situation, there is mainly 3 possible causes of trouble:
- the test don't yield what you think it should
- the function call fails
- the function execution fails (this you have ruled out allready)

That's not much but i hope it helps.

[dunbarx]

Ormente does not sound much like a newbie.

His advice is sound. I will bet that the problem is some glitch in the code. Tracking this down is, just like he said, a matter of detective work, and breakpoints, examining intermediate results, naming issues, numbering issues, checking the precision of strings that may not be exactly as you wish, or are required to have, etc.

I bet you 10 lines of code you will find the enemy in your handler.

Craig Newman

[FourthWorld]

This may help. It may not help. It depends on the specifics of your circumstance. For me, being able to see a detailed calling chain in near-real time has so frequently been so much more useful than a debugger that I only ever use the debugger maybe twice a year. Your mileage may vary. Hope it helps.
http://fourthworld.net/revnet/devolutio ... ivecode.gz

[RossG]

This may help. It may not help. It depends on the specifics of your circumstance. For me, being able to see a detailed calling chain in near-real time has so frequently been so much more useful than a debugger that I only ever use the debugger maybe twice a year. Your mileage may vary. Hope it helps.
http://fourthworld.net/revnet/devolutio ... ivecode.gz

Richard

Thanks for the advice and link.

Unfortunately I have the same problem as with your previous
stack that the font is sort of Chinese and unreadable.

As I mentioned previously I recall that this problem was
discussed but don't know if there is a fix.

Win XP (for ever).

Update: Of course the fix is simple - change the stack font
from Lucida ?? to Tahoma.

Look forward to finding this wretched bug.

[RossG]

This is the code which calls the functions:

Code: Select all

  if sCount > 29 then
     get nRed(aNumber)
     get nBlack(aNumber)
     get nHigh(aNumber)
     get nLow(aNumber)
     get nOdd(aNumber)
     get nEven(aNumber)
     get nRowThree(aNumber)
     get nRowTwo(aNumber)
     get nRowOne(aNumber)
     get nDozenOne(aNumber)
     get nDozenTwo(aNumber)
     get nDozenThree(aNumber)
     get WayBack(aNumber)
     get HowMany30(aNumber)
     get WayBack2(aNumber)
  end if

WayBack is the last function that runs.
The last two don't.
WayBack is the last one which shows in
Flight Recorder.
Makes it hard to de-bug doesn't it?

[Ormente]

Yes, it looks weird

So, the test is not the problem... now, what do we have left?

I suspect the call order of these functions is important and you're relying on side effects, but :
- do the 2 last functions gets called if you put them higher on the list ?
- do they get called if you comment the "get WayBack(aNumber)" line ?
- what is the action of WayBack(), since he is the last having seen the victim alive ?

@Richard: your Flight Recorder looks amazing. I just had a quick look at it yesterday, but i'll try to learn more from it today, and get a better understanding of livecode in the process.

[FourthWorld]

Unfortunately I have the same problem as with your previous
stack that the font is sort of Chinese and unreadable.

As I mentioned previously I recall that this problem was
discussed but don't know if there is a fix.

Win XP (for ever).

Windows XP was EOL'd years ago. The only people writing new code for it are organized crime rings. Microsoft considers it too dangerous to use, so I no longer have any XP installs on metal here to test with. I can see if I can resurrect a backup of an old VM to try to reproduce that when I get some time.

Update: Of course the fix is simple - change the stack font
from Lucida ?? to Tahoma.

That's encouraging. It'll throw the fonts off elsewhere, but at least we have a quick fix available if we run into anyone else developing on XP.

Look forward to finding this wretched bug.

Do you see this on supported versions of Windows?

[FourthWorld]

@Richard: your Flight Recorder looks amazing. I just had a quick look at it yesterday, but i'll try to learn more from it today, and get a better understanding of livecode in the process.

Thanks for the kind words. Keep me posted if you find any issues with it on supported OS versions.

[mwieder]

RossG-

If WayBack() is the last function you see called then the problem is probably in there.

And yes, the built-in debugger has its own set of problems (see PowerDebug in my sig).
Urk - I see that link is wrong: try http://ahsoftware.net/PowerTools/PowerDebug.lc
When you say the breakpoint isn't triggered, I'm not clear on where you're placing it.
If it's in a section of code that isn't actually getting executed then it won't get triggered.
If you're using the script editor's red dot to place a breakpoint, it might or might not.
If you're inserting a breakpoint command into the code, it *should* always get triggered.

You might try putting the whole thing in a try/catch construct and see what happens.
Or just the WayBack() call in a try/catch construct.

[RossG]

The culprit has been unmasked!

In function "HowMany30" I had coded

repeat with x = -1 to -30

which should have been (obviously to you but not to me)

repeat with x = -1 down to -30.

How this caused the effect it did will remain a mystery.
But what would life be without a few mysteries?

Thanks to all who helped.

[mwieder]

RossG-

Aha! Glad you found it.
I *think* what's happening there is that since you are counting up instead of down, the count sequence goes
-1
0
1
2
3
4
...
until you reach the largest signed integer LiveCode can handle, and then it wraps around.
If you wait long enough and finally wrap around to the unsigned-integer representation or -30 it might continue.
Probably, though, you will get tired of waiting long before that happens.

[RossG]

RossG-

Aha! Glad you found it.
I *think* what's happening there is that since you are counting up instead of down, the count sequence goes
-1
0
1
2
3
4
...
until you reach the largest signed integer LiveCode can handle, and then it wraps around.
If you wait long enough and finally wrap around to the unsigned-integer representation or -30 it might continue.
Probably, though, you will get tired of waiting long before that happens.

Oh dear. Here I was thinking that my programming had become so sophisticated that
it had outstripped the capabilities of the debugger.

Oh well, just have to keep trying.