On Monday, Mar 10, 2003, at 04:01 Australia/Sydney, Bob Rasmussen <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
Date: Sun Mar 9, 2003  21:31:59 Australia/Sydney
To: <[EMAIL PROTECTED]>
Subject: Re: Goofy button behavior
Reply-To: [EMAIL PROTECTED]


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: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Date: Sun Mar 9, 2003  23:42:52 Australia/Sydney
To: <[EMAIL PROTECTED]>
Subject: Re: List View GUI
Reply-To: [EMAIL PROTECTED]


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 <[EMAIL PROTECTED]>
Date: Mon Mar 10, 2003  03:07:46 Australia/Sydney
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Re: List View GUI
Reply-To: [EMAIL PROTECTED]



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 [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution


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

Reply via email to