LiveCode Forums.

I would like more detail from the error window. It provides insufficient information to determine race condition errors, therefore I need the option of seeing exactly what millisecond / epoch time that an error actually happens. I would also like it to include a message path trace longer than just the object/variable that caused the error so if I have many of the same functions being called quickly, I know which path caused it.

I am intrigued by your suggestion that a more precise indication of the timing of an error might be helpful. In my experience, it is the sequence of actions, not their timing, that matters.

I have seen the time stamps in the message watcher, but never paid any attention to them. How do you use them to help you find errors?

The best thing about the error pane in the script editor is the ability to double click on an error, and unless the whole offending line is the culprit, the portion of that line that needs looking into is hilited. Do you know about this? But again, it is a stepwise tool, not a timing one.

Craig Newman

You can trace the calling handlers by using the "Execution contexts" popdown button at the top left of the script editor window, next to the step buttons. Handler calls are listed in reverse order with the most recent at the top. Choosing any handler will take you to that part of the script and update the variables to show what they were when the handler was executing.

Jacque.

Never knew this.

But I am missing how it works. If I have a handler that calls another, and step through, only the current handler has it variables listed: Breakpoint at first line of "mouseUp"

Reading your post, I thought that I could, while stepping through the "goSomewhere" handler, click on the "mouseUp" handler in that popup and see what the value of "var" is. I cannot. It hilites the line in the mouseUp handler, but does not reload the variables in that handler.

And setting these as script local variables shows them all anyway regardless of what I do with that popup.

Craig

It hilites the line in the mouseUp handler, but does not reload the variables in that handler.

Quite correct.
I should, of course, point out that PowerDebug does indeed do the right thing, showing variables in context.
http://www.ahsoftware.net/PowerTools/BuyPowerDebug.irev

Race conditions are pretty rare in LC, unless you're using timers.

Can you post the relevant code?

Richard-

sockets are also a good place to get into race conditions. Anywhere you have asynchronous events firing, they can get out of order.

What I'm doing is simple but convoluted. I am dynamically creating the UI on the fly, and I've got a command that creates button objects, and then calls another command, updateButtonScript to set the script of the button.

Normally this violated self-referential calls for set script. The fist itteration to defeat this was to send updateButtonScript in x milliseconds, which works about 70% of the time with increasingly large x values. While that solution works on desktop, those increasingly large delays to waits are not acceptable for a mobile environment. So instead i pivoted to another card to change the context, so updateButtonScript dispatched to command Pivot on another card, which then sets the button script on the prior card. This works quickly and eliminated the need to wait, but probably isn't the best method.

Now you're executing so fast that you get race conditions if the button even exists at that point, so we add 'wait until there is a button theButton of card myCard' to the Pivot command and we get much higher success rates. Now, add multiple assignments of buttons within a short time and you get 4 small windows for race conditions competing against each other, extending the parent handler's open message path time, and creating more updateButtonScript events to pivot off of.

Thus the need for very specific timing details so I know exactly when things are firing off and colliding. At least until I figure out how to completely break the message context...

What I'm doing is simple but convoluted.

Nothing simple about this at all

Rather than "wait until there is a button myButton of card myCard", how about something like
That way there's no blocking while it's waiting for the button to appear, and you get a chance to handle other pending messages in sort of a round-robin style.

...and I thought the milliseconds reporting was a good idea, so I just added it to PowerDebug's error reporter.