Re: MC-REV Event similar to AppleEvent?

2004-01-25 Thread RCS
I am trying to stay away from anything 'interpreted. Unless I am
misunderstanding how MetaCard/RunRev works, I believe scripts are converted
to something 'native' when you close the script for that object...using the
'do' command requires that your script be interpreted 'on the fly'. This can
make things very slow. I know I read this somewhere in the docs or an
email...something like using the 'do' command can slow your script
execution down by a factor of 10. I was also in correspondence with Scott
Raney about some script debugging, and he mentioned that a feature I wanted
was not possible because the saved scripts are in a form similar to C++ or
Java...leading me to believe that they are in some kind of 'bytecode' form.

Having a 'built-in' handler simply pass the event (with related data) to my
object would have allowed me to, in turn, pass that on to my 'Main' handler
using a very small script...making it possible to use the 'set script'
command in a stand-alone to update my objects to a 'native' script form
(rather than using your proposed method).

Am I making any sense?
;-)

JR


 Hummm .. Seems easy enough to me. Integrate one or
 more do statement[s] in your generic handler. The
 script that gets 'done' can be located elsewhere, e.g.
 in a field, in a file, from a URL...


___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent?

2004-01-21 Thread RCS
 What is the benefit of parsing an event rather than handling them
directly?

I need to be able to update a stack/card script in a standalone, and I
cannot because of the limit imposed. The stack script contains (mostly)
typical handlers (i.e. openStack, resumeStack, etc.) for handling messages
that are sent to the stack. If I had a 'single' handler in the script that
could handle 'all' stack messages, I 'might' be able to update the script
because the size of the script would be greatly reduced. I really wish
RunRev would allow 'some' things in a stand-alone for licensed users, or a
special license for increasing the script limit 'just a litlle'.


 You could, for example, have a frontScript

Since I already have a few 'idle' handlers running, I really did not want to
add another...especially one that parses 'everything'! Things are a little
sluggish as it is...


 That's an invalid address, requiring hand-editing.  Odd.
 Who's the list mom for this list?

I am starting to feel like an 'abandoned child' on this list (or at least
the uncle that everyone is ashamed to talk about)...also, (maybe it is just
me though) any message I post to the 'RunRev' list does not go through.

I can take a hint ;-)


JR

- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Tuesday, January 20, 2004 9:00 AM
Subject: metacard Digest, Vol 4, Issue 18


 Send metacard mailing list submissions to
 [EMAIL PROTECTED]

 To subscribe or unsubscribe via the World Wide Web, visit
 http://lists.runrev.com/mailman/listinfo/metacard
 or, via email, send a message with subject or body 'help' to
 [EMAIL PROTECTED]

 You can reach the person managing the list at
 [EMAIL PROTECTED]

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of metacard digest...


 This is the Metacard mailing list.

 Today's Topics:

