Eliminar Styles de KB en GeneXus X.
Si realizamos una migración de GeneXus 9.0 (o anteriores) a la X, los objetos convertidos mantienen una referencia a los Styles, pero como no existen como objetos, dicha referencia queda apuntando a objetos que se almacenan en la "carpeta" TO BE DEFINED.
En general, joroban bastante poco, pero cuando se quieren subir objetos con dichas referencias al GXServer, dan problemas, pues el GeneXus Server no maneja los objetos Styles.
Si se quiere eliminar dicha referencia, se debe hacer:
1) Distribuir todos los objetos que usen Styles en la GeneXus X.
2) Descomprimir el xpz generado en 1) y salvar el xml.
3) En dicho XML, eliminar el texto:
<Property><Name>ObjStyle</Name><Value>497c0353-2904-4b7e-8711-d0ca41ac4460-ObjectsStyles_TTrnSEliminar</Value></Property>
donde el texto en rojo depende del nombre del style, y el identificador interno.
4) Volver a consolidar los objetos.
De esta forma, se eliminan todos los rastros de los styles en la KB.
Consulta casi sobre el mismo tema.. si tenia aplicado patter ww con el THEME FANTASTIC en la version 9, ahora que migre a la version GX XEvo1, especialmente en los webPanel que estan WebComponen con TAB me trae colores distintos, afectados en el BackgroundColor y los Forecolor.
ResponderBorrarhay una forma de llevar las clases o cual seria el mecanismo adecuado para que pueda tener el mismo look & Feel
Podes revisar que clases usabas en la 9.0 y volver a definirlas en la X.
BorrarLa forma mas facil de hacerlo es con alguna herramienta que permita ver cuales elementos tiene el html, uno bueno es con Chrome con la opcion Inspect element.
Enrique, nos ha sido muy útil lo que venís posteando sobre cómo migrar a la X. Donde trabajo venimos cerrando la migración de una KB de 7400 objetos. Por ser una KB grande en un equipo de trabajo de muchas personas, organizamos el trabajo en forma iterativa, adelantando lo más posible en la propia versión 9, a medida que quemábamos cada etapa (abrir la KB en la X, conseguir que especifique, que cierren las navegaciones, etc.). La idea era ir haciendo la versión 9 "X-friendly", y dejar un log de los problemas que se podrían resolver una vez migrado.
ResponderBorrarLa mayoría de los problemas surgieron porque la X es más fuertemente tipada que la 9, y en general no perdona las desprolijidades que permitía la 9.
Como anécdota, de los problemas encontrados, el que necesitó una solución más rebuscada fue el de las DYNAMIC CALLS en la función LINK: A diferencia de la 9, el generador XEV1, cuando se encuentra con una llamada tipo "link(&variable)", expande las dynamics calls, algo que no hacía en la 9 aún si estaba seteada la respectiva propiedad. No queríamos cambiar esa propiedad, para no perder información de llamadores y llamados. El problema es que a veces se generan fuentes demasiado largos. Eso provoca el error de compilación "code too large". No encontré forma de decirle al javac que pase por alto esto, los fuentes están topeados a 64k.
Al final se trató con el siguiente work around: se cambió el link común por una llamada tipo "link(att:AttAuxiliar)".
Basta con que AttAuxiliar sea algún atributo de una tabla auxiliar donde se vayan grabando URLs en forma temporal. Es rebuscado y poco eficiente, pero te saca del paso.
Saludos!
Mariano:
ResponderBorrarGracias por el comentario y me alegra que te sirva mi blog.
Con respecto a tu wa sobre los call dinámicos, lo tomare en cuenta. Personalmente, prefiero no usar la expansión automática de calls dinámicos, pues en Kb grandes trae problemas.
Prefiero agregar código de la forma
call(&variable)
If &i = &i+ 1
Pgm1.call()
Pgm2.call()
.....Lista de todos los programas que van a ser llamados en forma dinámica
Endif
y no expandir los call dinámicos.
De esa forma mantenéis visible el árbol de calls y las dependencias, y no agrega código innecesario en los exes. Tampoco tenes problemas al compilar.