Cómo nos cobra Clarion el tiempo que nos hace ganar
Publicado: Mié Jun 22, 2011 2:46 pm
En reiteradas oportunidades he dicho que si bien a Clarion no hay con qué darle en el momento del inicio de cualqueir proyecto, en algún momento te cobra el tiempo ganado.
Que en el inicio no hay con qué darle no necesita muchas explicaciones: una vez creado el diccionario es cuestión de unos pocos clics para tener una aplicación completamente funcional para la carga de los datos.
En cuanto a que en algún momento te cobra el tiempo ganado, y con creces, voy a presentar algunos casos.
Caso 1:
En un proyecto multi DLL tengo una de las aplicaciones que me está dando dos errores de compilación indicados como "Unkown procedure label". Si voy a uno de los errores efectivamente se trata de la definición de un procedimiento que está en una DLL. Pero el nombre está bien, tiene el atributo DLL, los parámetros son los correctos y está dentro del módulo correspondiente a la DLL. Además en el mismo módulo tengo otros procedimientos que no me dan problema. Revisé también la DLL con LibMaker y el procedimiento está correctamente incluido.
Pero si voy al otro error, también marcado como "Unkown procedure label", en realidad apunta a la definición de un campo dentro de una estructura de tipo FILE. Si bien sería posible que el campo no existiera en el archivo, ese error no debería saltar hasta el momento de la ejecución del programa cuando intentara abrir el archivo. Evidentemente el error está apuntando a la línea equivocada. Por eso sospecho que ambos errores están apuntando a otra línea.
Llevo dos días luchando contra este problema y aún no lo he resuelto. Volvía a revisar todo porque suponía que algún error tonto debía estar cometiendo, que algún detalle se me estaba escapando. Si le agregamos que con Clarion 7 nunca estamos seguros de que el código está generado correctamente (falla al detectar que tiene que volver a generar el código) la inseguridad es enorme. Uno vuelve al panel de aplicaciones para una regeneración incondicional, con todo el tiempo que eso implica.
Finalmente me convencí de que los errores están apuntando a las líneas equivocadas y publiqué en el foro de SV una consulta a ver si hay algún antecedente y alguna solución. Pero el tiempo perdido no me lo va a devolver nadie, y reitero que sigo sin resolverlo todavía.
Caso 2:
Tengo un Report de un recibo que consiste en el recibo en sí más un tique. Cuando el cajero cobra le entrega el recibo al cliente y se queda con el tique. Tanto en el recibo como en el tique están la fecha y la hora de emisión. Ambos controles están definidos exactamente iguales, con el ancho por defecto (default). Pues bien, en el tique la fecha y la hora se imprimen correctamente, pero en el recibo salen con numerales (#), como que los controles se desbordaran. Reitero que en los dos casos las definiciones eran exactamente iguales. En el recibo tuve que agrandarle el ancho para que se solucionara. En este caso el tiempo perdido no fue tanto, pero como es un aplicación que migré de Clarion 6 a Clarion 7, ahora tendré que revisar todos los Report de la aplicación para asegurarme de que funcionan.
Caso 3:
Como expresé en el caso 1, Clarion 7 falla al detectar que tiene que volver a generar el código de un procedimiento. Así que encuentro un error, hago un cambio en el código embebido, vuelvo a generar y compilar la aplicación, pero el error persiste. Si todo fuera normal (como era en Clarion 6) si el error continúa volvería a revisar el código embebido porque algo se me escapó. Pero como es Clarion 7 y creo que el cambio que hice en el código embebido debería solucionar el problema, por las dudas voy al panel de aplicaciones y hago una regeneración incondicional. Es posible que haya vuelto a compilar el mismo código fuente que no incluía mi corrección. Si la aplicación es un poco grande esto puede llevar su tiempo. En algunos casos, efectivamente había fallado la regeneración y todo se soluciona. Pero en otros, realmente se nos había escapado algún detalle y lo que creíamos que solucionaba el problema en realidad no lo hacía, así que la regeneración incondicional fue tiempo completamente perdido.
Esto de la falla al regenerar el código me parece un problema inaceptable, así como la incapacidad de SV para resolverlo. Pero mientras tengamos aplicaciones en Clarion tendremos que convivir con eso.
Conclusión:
Con estos tres casos queda explicado por qué el tiempo que Clarion nos hace ganar en el inicio del proyecto nos lo cobra más adelante. Y dado que el tiempo de vida de una aplicación es muchísimo más grande que el tiempo que implica su desarrollo, es muy probable que el tiempo que Clarion nos hace perder en el mantenimiento de una aplicación supere en mucho el tiempo ahorrado en el inicio.
Que en el inicio no hay con qué darle no necesita muchas explicaciones: una vez creado el diccionario es cuestión de unos pocos clics para tener una aplicación completamente funcional para la carga de los datos.
En cuanto a que en algún momento te cobra el tiempo ganado, y con creces, voy a presentar algunos casos.
Caso 1:
En un proyecto multi DLL tengo una de las aplicaciones que me está dando dos errores de compilación indicados como "Unkown procedure label". Si voy a uno de los errores efectivamente se trata de la definición de un procedimiento que está en una DLL. Pero el nombre está bien, tiene el atributo DLL, los parámetros son los correctos y está dentro del módulo correspondiente a la DLL. Además en el mismo módulo tengo otros procedimientos que no me dan problema. Revisé también la DLL con LibMaker y el procedimiento está correctamente incluido.
Pero si voy al otro error, también marcado como "Unkown procedure label", en realidad apunta a la definición de un campo dentro de una estructura de tipo FILE. Si bien sería posible que el campo no existiera en el archivo, ese error no debería saltar hasta el momento de la ejecución del programa cuando intentara abrir el archivo. Evidentemente el error está apuntando a la línea equivocada. Por eso sospecho que ambos errores están apuntando a otra línea.
Llevo dos días luchando contra este problema y aún no lo he resuelto. Volvía a revisar todo porque suponía que algún error tonto debía estar cometiendo, que algún detalle se me estaba escapando. Si le agregamos que con Clarion 7 nunca estamos seguros de que el código está generado correctamente (falla al detectar que tiene que volver a generar el código) la inseguridad es enorme. Uno vuelve al panel de aplicaciones para una regeneración incondicional, con todo el tiempo que eso implica.
Finalmente me convencí de que los errores están apuntando a las líneas equivocadas y publiqué en el foro de SV una consulta a ver si hay algún antecedente y alguna solución. Pero el tiempo perdido no me lo va a devolver nadie, y reitero que sigo sin resolverlo todavía.
Caso 2:
Tengo un Report de un recibo que consiste en el recibo en sí más un tique. Cuando el cajero cobra le entrega el recibo al cliente y se queda con el tique. Tanto en el recibo como en el tique están la fecha y la hora de emisión. Ambos controles están definidos exactamente iguales, con el ancho por defecto (default). Pues bien, en el tique la fecha y la hora se imprimen correctamente, pero en el recibo salen con numerales (#), como que los controles se desbordaran. Reitero que en los dos casos las definiciones eran exactamente iguales. En el recibo tuve que agrandarle el ancho para que se solucionara. En este caso el tiempo perdido no fue tanto, pero como es un aplicación que migré de Clarion 6 a Clarion 7, ahora tendré que revisar todos los Report de la aplicación para asegurarme de que funcionan.
Caso 3:
Como expresé en el caso 1, Clarion 7 falla al detectar que tiene que volver a generar el código de un procedimiento. Así que encuentro un error, hago un cambio en el código embebido, vuelvo a generar y compilar la aplicación, pero el error persiste. Si todo fuera normal (como era en Clarion 6) si el error continúa volvería a revisar el código embebido porque algo se me escapó. Pero como es Clarion 7 y creo que el cambio que hice en el código embebido debería solucionar el problema, por las dudas voy al panel de aplicaciones y hago una regeneración incondicional. Es posible que haya vuelto a compilar el mismo código fuente que no incluía mi corrección. Si la aplicación es un poco grande esto puede llevar su tiempo. En algunos casos, efectivamente había fallado la regeneración y todo se soluciona. Pero en otros, realmente se nos había escapado algún detalle y lo que creíamos que solucionaba el problema en realidad no lo hacía, así que la regeneración incondicional fue tiempo completamente perdido.
Esto de la falla al regenerar el código me parece un problema inaceptable, así como la incapacidad de SV para resolverlo. Pero mientras tengamos aplicaciones en Clarion tendremos que convivir con eso.
Conclusión:
Con estos tres casos queda explicado por qué el tiempo que Clarion nos hace ganar en el inicio del proyecto nos lo cobra más adelante. Y dado que el tiempo de vida de una aplicación es muchísimo más grande que el tiempo que implica su desarrollo, es muy probable que el tiempo que Clarion nos hace perder en el mantenimiento de una aplicación supere en mucho el tiempo ahorrado en el inicio.