Bob,
Think of custom properties as fields - without some of the field
overhead.
Putting information in custom properties and retrieving it is much
faster than using fields. And you can create and delete custom
properties on the fly much more easily than with fields - with less
code.
Two field features that cps lack are visibility (which is probably an
advantage for the storage you want) and chunk handling (you can not
refer to "line 3 of uMyUniqueCustomProperty" - but you can load the
property into a variable to get this information).
Like with fields, you can not store user information in a custom
property in an application (or standalone). This is actually a good
thing. By storing the user information in cps in a separate (call it
"Preferences" stack?) these settings not only survive the current
session, and subsequent sessions, they even survive an update of your
application (because you send the new app and the user retains the
prior Preferences). Plus it is easier to update and test apps without
having built-in customer information.
If you are only concerned with persistence of some items through
runtime, you should probably store these items in globals.
Paul Looney
On Feb 13, 2009, at 4:24 PM, Robert Sneidar wrote:
WHOA THERE TONTO! I thought the whole idea to properties was
persistence?? That means that I cannot save, for instance, the
database settings a user entered? I have to create an external file
for all of that? And so many card and object properties in my app
DEPEND on persistence through runtime. This means that I have to
put a kabosh on the whole project!
Say it ain't so Sam!
Bob Sneidar
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
