David Burgun wrote:
Later on I was talking about my bad luck with C (one of the reasons
I fell in love all over again with xTalk was the tedium of C) with
Mark Lucas, perhaps the best C Mac programmer I know, and he said,
"Dude, I could have saved you a lot of time with Bonds -- none of
those examples have worked with any compiler for years." :)
Always a new gotcha to discover....
Yep! I've been thru something like this too, the difference here that
springs to mind is that the book you are talking about was written by
a third party, whereas the problem here is with the makers of the
product.
You've never programmed with the CarbonLib API, have you? ;)
Bugs, including errors and ommissions in documentation, are not unique
to Rev. In fact, offhand I can't think of any programming language or
operating system API that doesn't have a great many such issues.
The thing is that there are loads of example stacks and examples in
the documentation that use the form:
put <something> into me
IMO, they should *all* be changed so that they work 100% of the time
or at least a footnote given stating that it will only work *some* of
the time!
Code that works works.
What you've discovered is a fairly rare usage in which other people's
code doesn't work in your specific setup.
I agree it's a bug, but it doesn't mean that other code doesn't work in
the context it was written for.
I'm in the process of changing all my scripts now!
"All" may be more work than is necessary. Things that aren't broken
probably don't need fixing.
Just so I understand this:
in some circumstances; put <something> into me
Result in the object contents being used instead of the reference to
the object? If this is true, then if the field just happened to
contain "button 1", would:
put "XXXXX" into me
result in the contents of button 1 being changed?
Interesting question -- what happened when you tried it?
I tested it here and neither the button nor the field changed.
It seems your specific circumstance simply exposed a bug in which using
"me" in a field on a card that isn't opened behaves as expected in all
respects except actually putting the data into the field.
The ambiguity with "me" and other forms of field references relates more
to getting data than putting. With regard to putting our tests in this
discussion reveal it's less of an ambiguity and more of a simple bug.
Interestingly, if you change your field script to read:
on MessageHandler
set the text of me to "xxxxxxxxxxxxxx"
answer me
end MessageHandler
...the answer dialog displays "xxxxxxxxxxx", even though when you later
go to that card the field's actual contents appears unchanged.
Tuviah (the former lead engineer) once explained to me that there's a
lot of work done with initializing fields on open cards that the engine
doesn't do on unopened cards. Once in a while this works to your
advantage: if you use a field on an unopened card to strip out html to
obtain the text only, like this:
set the htmlText of fld 1 of card MyUnopenedCard
get the text of fld 1 of card MyUnopenedCard
....it's many times faster than doing the same operation on a field on
an opened card.
But as you've found, there's also a bug there: fields on unopened cards
apparently don't get their text set correctly if the "set" command is
used in the field and the field is the target of a "send" command used
to trigger this.
That's a lot of very specific conditions which must be met for this
error to be evident, which is probably why it hasn't been reported before.
If the button script sets the text directly, without relying on "send",
the text is updated as expected:
put "xxxxxxxxxxxxxxxxxxxxxx" into fld 1 of cd 2 of stack "b"
So yes, there's a bug. But it's such a very specific bug that it's not
likely to affect many people, and there are two simple workarounds for it:
a) use "the long id of me" instead of simply "me"
b) set the data from the original button script directly rather
than using "send"
Just the same, for the sake of completeness I've filed a bug report for you:
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=3420>
Given the highly specific nature of the bug and that there are at least
two ways to avoid it, I've marked its Severity rating as "Minor".
Please review the bug report to get a feel for the level of specificity
which helps the team resolve them, and please post there any other
reproducible bugs, with recipes, you may find.
Yes, there are no doubt more bugs waiting to be discovered, perhaps some
less obscure than this one.
HyperCard is often cited by its fans as being "bug free", but a team
member reports that it shipped with more than 500 known bugs (and an
knowable number of bugs that hadn't been discovered in testing).
Rev is a much more complex program than HyperCard. We can expect the
bugs-per-thousand-lines-of-code to be at least on par, and it may
actually be lower.
Windows has thousands of known issues, as does OS X.
Welcome to software. :)
--
Richard Gaskin
Managing Editor, revJournal
_______________________________________________________
Rev tips, tutorials and more: 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
