delphi unicode

¿Alguna sugerencia para aquellos que quieran actualizar Delphi 7(y abajo) a Delphi 2010?



unicode (7)

Después de las actualizaciones 4 y 5, me interesa volver a evaluar Delphi 2010. Esta vez tengo la intención de portar parte de mi código (pequeña escala) para ver qué tan difícil es hacerlo a gran escala.

El problema principal parece ser la conversión de ASCII a Unicode. ¿Algún consejo o recurso sobre esto que haya encontrado útil?

Muchas gracias.

Editar:

En este punto, mi recomendación para otras personas (que desean actualizar) sería:

http://www.embarcadero.com/images/dm/technical-papers/delphi-in-a-unicode-world-updated.pdf

¿Es WideString idéntica a String en Delphi 2009?

¿Cuál es la versión del compilador para Delphi 2010?

http://chee-yang.blogspot.com/2008/10/delphi-2009-unicode.html

Tenga en cuenta que las imágenes Gif (por Melander) y Png (¿por Martijn Saly?) Ahora están incorporadas en Delphi 2010. Deberá usar un condicional para usar la unidad GIF correcta:

USES Windows, SysUtils, Graphics, blabla {$IFDEF VER150} , GIFImage, {Delphi 7} {$ELSE} GIFImg {Delphi 2010} {$ENDIF};

También debe "arreglar" el PNG proporcionado por Embarcadero: http://talkdelphi.blogspot.com/2009_03_01_archive.html

Otras cosas que debe saber es que realmente tiene que hacer una copia de seguridad de su proyecto antes de abrirlo en Delphi 2010. Delphi 2010 cambiará su archivo DFM incluso si no presiona el botón Guardar. El formulario perderá datos y no se compilará en D7.

ACTUALIZAR

Finalmente he actualizado. Delphi XE tiene algunas características nuevas. Desafortunadamente, muy pocos de ellos no funcionan en absoluto (compilación de fondo, modelado UML, información de código, por ejemplo), otros han sido degradados (la ayuda y por ejemplo). El IDE tampoco es tan estable y rápido como Delphi 7 y la barra de herramientas tiene problemas reales (mejor no personalizar el IDE). También hay un error desagradable en el que el IDE tiene un 100% de utilización de la CPU (vea mis otras publicaciones sobre todos estos problemas). Espero que en las actualizaciones 2 y 3 solucionen algunos de los problemas más estrictos.

De todos modos, creo que me actualicé demasiado pronto porque ahora Embarcadero anunció el compilador de 64 bits, así que probablemente tendré que volver a pagar una gran cantidad de dinero para actualizar a la próxima versión de Delphi para poder obtener ese compilador. Para aquellos que aún están pensando en actualizarse a Delphi XE, recomendaría probar Delphi XE antes de comprarlo para ver si ofrece algunas funciones que de lo contrario no estarán disponibles. No estoy diciendo que Delphi XE sea peor que Delphi 7, ¡estoy diciendo que no es mejor!

¡Hemos actualizado de Delphi 7 a través de Delphi 2007, 2009 y ahora 2010! Los siguientes son los problemas más grandes que hemos encontrado.

  • Los hilos han cambiado, con Reanudar y Suspender en desuso.
  • Unicode
  • La estructura de los proyectos ha cambiado y no son compatibles con versiones anteriores.
  • La estructura de dfms ha cambiado y no es compatible con versiones anteriores

Espero que esto ayude.

Convertir código a Unicode no toma mucho tiempo en sí mismo siempre y cuando no hagas nada "divertido" con tus cuerdas. Convertí cerca de 1 millón de líneas de código + la base de datos en menos de 2 semanas. Los chicos de Codegear hicieron un muy buen trabajo haciéndolo mucho más simple.

Su código podría recompilarse en D2010 sin ningún cambio (pero con bastantes toneladas de sugerencias / advertencias).

El peor problema de la conversión proviene de las llamadas a la API de Windows que se hicieron incorrectamente. Por ejemplo, la función GetComputerName que le pregunta el tamaño del búfer en TChars (según lo especificado por la API). En Ansi, TChar = 1 byte, entonces Length = SizeOf. En Unicode, ya no es cierto. Peor aún, la llamada a la API podría no fallar. Solo sobrescribirá una parte válida de la memoria y se bloqueará mucho más tarde.

Oh ... Y también hay esas pequeñas diferencias entre Ansi y Unicode en la API de Windows. Por ejemplo, la lpCommandLine de CreateProcess es de solo lectura en la versión Ansi, pero de lectura / escritura en la versión Unicode. Entonces, usar una constante como parámetro funcionó bien en Ansi, pero se bloqueará en Kernel32.dll en Unicode.

En general, depende mucho de la calidad del código con el que está trabajando. El código incorrecto puede ser muy difícil de portar a D2010. Buen código debería ser bastante fácil.

y lee los recursos a los que Nick Hodges ha vinculado, son bastante útiles.

Estoy de acuerdo con Chris: el mayor problema en la migración de nuestro código a 2010 fue hacer funcionar todas las bibliotecas de terceros. Algunos de ellos necesitaron modificaciones menores de origen aquí y allá y tuvieron que instalarse desde el origen modificado. Aún así, eso decía que no era más que un día o más de arreglar las cosas.

El único otro problema que hemos tenido al pasar a 2010 involucró a una pequeña sección de código que falló debido a un cambio en la forma en que funciona ProcessMessages de 2010. Era un fragmento de código antiguo que probablemente no debería haberse escrito de la forma en que comenzó (ProcessMessages y Sleep () dentro de un bucle while esperando en un cambio de variable OPC). Funcionó en 2007, pero en 2010 devoró de algún modo los mensajes del sistema y bloqueó el servidor OPC. Para nosotros fue una pequeña solución, pero como dijo Ken, probablemente dependerá de la calidad del código que esté transfiriendo. 2010 parece un poco menos tolerante a la mala práctica y los trucos feos.

Hemos creado una página web específicamente para este mismo problema:

http://www.embarcadero.com/rad-in-action/migration-upgrade-center

Allí, puede encontrar páginas web, documentos, repeticiones de seminarios web, etc. que cubren el problema de la migración.

Lo primero que dice la gente es "Tengo una base de código enorme, y migrar a Unicode durará para siempre" y casi sin excepción, descubren que "para siempre" es realmente un período de tiempo mucho más corto de lo que originalmente pensaron y que las nuevas características de Delphi 2010 hace que todo valga la pena.

Los mayores problemas son con las bibliotecas de terceros y VCL. Si no están en D2010, puede ser doloroso. El problema de Unicode surge si está haciendo cálculos con la longitud de las cadenas o los arrays de PChar, asumiendo un byte por carácter. Por lo general, puede salirse con la suya tratando todo como AnsiString / AnsiChar de estilo antiguo. Pero entonces no obtienes los beneficios de Unicode. Si no tiene nada que sea difícil de hacer en Unicode, solo haga todo en Unicode y estará mucho más adelantado que si tiene que preocuparse por cambiar de un lado a otro.