I have just added the following to Bug #13649
http://quality.livecode.com/show_bug.cgi?id=13649
OS X 10.9.5 LC8rc1
After downloading LC8rc1 I immediately began experiencing less stable
behaviour vs dp16. In particular breakpoints were being ignored - these
being hard coded breakpoints not red dots. After time the debugger would
become so 'lost' that it would appear frozen and I'd have to restart LC.
Typically on restart the first one or two attempts to debug would be
successful and then LC would start skipping breakpoints - but proceed to
the end of the handlers OK; but after time it would again become 'lost' and
not get to the end. Eventually I discovered that to get the debugger to
stop where I needed it to I had to resort to duplication:
breakpoint
breakpoint
the debugger usually stopping at the second line. Other things I noticed
was that if the insertion point was within a handler, when I Saved the
changes would Apply OK but the stack didn't save in the normal way, the
oblong save box that normally comes up with the Stack:... Main stack:...
Sub stack:... File name:.. didn't appear. If the insertion point was
outside a handler (between the end of one and the start of another) then
the Save was normal.
My handlers all worked as expected and produced the results I needed. After
3 days I suddenly noticed a typo. To reference a Custom Property within a
Custom Property Set I had something like this:
set the prefCurrentDocument{"longDescriptiveName"] of stack "stackName" to
the prefCurrentDocument{"longDescriptiveName"] of stack "stackName" & cr &
tVariable
To save typing, I typically just copy and past such lines and just change
the 'longDescriptiveName' to whatever other ones I need.
The typo was in the left bracket, it's not a straight bracket [ but a curly
bracket {.
After replacing the two dozen odd instances of this typo, and now 4 days
on, I've not had a single problem with LC8rc1.
Thinking I had a sure fire recipe for this problem I tried creating a stack
to reproduce it but I can't. Interestingly I discovered the use of curly
brackets seems to be acceptable to LC. All these variations work for me:
put "this" into aArray{1] --left curly
put "that" into aArray[2} --right curly
put "other" into aArray{3} --both curly
set the prefDoc{"this"] of stack "test" to 1 --left curly
set the prefDoc["that"} of stack "test" to 2 --right curly
set the prefDoc{"other"} of stack "test" to 3 --both curly
So it appears that {} are synonyms for []. It'a not documented and I don't
know if it's intentional. At no time is an error thrown, and again, in my
case the result of my scripts were all correct (supported by my later
experiments) it was just the debugger skipping breakpoints, and the strange
Save behaviour that I was noting. This I could not reproduce with my
experiment stack.
So this is here just for other's reference. In my own mind I have no doubt
that the use of the left curly bracket in array notation was the cause of
skipping breakpoints and associated debugger problems - I just can't prove
it.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
