$Id: TODO.TXT,v 1.3 2002/12/08 11:40:52 mankoff Exp $

GENERAL CODE STUFF:
* call DmSetDatabaseInfo to assign a version number to database
  It defaulted to "0" in 0.2.beta release (see DB)
* call DmDatabaseInfo to check DB version number (see DB)
* get cardNO dynamically, not hard-wired to 0
* Change application names to CRID because its 4 bytes (see DB)
* bold text for non-editable items in Config form (see UI)
* handle form correctly (delete form?, frmCloseAllForms()?) (see UI)

UI STUFF (MAJOR):
* See code07d0.c comments at top for more info
* provide list of apps to choose from
* allow form navigation with Up/Down keys, and also by writing first letter 
* error check for invalid characters
* error check 0 <= userID <= 65535

DB STUFF (MAJOR):  
* See code07d0.c comments at top for more info
* allow multiple personalities in DB
* error check for invalid characters
* error check 0 <= userID <= 65535
* re-format entirely (and therefore Prefs struct)

MAYBE STUFF (EXTRA WORK, NOT NECESSARY):
* Allow "setting" of system default
  - provide warning that it may not work
  - see QUESTIONS section below for more info

PALMOS REFERENCE PAGE NUMBERS AND RELEVANT SECTIONS
* The Memory Manager (186)
* The Data Manager (195)
  * DmRemoveRecord
* Features (285)
* Preferences (290)
* Retrieving the ROM Serial Number (318)
* Strings (338)
* Debugging Strategies (355)

QUESTIONS:
* If there is a reset while a personality is installed, that
personality becomes the system default after reboot. This needs to be
handled and can be taken care of a few ways: 

0) Don't detect resets. Let the user deal.
1) Detect resets. Alert the user if a problem exists. Suggest using
   ChangeName or provide our own interface to set defaults.
2) Store a copy of the default. Attempt to fix problem ourselves, or
   with users help.

There are problems with all these methods...

Here is a brain dump:
We can register/respond to sysAppLaunchCmdSystemReset to detect
resets. This means we are both a HACK AND ALSO have a PilotMain(). Is
this legal? Is this possible? We can set a bit every time we install a
personality, and unset when we un-install the personality. Then, if
there is a reset, and the bit is set, we know the wrong personality is
now the system default, and we can take actions to correct.

If we try to automatically correct, problems arise, because how do we
know the ONE TRUE personality, and how do we set it? We don't know it
because the user could change it, either with ChangeName or on the
Desktop. Can we register to detect this? Not for changename, but for
the desktop, I think so.  But, even if we detect and read the new
name, can we ever install it? Maybe, but if the user has installed a
personality for ChangeName, HotSync, and X-Master, then any changes
that get made while those programs are running get wiped by
Schizophrenic when they exit (and it restores the (presumably default)
presonality that existed prior to their launch). Ouch!

Hmm... Could schizophrenic install a personality, launch the program,
and then only restore the previous personality if the personality it
installed exists when the program exits? Yes, but is this a good
thing? Is this a feature or a bug?  This method, however, would let us
detect if ChangeName was used.

So, in summary, (0) is not very nice, (1) should work quite well and
is easy to implement, (2) requires a hellish recursive self-aware
semi-intelligent program.

I guess I will just increment a counter every time a personality is
installed, and decrement it every time its un-installed. This should
be in SystemPreferences or somewhere that survives resets. If its ever
NOT 0 or 1 (i.e. -1 or 2), then we know something has gone
wrong. Maybe we check it every time we add/subtract, or maybe we just
check it every time we enter config, or maybe we check it by
responding to a system reset. Not sure yet.
