Re: Code Libraries and Standalone Applications

[Peter Haworth]

Thanks for the responses.  I've implemented the stackFiles property  
and all seems to be working fine for now.


I prefer the single, separate, code library file to embedding it in  
the app, mainly because that makes it shareable by any and all apps I  
send to people without including the same code separately in each app,  
but stackFiles is working for me for now.


On the issue of the long IDs for behaviors, I've found that the  
behavior does not have to be a long ID - button 1234 of stack "xyz"  
seems to work just fine - so including the stack that contains my  
behavior buttons seems like the way to go although, as with code  
libraries, I'd prefer to have a shareable, separate library of  
behaviors.


Thanks for pointing me in the right direction.

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: Code Libraries and Standalone Applications

[J. Landman Gay]

Peter Haworth wrote:

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. 


The idea behind libraries is that you only have to maintain a single 
code base, which can be re-used anywhere. But each app still needs to 
have copy, or at least access to a copy. Some apps, like Adobe, store a 
single copy of their libraries in a central location like Application 
Data, and all their apps point to and use it. You could do that too if 
you want, though most of us don't. But there's nothing that says you 
can't store your library stack in Application Data and "start using" it 
on startup. A library doesn't have to be in the same place as the app, 
as long as you know where it is located you can open and use it. You'll 
have to overwrite it if it changes though, which isn't necessary of you 
just ship the library along with the standalone.


More commonly, a library is stored inside the standalone as a substack.

--
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: Code Libraries and Standalone Applications

[Sarah Reichelt]

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

Unless you never distribute your standalones, or have the libraries on
some generally accessible server, you are always going to have to
include them with every app. The advantage of using libraries is that
you only have to maintain them in one place. Multiple projects can
access the same library stacks and will pick up any changes to the
libraries every time a new standalone is built.

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: 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 
Subject: Re: Code Libraries and Standalone Applications
To: How to use Revolution 
Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

On Sun, Apr 18, 2010 at 7:41 AM, Peter Haworth  
 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

Re: Code Libraries and Standalone Applications

[Peter Haworth]

Thanks Richard.

Pete Haworth






--
 Richard Gaskin
 Fourth World
 Rev training and consulting: http://www.fourthworld.com
 Webzine for Rev developers: http://www.revjournal.com
 revJournal blog: http://revjournal.com/blog.irv



___
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: Code Libraries and Standalone Applications

[Sarah Reichelt]

On Sun, Apr 18, 2010 at 7:41 AM, Peter Haworth  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

Re: Code Libraries and Standalone Applications

[Richard Gaskin]

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