Global scope of functions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Global scope of functions

Rob Beynon
Dear Colleagues
I'm producing a new tool for my research, and I'm trying to do this
'properly'. In other words, I am trying to cut down the amount of coding
scattered through the application (buttons, menus etc) and put calls
to functions or handlers at these locations. I then assemble all the
functions and handlers in the stack script (app is a 1 card stack).

Is this the logical way forward, or have others found better ways?

--
All best wishes,
Rob

(Created at 07:52 on 14/07/2005)



==============================================================
Prof. Rob Beynon                    |+44 151 794 4312 (voice)
Dept. Veterinary Preclinical        |+44 151 794 4243 (fax)
Sciences, University of Liverpool,
Crown Street, Liverpool L69 7ZJ     |mailto:[hidden email]
--------------------------------------------------------------
http://www.liv.ac.uk/pfg            |http://www.csiv.org
==============================================================

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Global scope of functions

xbury.cs
Hi Rob

Yes, that's the way. However if it is only one card, clarity can be
improved
if your card related scripts are in the card scripts and the stack-only
related scripts reside in the stack script. This is IMOHO the best way
 for future expansions of the software.

If you have more than one card (in a background group for example) then
it's best to keep things in the background script instead of the card. The
card script being only local to that card. Naturally the stack script
applies
again here. But if there are 2 backgrounds, then the stack scripts may
introduce conflicts between group operations...

The advantage of the stack script is that it sees it all in the stack...

cheers
Xavier

On 14/07/2005 08:57:18 use-revolution-bounces wrote:

>Dear Colleagues
>I'm producing a new tool for my research, and I'm trying to do this
>'properly'. In other words, I am trying to cut down the amount of coding
>scattered through the application (buttons, menus etc) and put calls
>to functions or handlers at these locations. I then assemble all the
>functions and handlers in the stack script (app is a 1 card stack).
>
>Is this the logical way forward, or have others found better ways?
>
>--
>All best wishes,
>Rob
>
>(Created at 07:52 on 14/07/2005)
>
>
>
>==============================================================
>Prof. Rob Beynon                    |+44 151 794 4312 (voice)
>Dept. Veterinary Preclinical        |+44 151 794 4243 (fax)
>Sciences, University of Liverpool,
>Crown Street, Liverpool L69 7ZJ     |mailto:[hidden email]
>--------------------------------------------------------------
>http://www.liv.ac.uk/pfg            |http://www.csiv.org
>==============================================================
>
>_______________________________________________
>use-revolution mailing list
>[hidden email]
>Please visit this url to subscribe, unsubscribe and manage your
subscription
>preferences:
>http://lists.runrev.com/mailman/listinfo/use-revolution


-----------------------------------------
Visit us at http://www.clearstream.com
                                                         
IMPORTANT MESSAGE

Internet communications are not secure and therefore Clearstream
International does not accept legal responsibility for the contents of
this message.

The information contained in this e-mail is confidential and may be
legally privileged. It is intended solely for the addressee. If you are
not the intended recipient, any disclosure, copying, distribution or
any action taken or omitted to be taken in reliance on it, is
prohibited and may be unlawful. Any views expressed in this e-mail are
those of the individual sender, except where the sender specifically
states them to be the views of Clearstream International or of any of
its affiliates or subsidiaries.

END OF DISCLAIMER
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
Reply | Threaded
Open this post in threaded view
|

Re: Global scope of functions

Robert J. Earp
In reply to this post by Rob Beynon
Rob,
You're doing the right thing in that it's best to get common functions
(handlers/script) at the highest level you can, and the stack level is
OK if you don't intend to ever use those functions in other stacks.  If
there is that chance, I'd suggest you create a stack just for your
common functions (call it myCommonFunctions or something), and link it
on startup of your project stacks like....

on openStack
    start using stack "myCommonFunctions"
end openStack

(this goes into your project stack/s)

.... which puts the stack script in the message path.  If you have a lot
of functions and wish to group them, say on different cards or different
buttons in your common functions stack, then just use handlers at the
stack level to pass the message on to the appropriate place.  I find
this a nice neat way of keeping track of things without having to scroll
through long lists of script.

You may wish to close the common functions stack when you close your
project, although I don;t think this is necessary if you are building a
standalone.  This is done via...........

on closeStack
    stop using stack "myCommonFunctions"
end closeStack


HTH, Bob....


>Dear Colleagues
>I'm producing a new tool for my research, and I'm trying to do this
>'properly'. In other words, I am trying to cut down the amount of coding
>scattered through the application (buttons, menus etc) and put calls
>to functions or handlers at these locations. I then assemble all the
>functions and handlers in the stack script (app is a 1 card stack).
>
>Is this the logical way forward, or have others found better ways?
>
>--
>All best wishes,
>Rob
>

--
Robert J. Earp - Ashford Training Technologies*
*18059 21A Avenue, South Surrey, British Columbia, Canada. V3S 9V7
T:(1)604 541 1662 Cel:(1)604 612 6688 F:(1)604 541 1686


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.15/49 - Release Date: 14/07/2005

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution