Code Libraries and Standalone Applications

[Peter Haworth]

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.reichelt at gmail.com>
> Subject: Re: Code Libraries and Standalone Applications
> To: How to use Revolution <use-revolution at lists.runrev.com>
> Message-ID:
> 	<z2uf99b52861004171711y9d2660b1wd22efecdcdd0715e at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Sun, Apr 18, 2010 at 7:41 AM, Peter Haworth  
> <pete at 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
>