Arrays and Custom Props

[Paul Looney]

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