Re: Phone encoding error handling without rugs

> I plan to change the regular string class to use unicode internally, it will
> then be the same as the UNICODE_STRING class, but hardcoded to use ascii.

I like a combination of this and your earlier plan.  Make the STRING
class take an encoding parameter which defaults to ascii.  Internally
it stores as UNICODE but reads and writes in the encoding.

If all variants of a phone use the same encoding then it can just be
added in the p_ file.  If there is some other factor that determines
the encoding, then com_ file will need to specify the parameter
at decode/encode time.  Note that PACKETs can take a field of type
P which is accessible to all other fields.

The really difficult part is to make sure that round trips work
correctly.  For example if a contact is created named Grīd
but is written to the phone as Grid.  Later on when we
read back from the phone, we'll just see Grid.  (Even
worse we may have dropped that letter).  Similarly we
may write out a ringtone with that name and then read
back in a ringtone with the munged name.  The usual
solution to this is some sort of escaping.  However
we have to be careful as the phone won't like it.
Also names are stored in index files and may not match
the name ultimately written to disk.

I think it would be best if there are two parameters for
encoding - one for reading and one for writing.

The good thing about handling this internally in the STRING
class is we can generate a specific exception as you showed
which means that encoding issues dealing with the phone
won't be confused with encoding issues elsewhere.

Roger 



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642