Bonsoir Richard,
As I said in a previous post, it seems that you *must* require or set
a property.
In your example you don't get or set a property.
See the quote below.
Le 26 sept. 08 à 11:28, Eric Chatonet a écrit :
Bonjour Scott,
The rule is rather simple when working with long IDs or long names:
You *must* require a property :-)
<number of lines of> is not strictly a property but <number of
lines of the text of> is because <text> is a property but <lines>
is just a keyword.
Le 26 sept. 08 à 17:18, Richard Gaskin a écrit :
Scott Rossi wrote:
Recently, Richard Gaskin wrote:
The only one I can think of offhand is "value", which executes at
about
the same speed as "do":
put the long id of field 1 into tField
put the number of lines of value(tField)
I would say the benefit of this is being able to avoid writing out
complicated do statements. Nice.
But, while something like this works:
put the number of lines of value(tField)
Rev refuses to compile this:
delete line 2 of value(tField)
Error reads: Commands: missing ','
Any idea why?
First, let me chime in with the others who suggest putting the long
id of the field into a variable, and using property settings to
access it. FWIW I find that simple and consistent, and generally
faster than using the value function (which can't precompile its
operation, so it runs with similar speed to "send" or "do",
measurably slower than compilable expressions).
IMNSHO, the issue here is the ambiguous syntax HyperCard
introduced, which Rev attempts to follow faithfully. While it's
convenient to be able to refer to a field's contents by referring
to the field, it sometimes raises questions about which you're
going to get.
I'm not advocating that we ditch it, or even implying it's
necessarily A Bad Thing, just noting that the intention of
providing usability in syntax sometimes comes at the cost of
learnability. Ambiguity is the devil's playground. :)
Experimenting with how the compiler handles that expression, I also
find that this won't even compile:
delete line 2 of the text of tField
We're using a property specifier, so why not?
It seems the "get" and "set" commands for properties are the
unambiguous ones, and attempting to use chunk expressions with
other commands (such as "delete") cause them to operate on the
string which is the object reference, rather than the contents of
the referenced object.
So you could write instead:
get the text of tField
delete line 2 of it
set the text of tField to it
To force the compiler to understand that a particular var is an
object reference and not a string, we might consider the
possibility of allowing an optional type specifier for the
variable, a la:
put the long id of fld 1 into tField as object
That would tell the compiler to always treat tField as an object
reference, and never attempt string operations on it.
It does rather change the flavor of the language to introduce
types, however, so I'm not convinced it's an optimal solution.
For the moment I'd just do the three-line alternative and move on....
--
Richard Gaskin
Managing Editor, revJournal
Best regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: [EMAIL PROTECTED]/
----------------------------------------------------------------
_______________________________________________
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
