RE: Phone encodings (revisited)

> Go and fix one model writing the code needed to get it right.
> (Remember things like the phone filesystem may be in a 
> different encoding or may not support non-ascii chars).  
> Rinse and repeat on a seperate and totally unrelated model.  
> Do for a 3rd model.
> Don't forget the pelephone model.

Ok I've done this for three phones with the phonebook names and allowed for
acsii and another encoding to co-exist on the same phone. It is compatible
with Pelephone.

I added a new PACKET data type of UNICODE_STRING, it is the same as STRING
except for writetobuffer and readfrombuffer, they convert the data to and
from unicode when reading/writing the buffer. Internally it stores the
string as unicode, the conversion occurs as the data is written/read to/from
the phone
The encoding used is set by a function in prototypes and is global for all
UNICODE_STRINGS, it can be changed at any time. The __init__ of the phone
profile sets the encoding to the 'phone_encoding' attribute of the profile,
if defined, or ascii if not.
If we need to support more than one encoding on a phone then we could create
another string class UNICODE_STRING_2.

To add support for an encoding on a phone the developer has to do this.
1) add the attribute phone_encoding=XXXX where XXXX is the encoding used.
2) In the protocol file use UNICODE_STRING for strings that are encoded.

I'm not going to change the p_brew packets to use this, I don't know if
non-ascii works and I con't want to bugger up my phone trying.

Simon



-------------------------------------------------------
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