1. Re: MC-REV Event similar to AppleEvent? (RCS)
2. Re: MC-REV Event similar to AppleEvent? (Richard Gaskin)


 --

 Message: 1
 Date: Mon, 19 Jan 2004 12:53:47 -0800
 From: RCS [EMAIL PROTECTED]
 Subject: Re: MC-REV Event similar to AppleEvent?
 To: [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=iso-8859-1


 on hWindowEvent theEvent, theData

  SWITCH theEvent
   CASE openStack
-- do this
break
   CASE mouseDown
 if theData = 3 then
  -- right-click
  else
  -- do that
 end if
break
   DEFAULT
-- do the other
break
  end SWICH

 end hWindowEvent


 I really don't want an 'idle' handler (or 'send to' handler) parsing
 everything that is happening in my environment...I thought there might be
 something 'native' that was not mentioned in the docs.

 Thanks,

 JR


 - Original Message - 
 From: [EMAIL PROTECTED]
 To: [EMAIL PROTECTED]
 Sent: Monday, January 19, 2004 9:00 AM
 Subject: metacard Digest, Vol 4, Issue 17

 
  To craft a solution that better meets your needs, can you tell us a bit
 more
  about the specifics of what you're looking to do, maybe with an example
of
  how you'd like to use it?
 
  -- 
   Richard Gaskin
   Fourth World Media Corporation


 --

 Message: 2
 Date: Mon, 19 Jan 2004 13:21:42 -0800
 From: Richard Gaskin [EMAIL PROTECTED]
 Subject: Re: MC-REV Event similar to AppleEvent?
 To: MetaCard List [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=US-ASCII

 RCS wrote:

  To craft a solution that better meets your needs, can you tell us a bit
  more about the specifics of what you're looking to do, maybe with an
  example of how you'd like to use it?

  on hWindowEvent theEvent, theData
 
  SWITCH theEvent
  CASE openStack
  -- do this
  break
  CASE mouseDown
  if theData = 3 then
  -- right-click
  else
  -- do that
  end if
  break
  DEFAULT
  -- do the other
  break
  end SWICH
 
  end hWindowEvent
 
 
  I really don't want an 'idle' handler (or 'send to' handler) parsing
  everything that is happening in my environment...I thought there might
be
  something 'native' that was not mentioned in the docs.

 What is the benefit of parsing an event rather than handling them
directly?
 You could, for example, have a frontScript with:

 on openStack
-- do this
   pass openStack
 end openStack

 on mouseUp
   -- do this
   pass mouseUp
 end mouseUp

 ...etc.


 PS: What's gone wrong with the MC list server to cause the reply-to
address
 for RCS' messages to be:

  RCS , Discussions on Metacard
 [EMAIL PROTECTED]@lists.runrev.com

 That's an invalid address, requiring hand-editing.  Odd.
 Who's the list mom for this list?

 -- 
  Richard Gaskin
  Fourth World Media Corporation
  ___
  [EMAIL PROTECTED]   http://www.FourthWorld.com


 --

 ___
 metacard mailing list
 [EMAIL PROTECTED]
 http

Re: MC-REV Event similar to AppleEvent?

2004-01-21 Thread Robert Brenstein
  What is the benefit of parsing an event rather than handling them
directly?
I need to be able to update a stack/card script in a standalone, and I
cannot because of the limit imposed. The stack script contains (mostly)
typical handlers (i.e. openStack, resumeStack, etc.) for handling messages
that are sent to the stack. If I had a 'single' handler in the script that
could handle 'all' stack messages, I 'might' be able to update the script
because the size of the script would be greatly reduced. I really wish
RunRev would allow 'some' things in a stand-alone for licensed users, or a
special license for increasing the script limit 'just a litlle'.
Yah, tough problem. I have been trying to find a way to increase 
those limits but no luck so far. Last year, Kevin posted to this list 
that they may consider some special licencing, but there was no 
follow up. I guess they can't justify making their operation more 
complicated on account of a few users.

On the other hand, I am not clear how having a single event will help 
you with the limits. If you can break down the scripts into 
functional chunks, then you can stuff them into a series of buttons 
or fields (hidden) and call them as needed. If you are after updating 
standalone-controlled stacks, it may be easier to make another 
standalone that opens the stack and modifies it. The standalone self 
can't be modified.

Robert Brenstein
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent?

2004-01-21 Thread Richard Gaskin
RCS wrote:

 What is the benefit of parsing an event rather than handling them
 directly?
 
 I need to be able to update a stack/card script in a standalone, and I
 cannot because of the limit imposed.

Actually, you can't because of OS restrictions in Win and UNIX which prevent
a running EXE from being modified.  (The Mac version of Rev follows suit for
consistency).

 The stack script contains (mostly)
 typical handlers (i.e. openStack, resumeStack, etc.) for handling messages
 that are sent to the stack. If I had a 'single' handler in the script that
 could handle 'all' stack messages, I 'might' be able to update the script
 because the size of the script would be greatly reduced. I really wish
 RunRev would allow 'some' things in a stand-alone for licensed users, or a
 special license for increasing the script limit 'just a litlle'.

Write them.  In a discussion on this subject last summer they noted that
they can be quite flexible in crafting licenses for special cases.

But considering that even a special license will not allow a standalone to
write to itself, why not simply include a Components folder with your app
and put stack files in there?  You could load those with start using to
have them act as libraries.

See 
http://www.fourthworld.com/embassy/articles/revolution_message_path.html
for more info on using libraries.

Alternatively you could move everything out of your stack except for the
splash screen into a Components folder for easy updating.


 You could, for example, have a frontScript
 
 Since I already have a few 'idle' handlers running, I really did not want to
 add another...especially one that parses 'everything'! Things are a little
 sluggish as it is...

Idle should not be related to other events -- how are you using it?  Use
idle with caution:  it's a CPU hog, with timers providing wha you need in
most cases but much more efficiently.

 That's an invalid address, requiring hand-editing.  Odd.
 Who's the list mom for this list?
 
 I am starting to feel like an 'abandoned child' on this list (or at least
 the uncle that everyone is ashamed to talk about)...also, (maybe it is just
 me though) any message I post to the 'RunRev' list does not go through.
 
 I can take a hint ;-)

I don't think it's you, I think it's something with the list configuration.
This oddness seemed to start when the Rev mail server was updated.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent?

2004-01-21 Thread Alain Farmer
Hello,

 I need to be able to update a stack/card script
 in a standalone, and I cannot because of the
 limit imposed ...

Hummm .. Seems easy enough to me. Integrate one or
more do statement[s] in your generic handler. The
script that gets 'done' can be located elsewhere, e.g.
in a field, in a file, from a URL...

 If I had a 'single' handler in the script
 that could handle 'all' stack messages,
 I 'might' be able to update the script.

That's much tougher, e.g. to NOT include the
*handlers* in the script at all. My approach requires
that these handlers be in the script but, because they
merely do code that is external to the script, the
script never needs to be changed. You update the
field, file or URL instead to change what will be
'done'.

Hope this helps,

Alain F

__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent?

2004-01-19 Thread RCS

on hWindowEvent theEvent, theData

 SWITCH theEvent
  CASE openStack
   -- do this
   break
  CASE mouseDown
if theData = 3 then
 -- right-click
 else
 -- do that
end if
   break
  DEFAULT
   -- do the other
   break
 end SWICH

end hWindowEvent


I really don't want an 'idle' handler (or 'send to' handler) parsing
everything that is happening in my environment...I thought there might be
something 'native' that was not mentioned in the docs.

Thanks,

JR


- Original Message - 
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, January 19, 2004 9:00 AM
Subject: metacard Digest, Vol 4, Issue 17


 To craft a solution that better meets your needs, can you tell us a bit
more
 about the specifics of what you're looking to do, maybe with an example of
 how you'd like to use it?

 -- 
  Richard Gaskin
  Fourth World Media Corporation

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent?

2004-01-19 Thread Richard Gaskin
RCS wrote:

 To craft a solution that better meets your needs, can you tell us a bit
 more about the specifics of what you're looking to do, maybe with an
 example of how you'd like to use it?

 on hWindowEvent theEvent, theData
 
 SWITCH theEvent
 CASE openStack
 -- do this
 break
 CASE mouseDown
 if theData = 3 then
 -- right-click
 else
 -- do that
 end if
 break
 DEFAULT
 -- do the other
 break
 end SWICH
 
 end hWindowEvent
 
 
 I really don't want an 'idle' handler (or 'send to' handler) parsing
 everything that is happening in my environment...I thought there might be
 something 'native' that was not mentioned in the docs.

What is the benefit of parsing an event rather than handling them directly?
You could, for example, have a frontScript with:

on openStack
   -- do this
  pass openStack
end openStack

on mouseUp
  -- do this
  pass mouseUp
end mouseUp

...etc.


PS: What's gone wrong with the MC list server to cause the reply-to address
for RCS' messages to be:

 RCS , Discussions on Metacard
[EMAIL PROTECTED]@lists.runrev.com

That's an invalid address, requiring hand-editing.  Odd.
Who's the list mom for this list?

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent? (John Rule)

2004-01-18 Thread RCS
Not 'quite' what I was looking for, but it could be used to get the same
result. I am not sure what the overhead cost would be though...I was hoping
for something 'native'.

Thanks for the response...

JR

 Message: 1
 Date: Fri, 16 Jan 2004 15:27:59 -0800 (PST)
 From: Alejandro Tejada [EMAIL PROTECTED]
 Subject: Re: MC-REV Event similar to AppleEvent?
 To: [EMAIL PROTECTED]
 Message-ID: [EMAIL PROTECTED]
 Content-Type: text/plain; charset=us-ascii

 on Fri, 16 Jan 2004 04:39:21 -0800
 RCS wrote:

  Is there a master 'Event' that we can use to tell
  what handler is being
  called (similar to the 'AppleEvent')? Rather than
  trapping 20 (or more)
  handlers in my window for events passed to it, I
  would like to 'discern'
  from a generic handler what message is being
  sent...and any data that was
  involved.

 Richard Gaskin has an utility named 4W_UmbrellaMan
 that does exactly what you want:

 http://www.fourthworld.com/rev/channel/4W_UmbrellaMan.mc

 al


___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent? (John Rule)

2004-01-18 Thread Richard Gaskin
RCS wrote:

 on Fri, 16 Jan 2004 04:39:21 -0800 RCS wrote:
 
 Is there a master 'Event' that we can use to tell
 what handler is being called (similar to the
 'AppleEvent')? Rather than trapping 20 (or more)
 handlers in my window for events passed to it, I
 would like to 'discern' from a generic handler
 what message is being sent...and any data that
 was involved.
 
 Richard Gaskin has an utility named 4W_UmbrellaMan
 that does exactly what you want:
 
 http://www.fourthworld.com/rev/channel/4W_UmbrellaMan.mc
 
 Not 'quite' what I was looking for, but it could be used to get the same
 result. I am not sure what the overhead cost would be though...I was hoping
 for something 'native'.

To craft a solution that better meets your needs, can you tell us a bit more
about the specifics of what you're looking to do, maybe with an example of
how you'd like to use it?

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 ___
 [EMAIL PROTECTED]   http://www.FourthWorld.com

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard


Re: MC-REV Event similar to AppleEvent?

2004-01-16 Thread Alejandro Tejada
on Fri, 16 Jan 2004 04:39:21 -0800
RCS wrote:

 Is there a master 'Event' that we can use to tell
 what handler is being
 called (similar to the 'AppleEvent')? Rather than
 trapping 20 (or more)
 handlers in my window for events passed to it, I
 would like to 'discern'
 from a generic handler what message is being
 sent...and any data that was
 involved.

Richard Gaskin has an utility named 4W_UmbrellaMan
that does exactly what you want:

http://www.fourthworld.com/rev/channel/4W_UmbrellaMan.mc

al

=
Visit my site:
http://www.geocities.com/capellan2000/
Search the mail list:
http://mindlube.com/cgi-bin/search-use-rev.cgi

__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard