FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Cambiar de Version en Delphi es Problematico
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
|
#2
|
||||
|
||||
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...!!! |
#3
|
||||
|
||||
Cita:
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. |
#4
|
|||
|
|||
El futuro es incierto
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 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 valdria la pena recuperarlas |
#5
|
||||
|
||||
Cita:
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. |
#6
|
|||
|
|||
Cita:
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. |
#7
|
||||
|
||||
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. |
#8
|
|||
|
|||
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
|
#9
|
||||
|
||||
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 |
#10
|
|||
|
|||
Cita:
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. |
#11
|
||||
|
||||
ASAPLTDA, ¿te has parado a pensar que TUS clientes estarán diciendo lo mismo de tu programa?
Malos días los tenemos todos... y lo sé muy bien porque llevo 1 semana portando un programa de D7 a D2010 , 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...
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#12
|
||||
|
||||
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, |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
delphi 7 problematico? | anubis | Debates | 6 | 03-02-2011 12:44:15 |
ColorBox Problematico??? | Saindoft | Varios | 1 | 03-06-2008 12:13:10 |
DbGrid problemático | citlalliDgp | OOP | 1 | 27-12-2007 04:53:58 |
como puedo hacer para cambiar un archivo de excel con versión 2.1 a versión 8.0 | RONPABLO | Servers | 4 | 23-01-2006 06:02:38 |
El problemático UPDATE!!! | ciscu | SQL | 3 | 10-02-2004 20:26:13 |
|