
If you wish to report a bug, and the bug is reproduceable it may be helpful to
me if you run jpilot -d to run in debug mode, reproduce the error and then
send me the log file from ~/.jpilot/jpilot.log

==============================================================================

These are some of the bugs that I know about:

* Priority High:

* Priority Medium:

* Priority Low:

 - Kyocera QCP 6035 phone/palm combos don't close the address database, so it
   can't be sync'ed.  It is a Kyocera problem, and there is no known solution.

 - Setting the time on Palm OS 3.3 in a conduit will crash the handheld.
   SyncTime will detect OS 3.3 and do nothing.  The fix is to upgrade Palm OS.

* Priority Who Cares?:

* Quirks (not really bugs):

 - jpilot lets you enter in blank todo's, etc.  The palm pilot will not allow
   this.

 - The palm pilot will only let you make appointments on 5 minute intervals.
   jpilot will allow 1 minute intervals.

 - The PalmOS datebook will alarm on private records even when they are hidden
   and they show up on the screen.  Right, or wrong, who knows.
   I will do the same.

*Palm OS bugs that I have found while creating J-Pilot

 - If you try to sync with a pilotrate of 0, then the palm pilot with get a
   fatal exception and reboot.  (tested on 3.1) This is a PalmOS bug.

 - The Palm pilot will let you sync (add) an appointment that repeats weekly,
   but doesn't repeat on any day.  It won't show up in the calendar, but if
   you search for it, it shows up.  When you click on it in find, a Fatal
   Exception occurs and the Pilot reboots.  This is a PalmOS bug if you ask me.

 - Empty appointments crash Palm OS 2.0 (I don't allow them anymore)

Syncing of categories:

I have put off allowing categories to be added on the desktop because I read
all the documentation I could find on how to sync categories and I couldn't
see how it could possibly work.  I kept thinking I was not understanding
something.

So finally, I booted into Windows NT, after not doing so for many, many
months.  After 2 BSODs, and some hacking, I got it to boot (no joke).
I ran some experiments to see how 3com handles syncing of categories.

Just as I suspected, they don't always handle it right, just as the
documentation would suggest.

Here is just one example using memo:

 (Category IDs are all unique)

The first 2 categories I changed the name of on the handheld and on the
desktop, the last 2 are new on both.

rec-synced?   Palm cat | index | memo || Desktop cat | index | memo
(    synced)  NewPalm    4       one     NewDesk       4       one
(    synced)  NewPalm2   5       two     NewDesk2      5       two
(not-synced)  NewPalm3   6       P NP3   NewDesk3      6       D ND3
(not-synced)  NewDesk    7       P ND    NewPalm       7       D NP

Now, I do a sync and end up with:

 cat      | index | memo 
 NewDesk    4       P ND 
 NewDesk2   5        
 NewDesk3   6       D ND3
 NewPalm    7       one
                    D NP
 NewPalm2   8       two  
 NewPalm3   9       P NP3

On the palm things seem to have synced as expected.  On the desktop things
have moved between categories.  Look at items "one" and "two".  They moved
categories on the desktop.  If this were 50 items, all 50 would have moved
and possibly merged with other items.

I have followed the documention I found on the web.  I have not tested to see
if this exact behavior is duplicated.

* Bugs specific to Version 0.99.3, and 0.99.4:
  (SERIOUS)
  If you create an appointment in jpilot and change it more than once before
  a sync you can overwrite another appointment.
  The appointment is given a low, not very unique ID (1, 2, 3, etc). that can
  overwrite other appointments that were created this way.
  i.e. an appointment is entered, modified and then synced.
   Its ID will be 1.
   Another appointment is entered in jpilot and modified.  It may get an ID
   of 1.  When it is synced it will overwrite the previous appointment with
   an ID of 1.
  If appointments are just entered, not modified and synced everything is fine.
  
