Thanks Sarah.
On the behaviors, I thought of a handler similar to the one you
mentioned, just seemed like there should be a more elegant way to deal
with this issue but I guess not. The hard coded behavior
specification is making me wonder if it would be easier and less
hassle to have the controls call handlers in the code library instead
of specifying a behavior. Seems like that would achieve the same goal
of a central code base shared by all the controls that need it.
Thanks for the pointer to the stackFiles property. That certainly
makes life easier but it still seems to defeat one of the purposes of
having a central code library in that there's a copy of the the
library in every app I write instead of it being in one central
location and accessed from that location by any app. Of course, I
only have one app right now and who knows if I'll ever write another
one so probably shouldn't worry about it!
Pete Haworth
------------------------------
Message: 11
Date: Sun, 18 Apr 2010 10:11:12 +1000
From: Sarah Reichelt <sarah.reich...@gmail.com>
Subject: Re: Code Libraries and Standalone Applications
To: How to use Revolution <use-revolution@lists.runrev.com>
Message-ID:
<z2uf99b52861004171711y9d2660b1wd22efecdcdd07...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Sun, Apr 18, 2010 at 7:41 AM, Peter Haworth
<p...@mollysrevenge.com> wrote:
I'm hoping I can get some advice from the people on this list who
know a lot
more that I do about the mechanics of distributing a standalone
application.
While developing my application, I wrote a number of commands that
I insert
as front scripts to the app. The scripts for these command were
all on
cards within the application stack file but I've moved them out of
that file
and into a separate code library file so I can use them in other
future
apps. I changed the insert commands in my application to load the
scripts
from the code library stack file instead of from the application
stack file
and all seems to be working fine after a couple of initial glitches.
Now I'm realising that when I distribute the application as a
standalone,
the file path to the code library stack (currently hard coded in
my app)
will certainly be different than it is on my computer.
I have the same issue with a library of objects with custom
behaviors that
currently resides on a card in my application which I would like
to move
out of the application and into a separate object library stack
file for use
in other apps. Plus, there's a more difficult problem with the
object
library in that the behavior definitions are all hard coded long
ids that
include a reference to the file path to my application stack.
I guess I could just include a copy of both library stacks in every
app but
that seems to defeat the purpose of central libraries
I'm sure these problems have been solved many times and I'd
appreciate some
guidance on the best way to handle this before I go charging down
the wrong
path!
I use "the stackFiles" to solve the library problem. The library files
DO need to be included with each app or the app will not be able to
find them & use them.
If you set the stackFiles using the Inspector, you can refer to the
library stacks by name only and your main stack will know where to
find them.
The library stacks do not have to be included in your working stack
file.
When you build the app, the standalone builder will automatically
include these stackFiles in the app, and you will still be able to
refer to them just by name, with no file path needed.
For behaviors, I don't know how this works out. When I have a bunch of
objects that need to be set to use a behavior, I write a handler to
loop through them and set them all. As a precaution, I have just left
these handlers in the stacks and call them in an openCard or openStack
routine. This is probably overkill, but at least I know it works.
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
