Re: Front scripts vs Behaviors

[Mark Wieder]

Pete-

Thursday, August 12, 2010, 8:33:15 AM, you wrote:

> On the message path issue, I just meant ti wouldn't reach the target
> following the normal message path.  The model you showed using  
> dispatch is just what I need.

The dispatch command is my favorite thing about behaviors. 

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Front scripts vs Behaviors

[Peter Haworth]

Yep, the group=table/control=column model seems to work really well.   
I'm considering making all the handlers for it available once I've  
resolved the front script/behavior issue and tidied up the code.


On the message path issue, I just meant ti wouldn't reach the target  
following the normal message path.  The model you showed using  
dispatch is just what I need.


Pete

On Aug 11, 2010, at 9:01 PM, use-revolution-requ...@lists.runrev.com  
wrote:



Message: 9
Date: Wed, 11 Aug 2010 11:43:23 -0700
From: Mark Wieder 
Subject: Re: Front scripts vs Behaviors
To: How to use Revolution 
Message-ID: <95697085765.2010084...@ahsoftware.net>
Content-Type: text/plain; charset=us-ascii

Peter-

Wednesday, August 11, 2010, 10:01:05 AM, you wrote:

interface between controls on cards and my sqlite database.  Groups  
on

the card are tied to a db table and controls in the group are tied to
columns in the table related to the group.


Cool. I've thought of doing something like that.


