RE: [bme-develop] Code imported into CVS

[Daniel G. <al7...@ma...>]

Hi again.

> >Hello. I found a few problem with some of the changes.
> >The problem lays in that the MSN protocol uses the charset=3DUTF8 and=20
> > so
> >does BeOS for all the GUI text displaying classes. The problem is=20
> > that
> >BString cannot handle UTF8. So when you get the message body like=20
> > this:
> >	BString im;
> >	message->FindString("body",&im);
> >you get some problems for most of other non ascii characters, for
> >example =E1,=E9,=ED,=F3,=FA, =F1 (If you don't see this character chan=
ge the
> >encoding of the e-mail to Latin-1). I use these chars a lot since=20
> > most
> >of my conversations are in spanish. I think the best way to handle
> >messages is to use char pointers instead of BStrings, to avoid any
> >problems with character encodings.
> Ohoh...didn't know that...the guys at BeShare said that the BStrings=20
> would=20
> handle UTF8 well....so it does not...I never experienced those=20
> problems=20
> because those characters aren't used much here...I changed it to=20
> BString=20
> because the BString code is better organized, has more options and is=20
> a lot=20
> easier than those c methods, which I find quite difficult to=20
> use....but if=20
> it can't be done with BStrings then we have to use char* code...btw,=20
> what=20
> about c++ strings? can they be used, they are object oriented to and=20
> have=20
> most of the methods a BString has...or maybe implement our own=20
> version of a=20
> BString using the c methods?
>=20
I worked the problem!! The BString works good, the only problem was=20
that you ware using CountChars() to insert the message into the=20
TextView. I changed it to insertion.Length() and fix the problem, no=20
more ugly squares or missing chars, so I think we are good with=20
BStrings as long a we keep in mind this problem.

>
> Ok with me...btw another suggestion from me...I'm working on another=20
> beOS=20
> project and I use constants in this way:
>=20
> namespace Messages
> {
> 	const uint32 START_SIMULATION =3D 'STsi';
> 	const uint32 STOP_SIMULATION =3D 'SPsi';
> 	const uint32 SIMULATION_SETTINGS =3D 'SIse';
>=20
> 	const uint32 SET_SIMULATION_SETTINGS =3D 'STss';
> 	const uint32 NEW_CAMERA_DATA =3D 'NEcd';
>=20
> 	const uint32 UPDATE_MSG =3D 'UPms';
> 	const uint32 UPDATE_FAILURE =3D 'UPfa';
> 	const uint32 NEW_COORDINATES =3D 'NEco';
> }
>=20
> other constants are in other namespace, I personally prefer this=20
> approach to=20
> the c #define part because it's easier to understand...what do you=20
> think?=20
> also I would prefer putting the methods in common.cpp in a namespace=20
> because=20
> you can see that it's a method from common.cpp a lot easier:
>=20
> old: thismethod();
> new: Common::thismethod();
>=20
> what do you think? I know it's  quite a job to change all the=20
> #defines to=20
> namespace...but I'm willing to change the code in that way...if you=20
> agree=20
> with it....
>=20
I agree with using namespace.=20
For instance, MsnProtocolConstants, MsnProtocolMessages,=20
MsnProtocolCommands, etc, etc...
I can start making the changes for the Common namespace