Weirdness Passing Messages

[Richard Gaskin]

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