Data Grid deployment question

Josh Mellicker josh at
Thu Dec 17 15:57:31 EST 2009

Hi Trevor, and thanks for the quick answer!

On Dec 17, 2009, at 12:08 PM, Trevor DeVore wrote:

> On Dec 17, 2009, at 2:55 PM, Josh Mellicker wrote:
>> Here's our situation:
>> We have a product that uses a "splash" standalone that checks our server for updates in the secondary stack (the secondary stack is actually the real app) and downloads the updated secondary stack if it's newer.
>> We just, for the first time, put a data grid in the secondary stack.
>> So the question is, how do we deploy the "revdatagridlibrary.rev" library in this situation? Do we just make "revdatagridlibrary.rev" a substack of the secondary stack, and put a "start using" in the preOpenStack of the secondary stack? I thought I should ask before we started experimenting.
> I would either
> a) Bundle the library with the splash stack using the directions in this lesson:
> <>

We don't want to do this, for a few reasons: 1. if there are improvements in the datagrid library we are stuck with an old version, 2. we want to avoid making users re-download an executable when we have such a slick, behind-the-scenes updater :-)

> or
> b) Include the revDataGridLibrary.rev stack as a stack file in your application distribution. You need load this stack in memory before ANY of your application stacks open up or the behavior property of the Data Grid's won't resolve properly.

If we say:

start using stack "revdatagridlibrary.rev"

in the PreOpenStack of the stack that has a data grid, is that acceptable?

Or would it be better to have an intermediary stack that opens libraries, then launches a third stack which is actually the real program?

Also, is it better, when using a library, to say "start using", or "insert the script of... into back"?

> You could potentially include the stack as a substack to your stack but Rev would complain when you opened the stack in the IDE and had two versions of revDataGridLibrary in memory.

Strangely, we have not seen that message yet!

>> (Obviously we don't want to make thousands of users re-download a standalone.)
> You might want to consider updating the executable when you auto-update though. The reason is that the executable has the version, created on and modified on information. If you don't update the exe (on Windows at least, you could meddle with the info.plist file on Mac) then people using Windows Explorer to see which version of your app they have will see the wrong information.

True... but when we do tech support, we always have people use the "About..." menu, which is easier for them anyway.

> -- 
> Trevor DeVore
> Blue Mango Learning Systems
> ScreenSteps:
> Releasable Revolution Resources for Developers:
> _______________________________________________
> use-revolution mailing list
> use-revolution at
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:

More information about the Use-livecode mailing list