Variable uninitialized variable values (or unexpected declarations)

[David Vaughan]

On Monday, Mar 10, 2003, at 04:01 Australia/Sydney, Bob Rasmussen 
<brasmussen at earthlink.net> wrote:
> I found the following to be rather surprising.
>
>     on mouseUp
>       switch 1
>       case 1
>         put "var =" && quote & var & quote
>         break
>       case 2
>         put "whatever" into var
>         break
>       end switch
>     end mouseUp
>
> Press the button and the message box will say
>     var = "var"
> However, reverse the cases in the switch so case 2 statements comes 
> first, press
> the button again, and the message box will now say
>    var = ""

> 1.  The uninitialized value of an undeclared local variable is its 
> name.  I
> already knew that, though I couldn't find it in the documentation.  
> Did I miss
> it?
>
> 2.  Apparently, any line of the form "put ... into|before|after ... 
> var" seems
> to be equivalent to "local var", as far as declaring var is 
> concerned,..
>
> 3.  Moreover, this doesn't seem right to me.  Having the uninitialized 
> value of
> a variable vary in this way is a little disconcerting, and if I had a 
> choice,
> I'd prefer it always to be empty -- the default declaration value.

Bob

You may have misapprehended what is happening here. A variable is 
"declared" in Rev (given no active declaration such as "local var") 
when you put information into it or get it out (basically). If you 
otherwise refer to a text string then the compiler treats it as a 
literal text string until proven otherwise. Thus, your first case 
statement says "put var" where "var" is an  unquoted string not already 
defined as a variable - it is the string "var". That is, it is _not_ an 
initial value of the  variable var but is a literal string "var".

Your second case tells the compiler to create the variable var and set 
its value to the string "whatever". When the second case is compiled 
before the first, then the variable var has already been created (and 
hence initialised to empty/zero) when your case 1 is executed. Thus, 
var is now interpreted as an empty variable (case 2 not having been 
executed yet), not a literal string, and displays accordingly.

Walk through your code in the actual sequence of considering first the 
compiler's perspective and then a second time for the run-time 
perspective.

Hope this clarifies things.

cheers
David
>
> RR
>
>
>
>
>
> From: Dave Cragg <dcragg at lacscentre.co.uk>
> Date: Sun Mar 9, 2003  21:31:59 Australia/Sydney
> To: <use-revolution at lists.runrev.com>
> Subject: Re: Goofy button behavior
> Reply-To: use-revolution at lists.runrev.com
>
>
> At 2:12 pm -0500 8/3/03, Ken Norris wrote:
>> Howdy,
>>
>> I have a button which is not part of a group, and never was. It shows 
>> its
>> own selection handles, not group selection handles, with "Select 
>> Grouped
>> Controls" off, the same as other buttons which are not grouped. If I 
>> select
>> buttons which are grouped in that case, it shows the group's selection
>> handles.
>>
>> All OK so far? OK, now watch this (here's the problem):
>>
>> It is executing the script of a group. In fact it is mixing the 
>> script of a
>> group to which it does not belong (in fact, it is not grouped at all) 
>> with
>> its own script.
>>
>> What's going on and how do I fix it.
>
> I guess the group's background behavior is set to true. So if an event 
> (mouseUp for example) is not handled in the button, it will be passed 
> to the group (background).
>
> Depending on circumstances, you can do one of the following:
>
> -- turn off "backgroundBehavior" in the group
>
> --  in the group script, enclose handlers with a condition like this:
>
> on mouseUp
>   if the owner of the target is me then
>    ##normal stuff here
>   end if
> end mouseUp
>
> --  catch the events in the non-grouped objects (probably not such a 
> practical approach)
>
> Cheers
> Dave
>
>
>
> From: "valetia at mac.com" <valetia at mac.com>
> Date: Sun Mar 9, 2003  23:42:52 Australia/Sydney
> To: <use-revolution at lists.runrev.com>
> Subject: Re: List View GUI
> Reply-To: use-revolution at lists.runrev.com
>
>
> Hey Brad,
>
>> Is there a preexisting way in Rev to build a list view GUI, with
>> repeating control widgets within a scrollable body?
>
> I posted a similar question recently and have received a number of 
> helpful
> responses.
>
> Do a search in the list for "combo-box" and you'll find the thread. 
> You can
> search the list at:
>
> http://www.google.com/advanced_search?q=site:lists.runrev.com
>
> Jan Schenkel has a sample stack that demonstrates how you can include 
> actual
> repeating control widgets within a scrollable body. You'll find it at:
>
> http://www.geocities.com/janschenkel/downloads/checkboxlist.zip
>
> If you're just looking to pop-up the exact same menu when clicking 
> within
> the same column on each line, you can use Ben Rubinstein's technique, 
> which
> you'll also find in the same thread.
>
> Valetia
>
>
>
>
>
> From: Brad Allen <BradAllen at mac.com>
> Date: Mon Mar 10, 2003  03:07:46 Australia/Sydney
> To: use-revolution at lists.runrev.com
> Cc: js.allen at mac.com
> Subject: Re: List View GUI
> Reply-To: use-revolution at lists.runrev.com
>
>
>>
>> Jan Schenkel has a sample stack that demonstrates how you can include 
>> actual
>> repeating control widgets within a scrollable body. You'll find it at:
>>
>> http://www.geocities.com/janschenkel/downloads/checkboxlist.zip
>>
>
> Thank you! This sample stack is exhibiting the kind of list view 
> behavior I'm interested in. I didn't realize there was such as thing 
> as a "scrolling group". I will take a close look at how this works.
>
>
>
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>