As many of you who use custom properties are no doubt aware, the following script will produce two custom properties, "test" and "fred", both set to values of true:

on test
  set the test of this stack to true
  put "fred" into test
  set the test of this stack to true
end test

So, the same script line results in a different result depending on what came earlier (and globally) in the execution of the stack---a potential source of almost impossible to track down bugs (well, at least in my experience). The problem, in my estimation, is that the first use of the statement is incoherent. As the custom property "test" has yet to be created, the evaluation of the statement should fail *because test has no value (yet), unlike the second use of the statement*. For consistency with the rest of transcript, the first use (and all other *literal* uses) of the custom property label) should be quoted or literals, as in: set the "test" of this stack to true (or set the "te"&"st" of this stack to true, which, of course, *doesn't* work!). Indeed, virtually every newbie to the use of custom properties in my experience does exactly that (i.e., assumes that as a literal is meant, a literal should be used), leading to an error. The second use is the above script is fine because it is referring either to a built-in property or to a previously defined custom property whose name is the value of test. It shouldn't create a new custom property if the first two possibilities are false.

Furthermore, with the current scheme, one can't do the following:

  repeat with i=1 to 5 -- create and set 5 custom properties
    set the ("prop"&i) of this stack to i
  end repeat

rather one has to resort to:

  repeat with i=1 to 5 -- create and set 5 custom properties
    put ("prop"&i) into x -- assume x is a new variable name
    set the x of this stack to i
  end repeat

which is fine, I guess (not really!), unless a property named "x" already exists!

I don't know what to recommend at this point, but it really is a bug waiting to bite the unwary. Unfortunately, unlike unquoted button and field names, which can be rendered consistent and bug-potential free by the scripter simply by quoting all such names, no such option is available here.
--
John R. Vokey, PhD
Professor
B.E.R.G. - Behaviour and Evolution Research Group
Micro-Cognition Laboratory
Department of Psychology & Neuroscience
University of Lethbridge
Lethbridge, Alberta T1K 3M4
CANADA


_______________________________________________
use-revolution mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/use-revolution

Reply via email to