Thanks, Mark. I suppose it would be easiest to store the data as
custom **stack** properties for simplicity in referring to them. I
wouldn't have to be concerned about which card-object/card was current
(i.e. button x of card y, etc.).
Kurt
___
Hi Kurt,
I suppose it would be easiest to store the data as
custom **stack** properties for simplicity in referring to them.
This will work so long as your stack remains a stack file: if saved
as a standalone, when the application starts up the properties will
always reflect the values in
I suppose it would be easiest to store the data as
custom **stack** properties for simplicity in referring to them.
This will work so long as your stack remains a stack file: if saved
as a standalone, when the application starts up the properties will
always reflect the values in place when
The answer to my question:
In standalone, custom stack properties must be saved in substack which
is a (separate) individual stackfile within the OS X application
package (set in stacks pane of standalone application settings).
Kurt
___
We're using about 100 global (single word) variables that need to be
stored between sessions. Can I store them as custom properties of the
stack, and then re-populate the globals with the saved values at the
next startup?
Is this the best method?
Thanks, Kurt
I just realized that I can probably just access the data as (stack)
custom properties, rather than having to move it into globals at
runtime.
___
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe,
That would be the most straightforward way to do it, I should think.
They needn't be stack custom properties (but they could be). Any
object can have custom properties.
Mark
On Jan 10, 2009, at 7:01 PM, Kurt Kaufman wrote:
I just realized that I can probably just access the data as
