Hola compa�eros,
Estoy sufriendo una paranoia con el tema de los acentos. Seg�n he le�do desde la versi�n 0.9.25 de lazarus todo est� codificado con UTF8 (tengo la 0.9.28) sobre SO Windows XP.

Bueno tengo el siguiente procedimiento:

procedure Aviso(Texto: string);
begin
     Application.MessageBox(pchar(Texto),'Aviso',64);
end;

Y lo llamo con:

Aviso('Los par�metros han sido actualizados con �xito');

Al mostrar el mensaje los caracteres acentuados son sustituidos por ?.

Pensando que pudiera ser por el tipo del par�metro lo cambie por UTF8String con el mismo resultado. Examinando el valor del par�metro una vez pasado siempre va codificado en Ansi independientemente del tipo.

Cambiando la instrucci�n del procedimiento por:

Application.MessageBox(pchar(AnsiToUtf8(Texto)),'Aviso',64);

Funciona OK.

�Como puedo trabajar para evitar el tener que andar convirtiendo entre tipos de datos?

El 11/11/2010 12:26 p.m., Antonio �vora escribi�:

Hola Antonio...

es mejor usar MessageDlg. Yo uso esto y se ven perfectamente los caracteres acentuados; te pego un ejemplo donde lo uso:

            MessageDlg('��� Atenci�n...!!!', 'N�mero de comprobante ya
ingresado', mtWarning, [mbOk], 0);

quiz�s tb te sirva el ShowMessage..

Otra cosa que te puede servir es el SysToUTF8. Ejemplos:
   cSystemVersion        := SysToUTF8('Versi�n: ') + GetAppVersion;
aqu�, si no usaba esa funci�n, me aparec�a mi?ercoles
   pnlBotom.Caption      :=SysToUTF8(FormatDateTime('dddddd tt', now));

chauuuuuuuu

El 11/11/10 15:49, Paola Bruccoleri escribi�:

Primeramente gracias por contestar Paola.

Probare el MessageDlg, en cuanto a lo del SysToUTF8 lo habia leido (es m�s creo que era un post tuyo :D).

Ya te cuento.

Un saludete.

El 11/11/10 15:57, Antonio �vora escribi�:

Con el MessageDlg ocurre lo mismo, si el texto es un literal funciona sin problemas, pero si el texto es pasado como par�metro de un procedimiento/funcion salen los ? en vez de los acentos.

�alguna idea?

Saludos.

El 11/11/2010 01:14 p.m., Antonio �vora escribi�:

Hola Antonio...

as� me funciona:

procedure TPrincipal.Aviso(Texto: string);
begin
   MessageDlg(SysToUTF8('��� Atenci�n...!!!'), SysToUTF8(texto),
mtWarning, [mbOk], 0);
end;

Hello Antonio,

Thursday, November 11, 2010, 4:14:05 PM, you wrote:

A�> Con el MessageDlg ocurre lo mismo, si el texto es un literal funciona A�> sin problemas, pero si el texto es pasado como par�metro de un A�> procedimiento/funcion salen los ? en vez de los acentos. A�> �alguna idea?

Todo depende de la "fuente" de las strings, esto es, si viene de una base de datos, en qu� formato te llegan. Si vienen en UTF8 pues directamente al messagebox, si llegan en ANSI pues AnsiToUTF8, si llegan en iso8859-1 pues ISO_8859_1ToUTF8 y listo.

La salida de Lazarus es UTF8, as� que tienes que adaptar los datos llegados a ese formato.

El 11/11/10 17:07, Jos� Mejuto escribi�:

Hola Jos� y Paola,
Creo que la respuesta correcta seria:
Si al par�metro del procedimiento le paso un literal (no es el contenido de ninguna variable ni datos de ninguna BBDD), �como tendr�a que pasarlo para que estuviera en UTF8 y as� evitar la conversi�n?

Saludos y gracias.

Hello Antonio,

you wrote

> La salida de Lazarus es UTF8, as� que tienes que adaptar los datos > llegados a ese formato.

A�> Hola Jos� y Paola,
A�> Creo que la respuesta correcta seria:
A�> Si al par�metro del procedimiento le paso un literal (no es el contenido A�> de ninguna variable ni datos de ninguna BBDD), �como tendr�a que pasarlo A�> para que estuviera en UTF8 y as� evitar la conversi�n?

Eso ya depende de tu base de datos y c�mo hayas definido el campo en cuesti�n y c�mo tengas el "charset" de la conexi�n a la base de datos.

Para evitar conversiones, la base de datos deber�a de tener el campo definido como UTF8 y el charset de la conexi�n a UTF8 tambi�n o NONE.

Con Firebird y UTF8 en los campos hay un "problema" que no est� bien resuelto en Lazarus creo que por compatibilidad con Interbase, as� que en esta base de datos lo mejor para usar campos UTF8 es usar charset a NONE.

Cu�l es tu base de datos ?

Ah! los literales pueden estar casi seguro en UTF8, pero si el .pas es "antiguo" puede no serlo, para saberlo pulsa sobre el editor de c�digo con el bot�n derecho y selecciona (te lo pongo en ingl�s que es como lo tengo yo) "File settings -> Encoding" y ah� ver�s como est�n codificados los literales en ese .pas

El 12/11/10 11:40, Jos� Mejuto escribi�:

Muchas gracias Jos�, diste en el clavo.

Lo que ocurria era la unit donde se guardaba el procedimiento estaba codificado en UTF8 mientras que la unit desde la que llamaba estaba codificada en cp1252 (son unidades y formularios migrados desde Delphi).

Un cordial saludo y gracias reiteradas.

Jos� disculpa que discrepe contigo, pero no recomiendo para nada usar charset NONE porque eso te podr�a traer problemas de conversi�n.

Ya la compatibilidad de Firebird con Interbase se ha roto en las nuevas versiones. Si quieres mover datos de un sistema a otro mejor lo haces a trav�s de consultas. Eso sin preguntarme para que querer migrar a un sistema propietario.

Saludos cordiales
=========
|| ISMAEL ||
=========

Hello Ismael,

Friday, November 12, 2010, 3:52:42 PM, you wrote:

ILDG> Jos� disculpa que discrepe contigo, pero no recomiendo para nada usar ILDG> charset NONE porque eso te podr�a traer problemas de conversi�n.

ILDG> Ya la compatibilidad de Firebird con Interbase se ha roto en las nuevas ILDG> versiones. Si quieres mover datos de un sistema a otro mejor lo haces a ILDG> trav�s de consultas. Eso sin preguntarme para que querer migrar a un sistema ILDG> propietario.

No, no es eso, me refer�a a que el IBConnection de Lazarus no soporta bien campos en charset UTF8, de hecho lo hace muy mal :) creo que por compatibilidad con Interbase.

Para usarlos bien, no queda m�s remedio que usar CHARSET NONE, cosa que no me gusta, pero es lo que hay.

Demostraci�n, crea un campo UTF8 en firebird de 20 characters de tama�o, ver�s que ocupa 20*4 bytes en la base de datos, ya que cada UTF8 char puede tener hasta 4 bytes para codificarse. Bien, eso quiere decir que el datalen del campo son 20 y el datasize son 80 bytes. Ahora intenta actualizar ese campo poniendo como charset UTF8 en el IBConnection, y hazlo metiendo un campo de 20 caracteres UTF8 de una "�", ver�s que te da error, por que la cadena UTF8 ocupa 40 bytes y 20 chars, pero como 40 bytes es superior a 20 datalen, crack!. Para ello hay que detectar que el campo usa codificaci�n UTF8 (no recuerdo el c�digo interno) y usar el datasize en vez del datalen en ese caso.

El problema de usar NONE es que tienes que asegurarte de que mandas lo que hay que mandar. En mi caso, todos los campos de texto son UTF8 as� que no representa ning�n problema usar NONE. Si tuviera una mezcla si que podr�a tenerlos, y se complicar�a la cosa bastante.