Richard Gaskin wrote:
David Burgun wrote:
From what you say below, I can understand why put x into me *may*
not work, but not why:
set the text of me to x
doesn't work either?
Others may disagree, but I consider that a bug and have filed a report
on it:
<http://support.runrev.com/bugdatabase/show_bug.cgi?id=3418>
I agree, there's a problem here. I have now looked at a sample stack
that David sent me in email.
If Transcript is to be learnable we must at least expect property
settings to be consistent.
The "set" command must act like the "set" command, and "me" should
resolve to the object reference when used in conjunction with "set".
I don't think the problem is with "set". I think it is with the
interpretation of "me".
In this case, even if it's an inherited HyperTalk behavior I believe it
should be updated to be consistent. The future holds more newcomers
than old HyperTalkers, and I see no benefit to sacrificing a much larger
future to adhere to a bad practice used by very few people (if it all)
in the past.
There is no problem with HC compatibility; HC acts differently than Rev
here.
And there may be no conflict at all in honoring "set" consistently --
how did HyperCard handle such cases?
In HyperCard, you can't use "set the text of" so "set" isn't an issue.
However, when I made a duplicate stack in HC, and changed the commands
to "put xxx into me" (for compatibility) HC worked fine. So the problem
is only in Rev.
Also, why in the case where the handler is called from one place it
works but if called from within another Handler it doesn't!
It isn't clear to me yet, but I suspect it's the way "me" is
interpreted. "Me" is the object (or contents) of the currently running
handler, but since the sample stack does a lot of "sends", I believe the
engine isn't successfully tracking which object is "me". It appears to
think only the original handler's object is "me", which in a way is true
because the first object's handler really *is* still running. When you
specify the long name instead of "me" then the object reference is more
specific and it works.
This may be due to the fact that, as Richard mentioned, fields on remote
cards are not initialized; I'm not sure. If that's true, then in this
case there is no "me" except for the originating object on card 1.
This isn't to say it shouldn't be fixed, only that I can see how it
would get mucked up. The way the sample scripts are written is fairly
convoluted; I would never have thought to do the job this way. I suspect
that is why this problem has never been reported in all these years,
since as Richard mentioned, it really takes a very specific setup to
reproduce this problem.
A much better approach would be to move all the handlers into the stack
script and take advantage of the natural message hierarchy, rather than
relying on all those "sends".
This seems related to the ambiguity of "me": sometimes it refers to the
object, sometimes to the object's contents.
I'm not sure if this particular case is a bug or an inherited HyperTalk
"feature" -- maybe Jacque knows?
It is not how HC works. HC does what you'd expect.
If this is not how HyperTalk works I would encourage you to create a bug
report for that one as well.
--
Jacqueline Landman Gay | [EMAIL PROTECTED]
HyperActive Software | http://www.hyperactivesw.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
