Re: Behavior Nightmare

[Josh Mellicker]

On Feb 14, 2010, at 3:56 PM, Scott Rossi wrote:

> It would seem using behaviors is more secure than temporarily removing
> security from a stack.


Is there a higher risk to setting the passkey of a protected stack? What is it?





On Feb 14, 2010, at 3:56 PM, Scott Rossi wrote:

> Recently, Josh Mellicker wrote:
> 
>> On Feb 13, 2010, at 1:21 PM, Scott Rossi wrote:
>> 
>>> The reason for all the jumping through hoops here is password protection: I
>>> need to be able to dynamically add and remove groups from the main stack,
>>> and this can't happen if the stack is password protected.
>> 
>> Doesn't setting the passkey of the stack allow you to add, delete, copy
>> groups, etc.?
> 
> One of the main benefits of behaviors, from the docs:
> 
> "The button containing the behavior script can be located anywhere. In
> particular this allows for it be located in a password protected stack,
> allowing you to protect the script without need to protect the controls
> using it."
> 
> It would seem using behaviors is more secure than temporarily removing
> security from a stack.
> 
> Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, UX Design
> 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[David Bovill]

On 14 February 2010 23:55, Scott Rossi  wrote:

> The following works on my end and appears to operate counter to what you
> say.
>
> - Create new stack "maintest".
>
> - Create substack of maintest named "subtest".
>
> - Create a button in stack subtest named "b1".  Script:
>  on mouseUp
>   answer theMsg()
>  end mouseUp
>
> - Create another button in stack subtest named "b2".  Script:
>  function theMsg
>   return "abc 123"
>  end theMsg
>
> - Go back to stack maintest.  Set the behavior of the current card to long
> id of btn b1; set the behavior of stack maintest itself to long id of btn
> b2.
>
> Click the card in the main stack.  You should see the "abc 123" message
> above.  Note the script will fail if you remove the behavior assigned to
> the
> main stack or the card in the main stack.
>
> If behaviors are indeed essentially object-level backscripts, then I think
> it makes sense that object-level behaviors "fall through" to
> card/stack-level behaviors -- this is consistent with card/stack scripts
> handling any messages that go unhandled by objects.
>

I don't follow - the example is it not just what you would suspect - just
like putting the scrpts in the card and stack script? I don't see what you
mean by "fall through"

card --> btn 1 of stack subtest ( = backscript of card)
   |
   v
stack --> btn 2 of stack subtest ( = backscript of stack)
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Scott Rossi]

Recently, Josh Mellicker wrote:

> On Feb 13, 2010, at 1:21 PM, Scott Rossi wrote:
> 
>> The reason for all the jumping through hoops here is password protection: I
>> need to be able to dynamically add and remove groups from the main stack,
>> and this can't happen if the stack is password protected.
> 
> Doesn't setting the passkey of the stack allow you to add, delete, copy
> groups, etc.?

One of the main benefits of behaviors, from the docs:

"The button containing the behavior script can be located anywhere. In
particular this allows for it be located in a password protected stack,
allowing you to protect the script without need to protect the controls
using it."

It would seem using behaviors is more secure than temporarily removing
security from a stack.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Scott Rossi]

Recently, Sivakatirswami wrote:

> Now, I'm not sure what you mean by "card-level behaviors falling thru to
> stack-level behaviors" but  from one point of view it makes sense that
> the behavior cannot be found, because the button that contains the
> behavior is not really in the message path as we normally understand the
> message path.  In fact, I could have sworn that the nature of behaviors
> not being in the message path was part of their "charm" so to speak...
> i.e. you would deliberaty keep certain handlers segregated from the msg
> path by having them be behaviors.

The following works on my end and appears to operate counter to what you
say.

- Create new stack "maintest".

- Create substack of maintest named "subtest".

- Create a button in stack subtest named "b1".  Script:
 on mouseUp
   answer theMsg()
 end mouseUp

- Create another button in stack subtest named "b2".  Script:
 function theMsg
   return "abc 123"
 end theMsg

- Go back to stack maintest.  Set the behavior of the current card to long
id of btn b1; set the behavior of stack maintest itself to long id of btn
b2.

Click the card in the main stack.  You should see the "abc 123" message
above.  Note the script will fail if you remove the behavior assigned to the
main stack or the card in the main stack.

If behaviors are indeed essentially object-level backscripts, then I think
it makes sense that object-level behaviors "fall through" to
card/stack-level behaviors -- this is consistent with card/stack scripts
handling any messages that go unhandled by objects.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Josh Mellicker]

On Feb 13, 2010, at 1:21 PM, Scott Rossi wrote:

> The reason for all the jumping through hoops here is password protection: I
> need to be able to dynamically add and remove groups from the main stack,
> and this can't happen if the stack is password protected.

Doesn't setting the passkey of the stack allow you to add, delete, copy groups, 
etc.?___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Sivakatirswami]

Scott Rossi wrote:

 I assume that card-level behaviors
should "fall through" to stack-level behaviors, but weirdly, I got script
errors saying the handler/function couldn't be found.  I tried a simple test
stack and stack-level behaviors appear to work there, so I can't figure out
what's going on.  


I just getting into behaviors also, I'm curious to better understand 
what you are doing and what works and what does not.


I thought a behavior was placed in an object (typically a button, 
right?) and then you set the behavior of  whatever other object (the 
stack in your case?) to the long ID of the object that has the behavior 
(the aforementioned button)


