¿Algún consejo para aquellos que quieren actualizar de Delphi 7 (y hacia abajo) a Delphi 2010?

Question

Después de la actualización 4 y 5, estoy interesado en volver a evaluar Delphi 2010. Esta vez tengo la intención de transferir 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 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 desea actualizar) sería:

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

Is WideString identical to String in Delphi 2009

What is the compiler version for Delphi 2010?

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

Tenga en cuenta que el GIF (por Melander) y PNG (por Martijn Saly?) Las imágenes ahora se incorporan en Delphi 2010. Se tendrán que utilizar un condicional con el fin de utilizar la unidad GIF derecha:

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

también es necesario "fijar" el PNG proporcionada por Embarcadero: http://talkdelphi.blogspot.com/2009_03_01_archive.html

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

---

ACTUALIZACIÓN

fin he mejorado. Delphi XE tiene algunas características nuevas. Desafortunadamente, muy pocos de ellos no funcionan en absoluto (compilación de fondo, modelado UML, visión del 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 desagradable error donde el IDE tiene un 100% de utilización de 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 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 obtener ese compilador. Para aquellos que todavía están pensando en actualizar a Delphi XE, recomendaría probar Delphi XE antes de comprarlo para ver si ofrece algunas características que de otro modo no están disponibles. No digo que Delphi XE sea peor que Delphi 7, ¡estoy diciendo que no es mejor!

Answer 1

Hemos creado una página web específica para este mismo tema:

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

Allí, se puede encontrar páginas web, documentos, repeticiones de seminario, etc., que cubren todos el tema de la migración.

Lo primero que dicen es "Tengo una gran base de código y migrar a Unicode llevará una eternidad" y casi sin excepción descubren que "para siempre" realmente es un período mucho más corto de lo que originalmente pensaban y que el las nuevas características de Delphi 2010 hacen que todo valga la pena.

Answer 2

Los mayores problemas se encuentran con las bibliotecas de terceros y VCL. Si no están en D2010, puede ser doloroso. El problema Unicode aparece si está haciendo cálculos con la longitud de las cadenas o matrices PChar, suponiendo un byte por carácter. Por lo general, puede salirse con la suya tratando todo como AnsiString/AnsiChar de estilo antiguo. Pero luego no obtienes los beneficios de Unicode.Si no tienes nada que sea difícil de hacer en Unicode, simplemente haz todo en Unicode y estarás mucho más adelante que si tienes que preocuparte por cambiar de un lado a otro.

Answer 3

Convertir código a unicode no toma tanto tiempo en sí mismo siempre que no haya hecho nada "divertido" con sus cadenas. Convertí cerca de 1m líneas de código + la base de datos en menos de 2 semanas. Los chicos de codegear hicieron un muy buen trabajo al hacerlo mucho más simple.

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

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

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

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

y leyó los recursos con los que Nick Hodges se relacionó, son bastante útiles.

Answer 4

Para problemas de conversión Unicode, su mejor apuesta para ver los problemas que las personas han encontrado y lo que otros han hecho es obtener Cary Jenson's White Paper: Delphi Unicode Migration for Mere Mortals.

También recomiendo Marco Cantu's "Delphi 2009 Handbook" que describe todos los cambios en la versión Major 2009 que incluye Unicode y genéricos y más. Gran parte de su material Unicode de ese libro está en his White Paper: Delphi and Unicode.

Answer 5

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

• Los subprocesos han cambiado, y se está desaprobando el currículum y la suspensión.
• Unicode
• La estructura de proyectos han cambiado y no son compatibles
• La estructura de la DFMS han cambiado y no son compatibles

Espero que esto ayude.

Answer 6

Estoy de acuerdo con Chris: el mayor problema para migrar nuestro código al 2010 fue hacer funcionar todas las bibliotecas de terceros. Varios de ellos necesitaron ediciones menores de fuentes aquí y allá y tuvieron que ser instalados desde la fuente modificada. Aún así, eso dijo que no había pasado más de un día para resolver las cosas.

El único otro problema que hemos tenido al pasar al 2010 involucró una pequeña sección de código que presentó errores debido a un cambio en la forma en que funciona el ProcessMessages de 2010. Era una pieza antigua de código que probablemente no debería haber sido escrita de la manera en que estaba para comenzar (ProcessMessages y Sleep() dentro de un ciclo while esperando un cambio de variable OPC). Funcionó en 2007, pero en 2010 devoró los mensajes del sistema y bloqueó el servidor OPC. Para nosotros fue una solución pequeña, pero como Ken dijo, probablemente dependerá de la calidad del código que está portando. 2010 parece ser un poco menos tolerante con las malas prácticas y los feos hacks.