If I switch over to behaviors (and I'm inclined to do that)  I need a
way to handle this "local" logic since, as you say, the messages  
wont;

ever make it to the actual control, but I still need the database


No, I did *not* say that (or at least didn't mean that). Messages
won't get passed farther down the path (card, stack, backscripts...)
*unless* you do something yourself. If you have a handler (e.g.,
mouseUp) in the behavior button and not in the target button you can
use the dispatch message in the behavior button to pass a message to
the target.

behavior:
on mouseUp
 doSomething
 dispatch doMouseUp to me
end mouseUp

target1:
on doMouseUp
-- change contents of another field
end doMouseUp

target2:
on doMouseUp
--  recalculate totals
end doMouseUp

target3:
on doMouseUp
--  stuff like that
end doMouseUp

--
-Mark Wieder
mwie...@ahsoftware.net



--


___
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: Front scripts vs Behaviors

[Mark Wieder]

Peter-

Wednesday, August 11, 2010, 10:01:05 AM, you wrote:

> interface between controls on cards and my sqlite database.  Groups on
> the card are tied to a db table and controls in the group are tied to
> columns in the table related to the group.

Cool. I've thought of doing something like that.

> If I switch over to behaviors (and I'm inclined to do that)  I need a
> way to handle this "local" logic since, as you say, the messages wont;
> ever make it to the actual control, but I still need the database  

No, I did *not* say that (or at least didn't mean that). Messages
won't get passed farther down the path (card, stack, backscripts...)
*unless* you do something yourself. If you have a handler (e.g.,
mouseUp) in the behavior button and not in the target button you can
use the dispatch message in the behavior button to pass a message to
the target.

behavior:
on mouseUp
  doSomething
  dispatch doMouseUp to me
end mouseUp

target1:
on doMouseUp
 -- change contents of another field
end doMouseUp

target2:
on doMouseUp
 --  recalculate totals
end doMouseUp

target3:
on doMouseUp
 --  stuff like that
end doMouseUp

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Front scripts vs Behaviors

[Peter Haworth]

Thanks Mark.  I've read Richard's write up before, very useful.

Maybe if I explain a bit more what I'm trying to achieve.  I've  
written a development framework for my apps which serves as the  
interface between controls on cards and my sqlite database.  Groups on  
the card are tied to a db table and controls in the group are tied to  
columns in the table related to the group.  Every time the user  
modifies the content of a control, my frontscripts handle the updating  
of the database in handlers such as menuPick, closeField, etc.


Sometimes, a specific control may need some "local" logic to handle  
things it needs to do other than just updating the db (changing the  
contents of another field, recalculate totals, stuff like that).  The  
front script handlers pass their respective messages on so I can write  
that "local" logic as a handler for that specific instance of that  
type of control.


If I switch over to behaviors (and I'm inclined to do that)  I need a  
way to handle this "local" logic since, as you say, the messages wont;  
ever make it to the actual control, but I still need the database  
update to occur in the behavior.  I'm thinking perhaps if I have  
handlers in the controls themselves named something like  
"localMenuPick" or something similar then have the behavior menuPick  
handler send/dispatch a localMenuPick messge to the control, that  
might work?


Pete


On Aug 11, 2010, at 8:12 AM, use-revolution-requ...@lists.runrev.com  
wrote:



Message: 27
Date: Tue, 10 Aug 2010 22:10:09 -0700
From: Mark Wieder 
Subject: Re: Front scripts vs Behaviors
To: How to use Revolution 
Message-ID: <136648291062.20100810221...@ahsoftware.net>
Content-Type: text/plain; charset=us-ascii

Peter-

Check out Richard Gaskin's writeup on the message path:

http://www.fourthworld.com/embassy/articles/revolution_message_path.html

Behavior objects are not at all like frontscripts, but are more like
local backscripts. That said, it sounds from your description that
behaviors fit your purposes more than the use of frontscripts does.

You wouldn't normally pass a message on after a behavior button has
handled it (or not) because it would be at the end of the message
path. Behavior objects also allow you to override a default behavior
when desired.

--
-Mark Wieder
mwie...@ahsoftware.net


___
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: Front scripts vs Behaviors

[Andre Garzia]

Dar Scott had a quite nice stack called "message path primer" which was
great! It was my introduction to rev message path and till today I still
remember it fondly.

Wonder if RevOnline still has it...

Just checked, it does not, but I have his website handy:
http://pages.swcp.com/dsc/revstacks.html





On Wed, Aug 11, 2010 at 2:10 AM, Mark Wieder  wrote:

> Peter-
>
> Check out Richard Gaskin's writeup on the message path:
>
> http://www.fourthworld.com/embassy/articles/revolution_message_path.html
>
> Behavior objects are not at all like frontscripts, but are more like
> local backscripts. That said, it sounds from your description that
> behaviors fit your purposes more than the use of frontscripts does.
>
> You wouldn't normally pass a message on after a behavior button has
> handled it (or not) because it would be at the end of the message
> path. Behavior objects also allow you to override a default behavior
> when desired.
>
> --
> -Mark Wieder
>  mwie...@ahsoftware.net
>
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: Front scripts vs Behaviors

[Mark Wieder]

Peter-

Check out Richard Gaskin's writeup on the message path:

http://www.fourthworld.com/embassy/articles/revolution_message_path.html

Behavior objects are not at all like frontscripts, but are more like
local backscripts. That said, it sounds from your description that
behaviors fit your purposes more than the use of frontscripts does.

You wouldn't normally pass a message on after a behavior button has
handled it (or not) because it would be at the end of the message
path. Behavior objects also allow you to override a default behavior
when desired.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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

Front scripts vs Behaviors

[Peter Haworth]

I'm currently using front scripts to handle common events for  
different types of controls.  For example, I have menuPick, mouseDown,  
and mouseUp front script handlers that deal with what I want do in  
those events for option menu buttons.  They all pass the event on so  
the real controls can have their own local logic in addition to the  
common logic in the front scripts.


I guess I'm wondering if it might be better to use behaviors instead  
of front scripts.  The front scripts seem to work just fine but I had  
to jump through several hoops to prevent them from intercepting  
controls I didn't want them to handle, for example everything in the  
rev IDE, and I think some of the occasional hangs I get in Rev might  
be because of these front scripts.  It feels like the behavior  
approach might be tidier since it keeps the logic closer to the  
objects themselves.


If I do switch to behaviors,  I'm not quite sure how to deal with the  
"local logic" I mentioned earlier.  If the behavior handlers pass the  
event, will it end up going to the instance of the object that  
initiated the event or will I have to use a different approach for that?


Seems like it might be a matter of programming style as much as  
anything else but I'm wondering what guidance there might be out there  
from people who've been using Rev for a lot longer than I have.


Thanks,

Pete Haworth









___
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: preOpenCard inside behaviors, does it works?

[Andre.Bisseret]

Bonjour,

I had such problems recently. Behaviors property still set when  
reopening stacks but not inherited.


It was with rev 4.0.
See subject "Behaviors handlers not found when re-opening stacks" in  
the June' archives


Trevor reply with this address :

http://quality.runrev.com/qacenter/show_bug.cgi?id=8280

So I shifted to Rev 4.5 and it works now

Don't if that helps

Best regards from Grenoble

Le 22 juin 10 à 23:19, dunb...@aol.com a écrit :


Mark.

Yep, you're right. If I quit rev and reopen, and immediately ask for  
the
behavior of the stack, I get a valid button reference. So it seems  
like
everything should be fine. But no go, like you discovered. And yes,  
if I set the
stack behavior manually all over again, changing, ostensibly  
nothing, it

works.

I'm going to report it.

Craig


In a message dated 6/22/10 4:54:21 PM, mwie...@ahsoftware.net writes:



That would be nice. But I'm finding that it doesn't work that way. It
seems ok while the stack is still in memory after I've set the
behavior, but if I save a stack with the stack behavior set to a
button with a preOpenXXX or openXXX or all the above and then reload
it, the messages aren't caught by the behavior button. If I set the
card behavior to the button then the message *are* caught when the
stack reloads.



___
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: preOpenCard inside behaviors, does it works?

[DunbarX]

Mark.

Yep, you're right. If I quit rev and reopen, and immediately ask for the 
behavior of the stack, I get a valid button reference. So it seems like 
everything should be fine. But no go, like you discovered. And yes, if I set 
the 
stack behavior manually all over again, changing, ostensibly nothing, it 
works.

I'm going to report it.

Craig


In a message dated 6/22/10 4:54:21 PM, mwie...@ahsoftware.net writes:


> That would be nice. But I'm finding that it doesn't work that way. It
> seems ok while the stack is still in memory after I've set the
> behavior, but if I save a stack with the stack behavior set to a
> button with a preOpenXXX or openXXX or all the above and then reload
> it, the messages aren't caught by the behavior button. If I set the
> card behavior to the button then the message *are* caught when the
> stack reloads.
> 
> 
___
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: preOpenCard inside behaviors, does it works?

[Mark Wieder]

Craig-

Tuesday, June 22, 2010, 1:42:34 PM, you wrote:

> No, as long as there is no preOpenCard handler in the card(s), the stack
> will get it, and then it will send it along to the button as per its (the
> stack's) behavior. Normal message hierarchy.

That would be nice. But I'm finding that it doesn't work that way. It
seems ok while the stack is still in memory after I've set the
behavior, but if I save a stack with the stack behavior set to a
button with a preOpenXXX or openXXX or all the above and then reload
it, the messages aren't caught by the behavior button. If I set the
card behavior to the button then the message *are* caught when the
stack reloads.

> On another note, I think the lack of behavior fields in the inspector is a
> missing feature, rather than a bug, no?

Yes, that's the way Trevor wrote up the report. And that's why it will
probably get pushed to the bottom of the to-do list.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: preOpenCard inside behaviors, does it works?

[DunbarX]

No, as long as there is no preOpenCard handler in the card(s), the stack 
will get it, and then it will send it along to the button as per its (the 
stack's) behavior. Normal message hierarchy.

This is essential if the initialization is required when opening other 
cards in the stack as well. If it is only for the first card, then set the 
behavior of the card, not the stack.

On another note, I think the lack of behavior fields in the inspector is a 
missing feature, rather than a bug, no?

Craig

In a message dated 6/22/10 3:50:11 PM, mwie...@ahsoftware.net writes:


> Here's a better answer: set the behavior of the *card*, not the
> *stack*. The preOpen and Open messages are actually sent to the first
> card in the stack, so they don't get trapped by the stack behavior. I
> still think this is a bug, but setting the card behavior makes
> things... er... behave.
> 
___
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: preOpenCard inside behaviors, does it works?

[Andre Garzia]

On Tue, Jun 22, 2010 at 4:51 PM, J. Landman Gay wrote:

> Andre Garzia wrote:
>
>> Mark & Craig,
>>
>>
>> if you have a preOpenCard in a behavior script and set the behavior of a
>> button to that script, does it fires when you navigate to the card that
>> contains the button?
>>
>
> Buttons never get preOpenCard messages, though. The card gets them.
>

They don't??? :-O

Living and learning... I always though it would travel to whoever had it.
Like

Object -> Groups -> Card -> Stack

So that if any guy on that progression implemented a preOpenCard handler, it
would trigger or passes to the guy on the right side...

I *think* did this before... maybe I am just plain wrong, can't trust my
brain with all the vuvuzelas sounding (gosh, did you know there are vuvuzela
iPhone Apps?)

Well, for the time being, I am now using a handler "setup" where I
initialize all the damn controls that had a preOpenCard... Not my ideal
solution but as long as it works.



>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: preOpenCard inside behaviors, does it works?

[DunbarX]

Hmmm.

Remember that the "preOpenCard" message is sent to the current card, not to 
a button on the card. Is that what the problem is, that the message is 
starting too high? I think there is a slight misunderstanding of the 
terminology.

You need to set the behavior of the card to (the script of) the button. The 
preOpenCard message will be automatically sent to the card (it is a system 
message) and it will then be passed to the button, just as if you explicilty 
sent it there. So you are not setting the behavior of the button, but 
rather the card. The button is the repository of the script, and is the 
"target" 
of the card's behavior, but its own behavior is irrelevant, and is not 
tampered with.

Try the simple stack I made. See how the button script is invoked when the 
card opens? The card has no script itself, only a behavior pointing to the 
button.

Craig Newman

In a message dated 6/22/10 3:45:48 PM, an...@andregarzia.com writes:


> Mark & Craig,
> 
> 
> if you have a preOpenCard in a behavior script and set the behavior of a
> button to that script, does it fires when you navigate to the card that
> contains the button?
> 
> Cheers
> 
> 
___
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: preOpenCard inside behaviors, does it works?

[Mark Wieder]

DunbarX-

Tuesday, June 22, 2010, 12:42:52 PM, you wrote:

> I set the stack behavior to the button. Beeps happily away...

Works that way for me, too... until I save the stack and reload it.

> But I did just notice that for most controls except for simple buttons and
> fields, there is no behavior field in the inspector. No problem writing this
> in, of course, but odd, I thought...

It's a known (and reported: BZ#8358) bug. No doubt it'll get fixed
around rev 7.3, or whenever it sufficiently annoys someone on the
team.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: preOpenCard inside behaviors, does it works?

[J. Landman Gay]

Andre Garzia wrote:

Mark & Craig,


if you have a preOpenCard in a behavior script and set the behavior of a
button to that script, does it fires when you navigate to the card that
contains the button?


Buttons never get preOpenCard messages, though. The card gets them.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: preOpenCard inside behaviors, does it works?

[Mark Wieder]

Mark-

Tuesday, June 22, 2010, 12:33:59 PM, you wrote:

replying to my own message again...

Here's a better answer: set the behavior of the *card*, not the
*stack*. The preOpen and Open messages are actually sent to the first
card in the stack, so they don't get trapped by the stack behavior. I
still think this is a bug, but setting the card behavior makes
things... er... behave.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: preOpenCard inside behaviors, does it works?

[Andre Garzia]

Mark & Craig,


if you have a preOpenCard in a behavior script and set the behavior of a
button to that script, does it fires when you navigate to the card that
contains the button?

Cheers


On Tue, Jun 22, 2010 at 4:42 PM,  wrote:

> Mark.
>
> I have no issue with "preOpenCard".
>
> I made a stack just like I wrote to Andre. A button has:
>
> on preOpenCard
>   Beep 3
> end preOpenCard
>
> I set the stack behavior to the button. Beeps happily away...
>
> But I did just notice that for most controls except for simple buttons and
> fields, there is no behavior field in the inspector. No problem writing
> this
> in, of course, but odd, I thought...
>
> Craig Newman
>
>
> In a message dated 6/22/10 3:34:03 PM, mwie...@ahsoftware.net writes:
>
>
> >
> > ...make that preOpenCard instead...
> >
> > ...and write up a bug report on preOpenCard and preOpenStack not being
> > passed to a behavior button...
> >
> >
> ___
> 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
>



-- 
http://www.andregarzia.com All We Do Is Code.
___
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: preOpenCard inside behaviors, does it works?

[DunbarX]

Mark.

I have no issue with "preOpenCard".

I made a stack just like I wrote to Andre. A button has:

on preOpenCard
   Beep 3
end preOpenCard

I set the stack behavior to the button. Beeps happily away...

But I did just notice that for most controls except for simple buttons and 
fields, there is no behavior field in the inspector. No problem writing this 
in, of course, but odd, I thought...

Craig Newman


In a message dated 6/22/10 3:34:03 PM, mwie...@ahsoftware.net writes:


> 
> ...make that preOpenCard instead...
> 
> ...and write up a bug report on preOpenCard and preOpenStack not being
> passed to a behavior button...
> 
> 
___
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: preOpenCard inside behaviors, does it works?

[Mark Wieder]

Andre-

...make that preOpenCard instead...

...and write up a bug report on preOpenCard and preOpenStack not being
passed to a behavior button...

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: preOpenCard inside behaviors, does it works?

[DunbarX]

Are you sure you have this set up correctly? A behavior is a property of an 
object, and explicitly references a button. This button has a script that 
the object "shares".

Does the button itself have the preOpenCard handler? Does the stack (or 
card) have its behavior set to the long ID of the button? If so, when the stack 
opens, the "preOpenCard" message will be sent to the button, and handled 
there.

Note that stack and card inspectors do not seem to have a place to set the 
behavior, unlike buttons and fields. These have to be set (I think, anyway) 
by a script or at least a message box command.

So if you have a stack that has its behavior set to the long ID of a button 
in that stack (or actually anywhere in memory), and a preOpenCard handler 
in the button that says "beep 3", you will get beeps every time you open the 
stack.

Craig Newman
___
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: preOpenCard inside behaviors, does it works?

[Mark Wieder]

Andre-

Tuesday, June 22, 2010, 11:22:21 AM, you wrote:

> Now, if I can't set things like preOpenCard in behaviors, how am I supposed
> to run code when the stack launches from behaviors?

in script of card 1:

on preOpenStack
dispatch "preOpenStack" to the behavior of this stack
end preOpenStack

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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

preOpenCard inside behaviors, does it works?

[Andre Garzia]

Folks,

Experiencing some technical difficulties here. Can someone answer me if
adding preOpenCard to a behavior will work? I have a button on a card that
should do some initialization stuff on preOpenCard, this code is set in its
behavior. Now when I navigate to the card, nothing happens.

Now, if I can't set things like preOpenCard in behaviors, how am I supposed
to run code when the stack launches from behaviors?

Cheers
andre

-- 
http://www.andregarzia.com All We Do Is Code.
___
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: Behaviors handlers not found when re-opening stacks

[Andre.Bisseret]

Le 1 juin 10 à 14:49, Trevor DeVore a écrit :


On May 31, 2010, at 8:43 AM, Andre.Bisseret wrote:


But
If I save and close these 2 stacks when I reopen them that does not  
work anymore (I get a "can"t find handler" error, and in tRev, the  
tab of the group's script opens up with some empty lines in it !!!??)


http://quality.runrev.com/qacenter/show_bug.cgi?id=8280


OK, (I am working with rev 4.0). I will try 4.5 dp3

Thank you much for your attention and your answer Trevor

André

___
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: Behaviors handlers not found when re-opening stacks

[Trevor DeVore]

On May 31, 2010, at 8:43 AM, Andre.Bisseret wrote:


But
If I save and close these 2 stacks when I reopen them that does not  
work anymore (I get a "can"t find handler" error, and in tRev, the  
tab of the group's script opens up with some empty lines in it !!!??)


http://quality.runrev.com/qacenter/show_bug.cgi?id=8280

--
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

Behaviors handlers not found when re-opening stacks

[Andre.Bisseret]

Bonjour,

 I am trying to modify an app. using behaviors,
To simplify, let's say that I have two independent stacks :
"stack 1.rev" and "stack 2.rev"

the behavior of stack 2 is set to the script of a button on stack 1  
(button "behaviorOfStack2")

The script of this button is :
--
on singBeep
beep 5
end singBeep
--
on this same stack 2 there is a group "group1" whose behavior is set  
to the script of a button on stack 1 (button behaviorOfGroup1)

The group is composed of 2 fields, the second is named "fldTarget"
The script of this button is:
-
on openField
if the short name of the target is "fldTarget" then singBeep
end openField
-
Works well: beep when opening the field "fldTarget" (either selecting  
in it, or coming in it from the first field by tab)


But
If I save and close these 2 stacks when I reopen them that does not  
work anymore (I get a "can"t find handler" error, and in tRev, the tab  
of the group's script opens up with some empty lines in it !!!??)


However, In the message box, If I ask for the behaviors of stack 2 and  
of group1 I get the right answer (also, the behavior of group1 is  
still there at the bottom of the Basic properties pane of the group).


Despite this, I have to set again the two behaviors (of stack 2 and  
group1) in order to get my openField handler working.


Is it normal to set again the behaviors of objects each time the  
stacks are opened? or am I missing something?


Thanks a lot in advance for any help


Best regards from Grenoble

André

___
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

Front Scripts vs Behaviors

[Peter Haworth]

I have several event handlers for common events such as mouseUp,  
openCard, menuPick, closeField which are installed as front scripts.  
The reason for this is to grab these events as soon as possible in  
order to handle any updating of the SQLite database I use to store the  
data for my app.  The handlers do various checks to make sure they  
need to handle the message, take action if necessary, and pass the  
message on so the handlers for these events in the controls themselves  
can take any further action needed.


This all works quite nicely although I've experienced some grief and  
hard freezes because of things like mouseUp coming from unexpected  
places like the IDE stack objects or the script editing window in  
debug mode.   I suspect I'm taking some performance hits as well since  
every single one of these events has to go through my front script  
handler.


I'm wondering if it might be better to do this by having behavior  
scripts for each type of control.  That would eliminate the need for  
checking that I'm dealing with a control I care about, the issues with  
events coming from unexpected places, and any performance issues.  On  
the downside, I'd need to come up with a way to allow each control to  
carry out any local processing it needs to take care of (dispatch?).   
It would also involve a small amount of extra work to specify the  
behavior every time I add a control unless I developed my own tool  
palette that had the controls already set up with the correct behavior  
so I could drag and drop them where I wanted them.


I'd appreciate some guidance on this, either philosophical or practical.

Thanks,

Pete Haworth







___
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: Behaviors

[Beat Cornaz]

George wrote :

>If you leave out the first handler, Beat, other controls that DON'T
>override the behavior will get no mouseUp behavior at all!

George, I see what you mean. In my case all the buttons that have the  
behavior, have a mouseUp script in themselves with different code  
from button to button. So I need the mouseUp in all of my regular  
buttons. That's why I can leave it out in the behavior script, in my  
special case. But you're right, in general the mouseUp will be needed  
in the behavior script.


Thanks,

Beat

___
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: Behaviors

[George C Brackett]

If you leave out the first handler, Beat, other controls that DON'T  
override the behavior will get no mouseUp behavior at all!


George

On Oct 26, 2009, at 2:37 PM, Beat Cornaz wrote:

Thanks for your answer Trevor. It works good. I found that it can be  
even 'easier' :


The first part (on mouseUp pBtnNum) of the Behavior Script is not even  
needed.


===
Behavior Script
===

on mouseUp pBtnNum  -- This handler can be left out.
   _mouseUp pBtnNum
end mouseUp


command _mouseUp pBtnNum -- This handler alone will do the trick
   DoA
end _mouseUp


I start to get the idea of behaviors. They behave like  commands or  
functions, but can be accessed from everywhere and are restricted to  
act only in response to certain objects (the ones with that behavior  
assigned) with a certain message (like mouseUp).
So the commands and functions can be more specific, less general than  
say in a library . Great.


Thanks,

Beat

___
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: Behaviors

[Beat Cornaz]

Thanks for your answer Trevor. It works good. I found that it can be  
even 'easier' :


The first part (on mouseUp pBtnNum) of the Behavior Script is not  
even needed.


===
Behavior Script
===

on mouseUp pBtnNum  -- This handler can be left out.
_mouseUp pBtnNum
end mouseUp


command _mouseUp pBtnNum -- This handler alone will do the trick
DoA
end _mouseUp


 I start to get the idea of behaviors. They behave like  commands or  
functions, but can be accessed from everywhere and are restricted to  
act only in response to certain objects (the ones with that behavior  
assigned) with a certain message (like mouseUp).
So the commands and functions can be more specific, less general than  
say in a library . Great.


Thanks,

Beat

___
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: Behaviors

[Mark Wieder]

Beat-

Monday, October 26, 2009, 3:10:57 AM, you wrote:

> Because my button to click also has a mouseUp, it will not reach the

Don't do that. See Trevor's response.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Behaviors

[Trevor DeVore]

On Oct 26, 2009, at 10:39 AM, George C Brackett wrote:

So the mouseUp message goes to the control script first (I get  
confused about this) and, if it's not handled, on to the behavior  
script, right? So by handling the mouseUp message in the control  
script, and NOT passing it on, the mouseUp message never reaches the  
behavior script. Do I have that right, Trevor?


Yes, that is correct.

Control always gets message first. Then behavior.

--
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: Behaviors

[George C Brackett]

So the mouseUp message goes to the control script first (I get  
confused about this) and, if it's not handled, on to the behavior  
script, right? So by handling the mouseUp message in the control  
script, and NOT passing it on, the mouseUp message never reaches the  
behavior script. Do I have that right, Trevor?


George

On Oct 26, 2009, at 9:47 AM, Trevor DeVore wrote:

On Oct 25, 2009, at 11:39 AM, Beat Cornaz wrote:

2.  A couple of btns have a behavior (DoA) assigned for mouseUp. Now  
one of the buttons has an additional task to perform on mouseUp  
(DoB). 'DoA' needs to be done before 'DoB'.


Beat,

When working with behaviors and engine events I usually define a  
second command in the behavior script that the behavior calls from the  
engine event. For example, a mouseUp would look like the following:


===
Behavior Script
===

on mouseUp pBtnNum
   _mouseUp pBtnNum
end mouseUp


command _mouseUp pBtnNum
   DoA
end _mouseUp


Now if you want to add additional functionality in mouseUp then you  
can make a call to the behavior _mouseUp handler. This will provide  
all of the functionality that the behavior provides at which point you  
can provide any additional functionality. In your case you would call  
DoB:


===
Control Script
===

on mouseUp pBtnNum
   _mouseUp pBtnNum
   DoB
end mouseUp


--
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

___
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: Behaviors

[Trevor DeVore]

On Oct 25, 2009, at 11:39 AM, Beat Cornaz wrote:

2.  A couple of btns have a behavior (DoA) assigned for mouseUp. Now  
one of the buttons has an additional task to perform on mouseUp  
(DoB). 'DoA' needs to be done before 'DoB'.


Beat,

When working with behaviors and engine events I usually define a  
second command in the behavior script that the behavior calls from the  
engine event. For example, a mouseUp would look like the following:


===
Behavior Script
===

on mouseUp pBtnNum
_mouseUp pBtnNum
end mouseUp


command _mouseUp pBtnNum
DoA
end _mouseUp


Now if you want to add additional functionality in mouseUp then you  
can make a call to the behavior _mouseUp handler. This will provide  
all of the functionality that the behavior provides at which point you  
can provide any additional functionality. In your case you would call  
DoB:


===
Control Script
===

on mouseUp pBtnNum
_mouseUp pBtnNum
DoB
end mouseUp


--
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: Behaviors

[Beat Cornaz]

Beat wrote :
>A couple of btns have a behavior (DoA) assigned for mouseUp. Now
>one of the buttons has an additional task to perform on mouseUp
>(DoB). 'DoA' needs to be done before 'DoB'.

Mark Wieder wrote :

>Use the dispatch command in the behavior object:

>on mouseUp
> DoA
> dispatch "DoB"
>end mouseUp

Thanks Mark. The problem is though that the 'DoA' is in the behavior  
script inside a 'mouseUp'.


The script of the behavior button :
on mouseUp
DoA
end mouseUp

Because my button to click also has a mouseUp, it will not reach the  
mouseUp handler in the behavior script. It only does if I 'pass  
mouseUp'. But then the order is wrong (I can only 'pass mouseUp' at  
the end of my mouseUp handler in the button to click, so after DoB  
has been executed. But the behavior script (with DoA inside the  
mouseUp) needs to run first.



Thanks,
Beat

___
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: Behaviors

[Mark Wieder]

Beat-

Sunday, October 25, 2009, 8:39:03 AM, you wrote:

> 2.  A couple of btns have a behavior (DoA) assigned for mouseUp. Now
> one of the buttons has an additional task to perform on mouseUp  
> (DoB). 'DoA' needs to be done before 'DoB'.

Use the dispatch command in the behavior object:

on mouseUp
 DoA
 dispatch "DoB"
end mouseUp

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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

Behaviors

[Beat Cornaz]

I started to use Behaviors today and ran into two things :

1. I have a behavior assigned to a couple of buttons and some label  
fields.


The script of the behavior button is :

on mouseEnter
   set the uVraagteken of stack "Timer-general_Lib" to true
end mouseEnter

on mouseLeave
   set the uVraagteken of stack "Timer-general_Lib" to false
end mouseLeave

Now all of a sudden this 'behavior' is all over the place. This  
'behavior' is also excecuted when I mouseEnter a graphic or a button  
which has the behavior removed. Even with a freshly created button.  
And it is the script in the behavior button, because if I comment it  
out, nothing happens. What is the matter here? For a while it worked ok.


2.  A couple of btns have a behavior (DoA) assigned for mouseUp. Now  
one of the buttons has an additional task to perform on mouseUp  
(DoB). 'DoA' needs to be done before 'DoB'.


This works, but is the wrong order :

on mouseUp
  Do B
  pass mouseUp  -- to activate the behavior
end mouseUp

I can't do it with 'send in Time' because the behavior (DoA) will  
exit to top in certain conditions.


I have come up with the inelegant solution : (especially if mouseDown  
has already a script). Any better ideas?


on mouseDown
   mouseUp   -- activates the behavior
   DoB
end mouseDown

on DoB
 -- do what is needed
end DoB

Any better ideas?
best,

Beat


___
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: Behaviors & Image References

[Chipp Walters]

I'm pretty sure that code ought to looks somewhat familiar to you ;-)
___
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: Behaviors & Image References

[Scott Rossi]

Recently, Chipp Walters wrote:

> I use a variation of:
> http://www.sonsothunder.com/devres/revolution/tips/scrp002.htm

Does exactly what I need -- thanks Chipp!

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & 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: Behaviors & Image References

[Chipp Walters]

Hey Scott,
I use a variation of:
http://www.sonsothunder.com/devres/revolution/tips/scrp002.htm

HTH,
C
___
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: Behaviors & Image References

[Scott Rossi]

Recently, Mark Wieder wrote:

>> Another question related to behaviors -- the resizeControl message that is
>> generated when resizing a group.  I thought this had been updated with some
>> enhancements specifically for behaviors.  Now that resizeControl is sent
>> continuously when resizing a group, is there any message sent once resizing
>> is done?  Or at least a way to determine when resizing is completed?
>> Barring a message, the only thing I can think of is starting a timer that
>> triggers an event after a specific period of resizing inactivity.
> 
> I'm not clear on why you need this, but how about using the mouseUp
> handler as an indication that you're no longer resizing?

I would, but mouseUp isn't sent with the pointer tool.

I need this because I want to update a control immediately after it is
resized.

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & 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: Behaviors & Image References

[Mark Wieder]

Scott-

Wednesday, April 29, 2009, 8:32:35 AM, you wrote:

> Another question related to behaviors -- the resizeControl message that is
> generated when resizing a group.  I thought this had been updated with some
> enhancements specifically for behaviors.  Now that resizeControl is sent
> continuously when resizing a group, is there any message sent once resizing
> is done?  Or at least a way to determine when resizing is completed?
> Barring a message, the only thing I can think of is starting a timer that
> triggers an event after a specific period of resizing inactivity.

I'm not clear on why you need this, but how about using the mouseUp
handler as an indication that you're no longer resizing?

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Behaviors & Image References

[Mark Wieder]

Scott-

Wednesday, April 29, 2009, 7:46:58 AM, you wrote:

> So my next question is, is there a more efficient way than the following to
> determine the parent stack of the behavior button?

Don't know about more efficient, but how about:

put the behavior of me into tParent
replace " of " with comma in tParent
get item -1 of tParent

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Behaviors & Image References

[Scott Rossi]

Another question related to behaviors -- the resizeControl message that is
generated when resizing a group.  I thought this had been updated with some
enhancements specifically for behaviors.  Now that resizeControl is sent
continuously when resizing a group, is there any message sent once resizing
is done?  Or at least a way to determine when resizing is completed?
Barring a message, the only thing I can think of is starting a timer that
triggers an event after a specific period of resizing inactivity.

I can't remember where I read about the new resizeControl behavior, but it
seems the 3.5 docs haven't been updated to account for this.

Thanks & Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & 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: Behaviors & Image References

[Scott Rossi]

Recently, David Bovill wrote:

> Maybe I don't get the question - my guess is you have something like a
> button in a group that uses an image in its behavior stack for its icon (say
> the image in the behavior stack is called "flag" for example), and you want
> to refer to this image by name - and not have to know / use its ID?

Correct.  Apparently Rev is smart enough to find an image in the behavior
stack using an id, but if one references an image by name or using variables
(put "my" & "cool" & "image" into tImageName), the behavior script generates
an error, saying it is unable to to find the image (Rev looks in the stack
where the control is located, as opposed to the behavior stack).

The reason I'm asking is because if I copy the behavior stack and its images
to other mainstacks, any controls that reference the behavior need to know
where to find the images.

I wonder if there's a better way this stuff could work.

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & 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: Behaviors & Image References

[Scott Rossi]

Thanks Jacque.

So my next question is, is there a more efficient way than the following to
determine the parent stack of the behavior button?

[in the object that has the behavior]

get word wordOffset("stack",the long owner of the behavior of me) to -1 of
the long owner of the behavior of me



Recently, J. Landman Gay wrote:

> Scott Rossi wrote:
>> I understand that with the new behaviors, image ids are automatically
>> resolved beginning with the stack containing the behavior button, but how do
>> we reference an image in the same behavior stack by name?  If one doesn't
>> know the id of an image located in the behavior stack, how is the image
>> referenced without using a full path reference (which defeats the purpose of
>> behaviors)?
> 
> Behaviors mainly deal with scripts and message paths. The engine
> includes the behavior button's stack as part of the regular search path
> when looking for IDs, but as I understand it, other objects themselves
> aren't part of behaviors. So you'd need to provide the same sort of path
> for other object references as we always have.
> 
> While I guess it isn't entirely accurate, I still think of behaviors as
> sort of a private backscript.


Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & 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: Behaviors & Image References

[David Bovill]

Maybe I don't get the question - my guess is you have something like a
button in a group that uses an image in its behavior stack for its icon (say
the image in the behavior stack is called "flag" for example), and you want
to refer to this image by name - and not have to know / use its ID?

The only thing I can think of is to define some getprop / setprops in a
library that check if there is a behavior and search for images in that
stack:

set the behavior_ImageName of btn 1 to "flag"
> put the behavior_ImageName of btn 1 into imageName
> put the behavior_ImageNames of btn 1 into possibleNames
>

is that the sort of thing?

2009/4/29 J. Landman Gay 

> Scott Rossi wrote:
>
>> I understand that with the new behaviors, image ids are automatically
>> resolved beginning with the stack containing the behavior button, but how
>> do
>> we reference an image in the same behavior stack by name?  If one doesn't
>> know the id of an image located in the behavior stack, how is the image
>> referenced without using a full path reference (which defeats the purpose
>> of
>> behaviors)?
>>
>
> Behaviors mainly deal with scripts and message paths. The engine includes
> the behavior button's stack as part of the regular search path when looking
> for IDs, but as I understand it, other objects themselves aren't part of
> behaviors. So you'd need to provide the same sort of path for other object
> references as we always have.
>
> While I guess it isn't entirely accurate, I still think of behaviors as
> sort of a private backscript.
___
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: Behaviors & Image References

[J. Landman Gay]

Scott Rossi wrote:

I understand that with the new behaviors, image ids are automatically
resolved beginning with the stack containing the behavior button, but how do
we reference an image in the same behavior stack by name?  If one doesn't
know the id of an image located in the behavior stack, how is the image
referenced without using a full path reference (which defeats the purpose of
behaviors)?


Behaviors mainly deal with scripts and message paths. The engine 
includes the behavior button's stack as part of the regular search path 
when looking for IDs, but as I understand it, other objects themselves 
aren't part of behaviors. So you'd need to provide the same sort of path 
for other object references as we always have.


While I guess it isn't entirely accurate, I still think of behaviors as 
sort of a private backscript.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Behaviors & Image References

[Scott Rossi]

I understand that with the new behaviors, image ids are automatically
resolved beginning with the stack containing the behavior button, but how do
we reference an image in the same behavior stack by name?  If one doesn't
know the id of an image located in the behavior stack, how is the image
referenced without using a full path reference (which defeats the purpose of
behaviors)?

Thanks for any clues.

Regards,

Scott Rossi
Creative Director
Tactile Media, Multimedia & 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: Message Path article updated for Behaviors

[Jim Bufalini]

Hi Richard,

Very well written. ;-)

Aloha from Hawaii,

Jim Bufalini

> -Original Message-
> From: use-revolution-boun...@lists.runrev.com [mailto:use-revolution-
> boun...@lists.runrev.com] On Behalf Of Richard Gaskin
> Sent: Tuesday, March 31, 2009 9:13 AM
> To: How to use Revolution
> Subject: Message Path article updated for Behaviors
> 
> Now that v3.5 is close to release with its nifty new Behaviors feature,
> I've updated my article on the Message Path to include a section
> introducing the basics of using this powerful addition to the language:
> 
>Extending the Runtime Revolution Message Path:
>An introduction to using Libraries, FrontScripts,
>BackScripts and Behaviors in Revolution
> <http://www.fourthworld.com/embassy/articles/revolution_message_path.ht
> ml>
> 
> --
>   Richard Gaskin
>   Fourth World
>   Revolution training and consulting: http://www.fourthworld.com
>   Webzine for Rev developers: http://www.revjournal.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

___
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: Message Path article updated for Behaviors

[Terry Judd]

Maybe Sarah doesn't have the southern hemisphere orientation plugin
installed in her browser. Actually I think I remember seeing that it doesn't
work with the Safari 4.0 beta.

Terry (Firefox user)


On 1/04/09 1:42 PM, "J. Landman Gay"  wrote:

> Sarah Reichelt wrote:
>> Yes, I had to stand on my head to read it :-)
> 
> But...I thought you were already upside down over there. :)

___
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: Message Path article updated for Behaviors

[Kay C Lan]

On Wed, Apr 1, 2009 at 10:38 AM, Richard Gaskin
wrote:

>  Hope it helps people get on board with v3.5.  I've never been more excited
> about a release in many years.
>

Yes, thanks Richard, and Kevin, Trevor and Bill for the webinar. Whilst I've
enjoyed the stability improvements since 2.6 most of the additional features
I've only ever toyed with, my programing style hasn't changed much. With
dataGrids and Behaviours I can see that all that's about to change.

Also looking forward to 3.5. I might even start holding my breath;-)
___
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: Message Path article updated for Behaviors

[Kay C Lan]

On Wed, Apr 1, 2009 at 10:42 AM, J. Landman Gay wrote:

>
> But...I thought you were already upside down over there. :)
>

I think you'll find the answer here:

http://www.gregorys-online.com/maps/index_html?content_id=45'

Look closely at the image.
___
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: Message Path article updated for Behaviors

[Richard Gaskin]

Mark Wieder wrote:


Richard-

Tuesday, March 31, 2009, 12:12:47 PM, you wrote:


Now that v3.5 is close to release with its nifty new Behaviors feature,
I've updated my article on the Message Path to include a section 
introducing the basics of using this powerful addition to the language:



   Extending the Runtime Revolution Message Path:
   An introduction to using Libraries, FrontScripts,
   BackScripts and Behaviors in Revolution
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>


Nicely done. Would be nice to have a line about the dispatch command
in there as well, since it swims against the tide of message-passing.
And its addition to Figure 3. But it makes the... er... behavior... of
behaviors very clear.


Thanks, Mark.

I think you're right - dispatch deserves mention there.  I haven't 
played with it much yet, but I can see that it's very useful and will be 
using it to replace my slower custom dispatcher soon.  Once I get some 
time to play with it I'll add a note there about it.  Thanks for 
reminding me about dispatch.


That's the problem with v3.5:  there's too much cool new stuff to keep 
in one's head. :)


--
 Richard Gaskin
 Fourth World
 Revolution training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.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: Message Path article updated for Behaviors

[J. Landman Gay]

Sarah Reichelt wrote:

Now that v3.5 is close to release with its nifty new Behaviors feature,
I've updated my article on the Message Path to include a section introducing
the basics of using this powerful addition to the language:

 Extending the Runtime Revolution Message Path:
 An introduction to using Libraries, FrontScripts,
 BackScripts and Behaviors in Revolution
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>

This is nice, very well done. I like the diagrams. I see you are an earth
person. :)



Yes, I had to stand on my head to read it :-)


But...I thought you were already upside down over there. :)

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Message Path article updated for Behaviors

[Richard Gaskin]

J. Landman Gay wrote:


Richard Gaskin wrote:
Now that v3.5 is close to release with its nifty new Behaviors feature, 
I've updated my article on the Message Path to include a section 
introducing the basics of using this powerful addition to the language:


  Extending the Runtime Revolution Message Path:
  An introduction to using Libraries, FrontScripts,
  BackScripts and Behaviors in Revolution
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>


This is nice, very well done. I like the diagrams. 


Thanks.  Hope it helps people get on board with v3.5.  I've never been 
more excited about a release in many years.



I see you are an earth person. :)


Naw, I just read top-to-bottom. ;)

--
 Richard Gaskin
 Fourth World
 Revolution training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.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: Message Path article updated for Behaviors

[Sarah Reichelt]

>> Now that v3.5 is close to release with its nifty new Behaviors feature,
>> I've updated my article on the Message Path to include a section introducing
>> the basics of using this powerful addition to the language:
>>
>>  Extending the Runtime Revolution Message Path:
>>  An introduction to using Libraries, FrontScripts,
>>  BackScripts and Behaviors in Revolution
>> <http://www.fourthworld.com/embassy/articles/revolution_message_path.html>
>
> This is nice, very well done. I like the diagrams. I see you are an earth
> person. :)


Yes, I had to stand on my head to read it :-)

Cheers,
Sarah
___
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: Message Path article updated for Behaviors

[Mark Wieder]

Richard-

Tuesday, March 31, 2009, 12:12:47 PM, you wrote:

> Now that v3.5 is close to release with its nifty new Behaviors feature,
> I've updated my article on the Message Path to include a section 
> introducing the basics of using this powerful addition to the language:

>Extending the Runtime Revolution Message Path:
>An introduction to using Libraries, FrontScripts,
>BackScripts and Behaviors in Revolution
> <http://www.fourthworld.com/embassy/articles/revolution_message_path.html>

Nicely done. Would be nice to have a line about the dispatch command
in there as well, since it swims against the tide of message-passing.
And its addition to Figure 3. But it makes the... er... behavior... of
behaviors very clear.

-- 
-Mark Wieder
 mwie...@ahsoftware.net

___
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: Message Path article updated for Behaviors

[J. Landman Gay]

Richard Gaskin wrote:
Now that v3.5 is close to release with its nifty new Behaviors feature, 
I've updated my article on the Message Path to include a section 
introducing the basics of using this powerful addition to the language:


  Extending the Runtime Revolution Message Path:
  An introduction to using Libraries, FrontScripts,
  BackScripts and Behaviors in Revolution
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>


This is nice, very well done. I like the diagrams. I see you are an 
earth person. :)


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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: Message Path article updated for Behaviors

[Devin Asay]

Thanks for this excellent article, Richard.

Devin

On Mar 31, 2009, at 1:12 PM, Richard Gaskin wrote:

Now that v3.5 is close to release with its nifty new Behaviors  
feature,

I've updated my article on the Message Path to include a section
introducing the basics of using this powerful addition to the  
language:


  Extending the Runtime Revolution Message Path:
  An introduction to using Libraries, FrontScripts,
  BackScripts and Behaviors in Revolution
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html 
>




Devin Asay
Humanities Technology and Research Support Center
Brigham Young University

___
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

Message Path article updated for Behaviors

[Richard Gaskin]

Now that v3.5 is close to release with its nifty new Behaviors feature, 
I've updated my article on the Message Path to include a section 
introducing the basics of using this powerful addition to the language:


  Extending the Runtime Revolution Message Path:
  An introduction to using Libraries, FrontScripts,
  BackScripts and Behaviors in Revolution
<http://www.fourthworld.com/embassy/articles/revolution_message_path.html>

--
 Richard Gaskin
 Fourth World
 Revolution training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.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