Now, I'm not sure what you mean by "card-level behaviors falling thru to 
stack-level behaviors" but  from one point of view it makes sense that 
the behavior cannot be found, because the button that contains the 
behavior is not really in the message path as we normally understand the 
message path.  In fact, I could have sworn that the nature of behaviors 
not being in the message path was part of their "charm" so to speak... 
i.e. you would deliberaty keep certain handlers segregated from the msg 
path by having them be behaviors.


Of course, I really don't know what I'm talking about so take all of the 
above with a grain of salt.


Sivakatirswami




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Scott Rossi]

Thanks for all the responses regarding behaviors.  I wound up moving several
scripts around and I think I have most things working.  There's still an odd
behavior I've run into where functions/handlers that resided in the behavior
of the stack refuse to get called.  I assume that card-level behaviors
should "fall through" to stack-level behaviors, but weirdly, I got script
errors saying the handler/function couldn't be found.  I tried a simple test
stack and stack-level behaviors appear to work there, so I can't figure out
what's going on.  Anyway, I worked around the problem by placing the
stack-level behaviors into a backscript.

The reason for all the jumping through hoops here is password protection: I
need to be able to dynamically add and remove groups from the main stack,
and this can't happen if the stack is password protected.  So I wanted to
use behaviors to get around this restriction and dump them into a substack,
which works for the most part.

Thanks again to all.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX Design


___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Jan Schenkel]

Do the groups have their 'backgroundBehavior' property set by any chance? In 
theory, a behavior acts like an object-specific backscript, but the message 
path for background groups is a tad strange when it comes to the card script, 
so who knows?
Can you confirm this with simple logging to a text field?

Jan Schenkel
=
Quartam Reports & PDF Library for Revolution


=
"As we grow older, we grow both wiser and more foolish at the same time."  (La 
Rochefoucauld)


--- On Fri, 2/12/10, Scott Rossi  wrote:

> From: Scott Rossi 
> Subject: Behavior Nightmare
> To: "Revolution Mail List" 
> Date: Friday, February 12, 2010, 3:04 AM
> Does anyone know what the message
> order is for behaviors assigned to
> multiple objects?
> 
> I have a set behaviors assigned to a card, and a set of
> behaviors assigned
> to a group that is placed on the same card.  It seems
> that the behavior
> scripts of card are being handled *before* the behavior
> scripts of the
> group.  Is this expected behavior?  Is there some
> way I can have the scripts
> of group processed before those of the card?
> 
> I've been trying to migrate a bunch of object/card/stack
> scripts to
> behaviors and it has been a major pain trying to get
> messages to naturally
> "fall" between objects the same way messages work in the
> normal message
> hierarchy.  I can't use a single set of behaviors for
> all the objects
> because there are common mouse event messages that need to
> be handled across
> objects depending on what object is clicked (ie mouseDown
> on the group does
> something different than mouseDown on the card).
> 
> Thanks for any advice/suggestions (needed to have this done
> 2 days ago and
> am beating my head against the wall).
> 
> Regards,
> 
> Scott Rossi
> Creative Director
> Tactile Media, UX Design
> 
> 
> ___
> use-revolution mailing list
> use-revolution@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage
> your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
> 




___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[Trevor DeVore]

On Feb 12, 2010, at 6:04 AM, Scott Rossi wrote:


Does anyone know what the message order is for behaviors assigned to
multiple objects?

I have a set behaviors assigned to a card, and a set of behaviors  
assigned
to a group that is placed on the same card.  It seems that the  
behavior

scripts of card are being handled *before* the behavior scripts of the
group.  Is this expected behavior?  Is there some way I can have the  
scripts

of group processed before those of the card?


Scott,

A Behavior acts just like the script of the object it is attached to  
so the message hierarchy remains unchanged. Have you confirmed that  
scripts are being executed out of order using logging?


--
Trevor DeVore
Blue Mango Learning Systems
ScreenSteps: http://www.screensteps.com
Releasable Revolution Resources for Developers: 
http://revolution.bluemangolearning.com
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

Re: Behavior Nightmare

[David Bovill]

Been using behaviors for a while now - and they have seemed unproblematic
and intuitive to me. I may well have missed something as I use them in a
particular way, but this is as far as i know the situation (shoot me down if
I get something wrong).

Behaviors are effectively backscript for the object they are attached to -
so a behavior on a group will be called before a card unless the group is a
background in which case it will be called after the card?


On 12 February 2010 11:04, Scott Rossi  wrote:

> Does anyone know what the message order is for behaviors assigned to
> multiple objects?
>
> I have a set behaviors assigned to a card, and a set of behaviors assigned
> to a group that is placed on the same card.  It seems that the behavior
> scripts of card are being handled *before* the behavior scripts of the
> group.  Is this expected behavior?  Is there some way I can have the
> scripts
> of group processed before those of the card?
>
> I've been trying to migrate a bunch of object/card/stack scripts to
> behaviors and it has been a major pain trying to get messages to naturally
> "fall" between objects the same way messages work in the normal message
> hierarchy.  I can't use a single set of behaviors for all the objects
> because there are common mouse event messages that need to be handled
> across
> objects depending on what object is clicked (ie mouseDown on the group does
> something different than mouseDown on the card).
>

Some thoughts:

   - a group behavior would be triggered before the card script unless
   background behavior is true
   - mouse events wont be sent to a group even if opaque unless an actual
   control is clicked on
   - card scripts can intercept and over-ride local group behaviors by using
   dispatch or checking for card properties
   - use as many groups as you want to nest behaviors
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution