Ver la Versión Completa : Cambiar de Version en Delphi es Problematico
ASAPLTDA
16-03-2011, 03:39:15
Estoy usando delphi desde la version de delphi 2 o 3 y cada vez que sale una nueva version dan ganas de llorar :( Uno toma sus programas fuentes y algun otro componente de un tercero y empieza cristo a padecer empiezan a salir errores por todo lado. No es que estoy en contra del cambio ni de la mejora Pero imaginese a uno tener que volver a escribir los reportes otra vez y otra vez Primero Report Smith, luego quick Reports luego chachachara y quien sabe otro invento. Creo que ya es hora de enterder que el software es el trabajo de cientos de horas cientos de dias y varios anos de esfuerzo para que no halla consistencia porque al senor x y se le ocurrio cambiar la unidad x al la unidad y , eso que aporto? Solo que cientos de programas no se puedan mover de un nivel de version a otra, cuantos cientos de programadores sufren las consecuencias? . He trabajado durante muchos anos en sistemas as400 y antes de los sistemas 32/34/36 y aun ahora existen programas con 30 o mas anos de existencia y siguen funcionando sin importar el cambio de version de sistema operativo. en delphi se llamria delphi V delphi XE .... etc pero cada vez que cambia el ano las jodas dejan de funcionar . No se si estoy equivocado soy programador de aplicaciones no mantenedor de codigo por cambio de versiones . Si existen comentarios a favor me encanta oirlos o los en contra mejor para saber porque no tengo la razon
gatosoft
16-03-2011, 05:46:28
pues no se que decir compañero...
yo he tenido experiencias de migración y algunas han sido muy traumáticas, pero te puedo decir finalmente que el problema radica en no haber pensado en el futuro... principalmente cuando escoges un componente de tercero, que es libre o pago, y que con el paso del tiempo deja de tener soporte...
yo tuve que migrar una aplicación desde delphi 3,con paradox a Delphi 2009 con Sql-Server y si no hubiese sido por estios componentes de terceros, muchas cosas hubiesen pasado con simplemente compilar... de hehco la migración consistio en retirar todos los componentes basura (que ya no tenian soporte) y cambiarlos por componentes estandar, o crear métodos que los reemplazaran...
Muchas funcionalidades o adornos se perdieron, pero la funcionalidad básica quedó intacta... se paga un precio...
Bueno amigo ASAPLTDA, mucha suerte con tu migración y saludos a Johnny por alla en Cali...!!!
Casimiro Notevi
16-03-2011, 11:32:10
[..]He trabajado durante muchos anos en sistemas as400 y antes de los sistemas 32/34/36 y aun ahora existen programas con 30 o mas anos de existencia y siguen funcionando sin importar el cambio de version de sistema operativo. en delphi se llamria delphi V delphi XE .... etc[..]
Bueno, amigo, es muy distinto cambiar de delphi que cambiar de sistema operativo.
Los programas que hablas seguramente están hechos en cobol y los cambios que se hacen en esos sistemas AS400 y demás que has mencionado son mínimos en años y años, prácticamente son iguales, sin embargo no tiene nada que ver con los cambios/mejoras de un IDE y componentes que se actualizan de versión a versión.
Debes tener en cuenta lo comentado por gatosoft, hay que pensar en el futuro y hacer las cosas "estandares", lo más simple posible sin meterse en lios con componentes bonitos y llamativos que lo mismo desaparecen en un año y luego ya no puedes actualizar el sistema.
ASAPLTDA
16-03-2011, 16:09:47
Es cierto que algunos componentes de terceros desaparecen, pero el problema es que no solo los componentes de terceros lo son son los mismos elelementos de trabajo que da delphi , recuerdan quickreports? desapaprecion de borlan , recuerdan report smith desaparecion de borland .
Pr no hablar de las funciones/procedimientos que cambian de clases :eek:
Ahora si comparas un as400 de hoy con hace 10 anos te puedo decir que si ha cambiado y mucho
Ahora toca usar algunos componentes de terceros por ejemplo no tengo la version para usar bases de datos me toca usar SQL-DIRECT , algunos recomiendan ZEUS Pero esta absoleta .
Estoy usando SdfData Application de Author : Orlando Arrocha email: oarrocha@hotmail.com para cargar arhivos de texto, es excelente pero en delphi xe no funciona, los fuentes estan en Torry pero no tengo el conocimiento para actualizarlas :mad: valdria la pena recuperarlas
Casimiro Notevi
16-03-2011, 16:52:43
[..] Ahora si comparas un as400 de hoy con hace 10 anos te puedo decir que si ha cambiado y mucho [..]
Pero el as400 es el "aparato", que puede llevar el SO os400 e incluso en los últimos modelos creo que incluso linux, windows o el unix de ibm, el aix.
Seguro que un programa que funciona en os400 no funcionará en windows, por decir algo.
Lo que comentas es así, por eso es lo que decíamos antes, hay que pensar en el futuro, a veces es dificil acertar en las herramientas, por ejemplo, supongo que aunque delphi ya no venga con quickreport, me imagino que se podrá comprar por separado o quizás de primera hora se tendría que haber elegido otro "reporteador" externo a delphi, en fin, nadie es adivino, creo que casi todos hemos sufrido esos problemas que comentas.
Pero el as400 es el "aparato", que puede llevar el SO os400 e incluso en los últimos modelos creo que incluso linux, windows o el unix de ibm, el aix.
Seguro que un programa que funciona en os400 no funcionará en windows, por decir algo.
No te creas... Hace 10 años trabajaba en una empresa de software donde se programaba principalmente en RM-Cobol. La versión inicial del programa lo habían hecho para Xenix/286, se había portado a MS-DOS, a Novell Netware, y a Windows sin cambiar ni una coma del programa, y dicha aplicación se había pasado a AS/400 (o quizá era un System/36?? No sé, un cacharro grande de IBM) sin modificar el código fuente.
Esto en Delphi es difícil de hacer, por el simple motivo que no hay un estándar... Hoy (Delphi XE) un String es un conjunto de hasta 65535 WideChar (16 bit). Hace 5 años (Delphi 2006), un String era un conjunto de hasta 255 Char (8 bit).
Es mala esta evolución? Para nada. Pero tenemos el inconveniente que a veces se rompe completamente la compatibilidad hacía atrás.
Casimiro Notevi
16-03-2011, 20:48:32
Cierto, lo sé por experiencia, con RM-Cobol es posible ejecutar el mismo programa en msdos, xenix, unix, windows (como programa msdos), etc. y todo eso con tan sólo compilarlo. Pero no puedes comparar, no tiene nada que ver eso con delphi.
Aunque hoy en día también hay entornos gráficos y IDEs para cobol, pero seguramente ya no serán compatibles entre distintos sistemas.
ASAPLTDA
16-03-2011, 21:15:11
No te creas... Hace 10 años
Es mala esta evolución? Para nada. Pero tenemos el inconveniente que a veces se rompe completamente la compatibilidad hacía atrás .
La evolucion es importante pero tambien la comptabilidad hacia adelante, si estoy migrando de delphi 5 a XE dberia ser compatible, porque cada ano si uno actualiza el IDE le tocara cambiar de nuevo los programas y sobre esto creo que es importante hablar compatabilidad porque cada ano al actualzizar el IDE por mejorar me toca revisar un poco de cosas que dolor de cabeza:mad:
Casimiro Notevi
16-03-2011, 21:58:50
El programa de gestión que tenemos en mi trabajo se empezó a programar en 1999 con delphi 5 y seguimos todavía con delphi 5 porque cambiarlo sería costosísimo en tiempo, dinero y trabajo.
Lo de la compatibilidad hacia adelante... no sé, depende, el problema es el de siempre, que hay cosas que son muy difíciles de mantener, se engordan los programas con parches para mantener la compatibilidad de las versiones anteriores y al final salen cosas como... windows :D:D:D
La evolucion es importante pero tambien la comptabilidad hacia adelante, si estoy migrando de delphi 5 a XE dberia ser compatible, porque cada ano si uno actualiza el IDE le tocara cambiar de nuevo los programas y sobre esto creo que es importante hablar compatabilidad porque cada ano al actualzizar el IDE por mejorar me toca revisar un poco de cosas que dolor de cabeza:mad:
no has programado con visual C de microsoft.
de los programas que he compilado den visual c 6, no
compilan en visual c 2003, 2005 y asi.
si tu programa compila bien en una version
en la siguiente casi siempre da errores
y eso que no usa componentes de terceros.
cimplemente, puro C++ y los componentes standar de visual studio.
erorr tras error de compilacion
yo al contrario.
he programdo con delphi 1 hasta 2007
y el codigo. bien facil de portar excepto por
las versiones intermedias de delphi 6 con la porqueria de CLX incrustada
y delphi 7, de ahi sin CLX se porta facililismo.
menos en delphi 2009 en adelante.
aun no hay componentes nativos para soportar unicode.
en el procesamiento de archivos de textos
que se generan en sistema Ansi. y que tienen que manejar texto
en chino. mi caso mucho problema por que hay que hacerlo bien.
pero pronto.
ASAPLTDA, ¿te has parado a pensar que TUS clientes estarán diciendo lo mismo de tu programa? :D :eek:
Malos días los tenemos todos... y lo sé muy bien porque llevo 1 semana portando un programa de D7 a D2010 :D, me ha asombrado que todo el código compile perfectamente y sólo falle un 0.005 % que encima son componente de terceros (por el unicode).
Un cafelito (o té) y pa'lante compañero de fatigas...
Delphius
17-03-2011, 18:08:48
Hola,
Con todo respeto me cuesta creer que sea tan problemático un cambio desde una versión anterior de Delphi a una nueva. Si hay algo que ha caracterizado a Delphi es la de mantener la compatibilidad.
Es bien cierto que de vez en cuando se necesita romper esa compatibilidad, como es el caso de la llegada de Unicode que si bien ha traído algunos problemas y confusiones en el mismo sentido se ha generado documentación explicando el tema... ¡vamos que tampoco es para armar un escándalo, se ha cambiado un tipo! Tocará de narices el código, pero oye... ese cambio no lo tendrás que hacer de nuevo versión tras versión.
El problema que tienes se debe más a una enfermedad que yo he llamado componentitis externitis. Los síntomas de esa enfermedad hacen que el desarrollador prefiera, pruebe, pondere y aprecie más los componentes de terceros que los propios.
Evidentemente si uno se pasa de rosca de poner cosas de terceros es más probable que tenga más de un problema al pasar de versión a otra ya que no necesariamente habrá soporte. Pero, si uno prefiere y se centrara más en los propios o los "in the box" o "de fábrica", como prefieran llamarles, se reduce drásticamente cualquier dolor y malestar.
En lo si te puedo aceptar es el tema de reportes, parece que no se deciden por cual tener... pero en lo demás, me parece que estás exagerando.
Saludos,
vBulletin v3.6.8, Derechos ©2000-2024, Jelsoft Enterprises Ltd.