Chris Tutty wrote: > From: "Logan Shaw" <[EMAIL PROTECTED]>
> I thought it might be useful to work on an open-source > example that would be useful to everyone because I've seen > a few projects where someone alters the preference structure > without realising the side-effects An open-source implementation is not a bad idea. Preferences code like this is simple enough that that should be very achievable as a project, and since virtually every program needs something like that, it would probably get used a lot. >>I think if I were starting from scratch, I would write preferences >>out as a symbol table. Then at app start time, I'd read that > Hmm, do you mean an array with a coded symbol id followed > by a value? Or something different? Actually saving the whole > thing as a string in property=value;property=value;... format > with a read and write function would be safer, but a little > space hungry. A text format would have its advantages (like being able to easily view and change preferences options by hand), but I was thinking of a binary format with strings in it. In fact there is no reason you couldn't allow both integers and strings as keys (and values) for preferences items; this would allow people to use an enum for identifying preferences items if they prefer that. (The binary format would have to have some kind of tag to indicate what format the key is in, but that's no big deal.) And yeah, that's a little wasteful with space, but not that bad considering most apps have like 10 or 20 preferences items. > I guess if you use a GetPref(), SetPref() pair of functions > the implementation gets a lot easier to hide. But that means > preference codes and having a lookup to return the value, > although I guess preference lookup isn't something you do > inside tight loops so robustness is worth more than speed here. And if you do need it inside a tight loop, just do a lookup and save the result in a local variable right before the tight loop. The issue of implementation hiding is an interesting one, though. If you make some open-source preferences routines, it'd be a lot cleaner to have preference storing, loading, and access in one piece that doesn't know anything about the application it's a part of. But that gets a little tricky. My Prefs.c file contains all the default values for all the fields (not exactly modular) and my Prefs.h #includes a few .h files specific to my project so that I can have the types I need to put in my prefs struct. But if you're separating the preferences stuff into its own standalone thing, it needs to be able to function without understanding your types. Which means that (short of serializable objects or something) preference values wind up being forced to be one of a few types that the preferences library supports. Still, I guess that's not SO horrible -- Mozilla has just string, boolean, and integer types for its preferences values and seems to get by OK. - Logan -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
