David Bovill wrote:
There is a case, where the long id stops working which was intoduced since
3.5 and behaviors. Though I have not had time to track down the cause. I
have filed it here <http://quality.runrev.com/qacenter/show_bug.cgi?id=8014>
It totally baffles me but sometimes "the long id of the target" fails to
convert an object reference form the form "control id 1234 of stack XXX" -
I've set a breakpoint in a crucial handler so I can clearly see the script
and variables when it fails - but can;t reproduce it except to note it only
happens occasionally with this behavior type reference. Anyway...
Very interesting bug you stumbled across there. Oddly enough, I can't
reproduce it using:
put the long id of btn id 1008 of stack "b"
...which returns the object descriptor with the full hierarchy as we
would expect:
button id 1008 of card id 1002 of stack "b" of stack
"/Users/rg/Desktop/a.rev"
Maybe this issue is specific to debug mode? Have you found a recipe for
getting that result outside of debugging?
The weirder part of that report was the part about behaviors being
disconnected even though the behavior reference was apparently correct:
Then I issued "set the behavior of grp 1 to the behavior
of grp 1" and everything started working again across
multiple stacks.
If the behavior is a valid reference, what would cause it to go bad?
I agree with your suggestion there that if the engine is unable to find
a referenced behavior it should automatically do the equivalent of "set
the behavior to the behavior" to attempt to fix it before bailing out.
What would be the ideal solution to make short and long IDs of stacks most
consistent with the rest of the language?
I'd go for returning the short name of the stackas equivalent to a unique
"id" of an object - unless there is a use for the current id (number)
returned.
I'm inclined to agree, but it may be useful to know why stacks have
integer IDs at all.
--
Richard Gaskin
Fourth World
Revolution training and consulting: http://www.fourthworld.com
Webzine for Rev developers: http://www.revjournal.com
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
