Upgrading / Deleting things from UserStore in new version. Method

If you don't give your enumerators values explicitly, the compiler will give them values for you. The way that you've declared your enum, the values are implied. The one named ENUM1 has the value 0 (in both cases), and both ENUM2 in the original code and ENUM3 in the new code share the value 1. If you call getProperty(ENUM3) in your new code, it will return the value that was stored in the old application with a call to setProperty(ENUM2, ...). Does that make any sense?

The easiest thing to do is to give explicit values to the enumerators in the old version, and then never re-use those values. If you want to delete them from the object store completely, you can call deleteProperty() or clearProperties().

Travis

I sort of understand it now. The enum are like arrays and always start at ZERO no matter if I delete old ones.

You mentioned to explicitly declare values?

Or u mean just leave the old Enum there but never reuse them?

Eg
Enum2 - I supposedly deleted then. But since this will cause issues. Best bet is to just leave them be but don't reuse them. (At the expense of additional space/memory used)

The suggestion about migrating the "userstore", I thought of but haven't thought thru completely. But for sure I don't want to clear it up cos that would make users unhappy. (Like the firmware that goes and clears of users heart rate zones.

Best thing if you use enums for keys, and you want to stop using one of them, is to leave it in place, and just not use it to refernce anything. As Travis said your are "enumerating" a list, starting at 0 by default.

so
enum {
key1,
key2,
key3
};

meaning key1=0, key2=1, key3 =2

Now, if you want to stop using key 2 and add key4 and key5, you'd use:
enum {
key1,
key2,
key3,
key4,
key5
};

and just never use "key2".
the values would be key1=0, key3=2, key4=3, key5=4

but if you did this: (not the way to to it!)
enum {
key1,
//key2,
key3,
key4,
key5
};

the values would be key1=0,key3=1,key4=2,key5=3

and key3 would get the property value for what used to be key2, and key4 would get the property value of what used to be key3

Or instead of using numbers for keys, you could use strings, as that also makes it easier if you want to use "user settings"

Thanks Jim and Travis..
Understand how to do it.

My ENUM are not actually labeled enum1/2/3 it's strings

enum{
field_array,
default,
properties


along those lines.

You can explicitly give enumerators values like so...

enum {
value1 = 1,
value2 = 2,
value3 = 3
};


If you don't give an enumerator an explicit value, its value will be one greater than the one that precedes it. If it is the first, it will get the value 0.

enum {
value1 = 1,
value2, // implicitly 2
value3 = 3
};


If you stop needing value2 for some reason, you can just leave it in there (as Jim suggested above). If you give an explicit value to the enumerator that follows, you can delete it or comment it out...

enum {
value1 = 1,
value3 = 3
}


You just have to remember to not re-use the old value.

I see.. I wasn't aware that one can explicitly put values to enum values.
I'm going to re-check the Docs.

just checked the docs, maybe i missed it, but searching for "ENUM" doesn't seem like it states that tho.

I see.. I wasn't aware that one can explicitly put values to enum values.
I'm going to re-check the Docs.

just checked the docs, maybe i missed it, but searching for "ENUM" doesn't seem like it states that tho.

"enums" have been around so long in various programming languages that the doc writer may have left that one out :)

And as I said, another option is to use a string as a key, and not use a number as a key. It takes a bit more memory in the .prg, and a bit more in the object store, but it makes it easy to move something to a "user setting" with SDK 1.2.0.

var key_xyz="xyz";
var key_abc="abc";

q=app.getProperty(key_abc);
r=app.getProperty(key_xyz);



and "q" could come from the object store, while "r" comes from user settings, and you can easily change "q" to come from user settings, with no changes in your .mc!

What "user settings" also means is you may be able to remove some of your user settings code from the app (freeing up .prg memory), and have these things set using GCM on the user's phone.

I've added a task to update the enum documentation to describe explicit assignment. We seem to have a lot of new coders being drawn to our platform, which is great, so really spelling out what Monkey C can do would help avoid frustration for them. It can't hurt to have good docs for experienced people, either. ;)

Thanks All..

will see what I can do within my capabilities.