Desarrollando desde la trinchera.

Siempre que sea posible, queda mas claro el código para entenderlo mas rapido, cuando se cheque que un booleano sea verdadero (TRUE) en vez de chequear por falso (FALSE).  Por ejemplo, si tenemos // &Not_Authorized es booleano que indica que el usuario no esta autorizado.  if NOT &Not_Authorized      Operacion() else     Msg('Usuario no autorizado') endif es bastante mas difícil de leer que   //&User_Authorized es un boolean que indica si usuario esta autorizado if &User_Authorized    Operación() else    Msg('Usuario no autorizado') endif Tenemos que recordar que el codigo deberia ser lo mas simple posible de entender como cualquier texto en ingles o pseudocódigo y por lo tanto tener en cuenta el nombre y la semántica de las variables booleanas, es algo importante que ayuda entender más fácil.  Este es algo muy sencillo de hacer en el momento que defino la variable booleana, y simplifica su uso posterior.  Son los pequeños detalles que se sumados hacen l

  En algunas ocasiones pasa (generalmente en cambios de versión de GeneXus) que da un error al comprimir los archivos javascript.  Si bien el mensaje es claro, es un warning y el proceso de build all termina con éxito. Por este motivo, a veces no se detecta el problema hasta que llega a producción y es mucho mas caro de corregir.  Por eso, recomiendo mucho sobre todo en las primeras especificaciones/generaciones/compilaciones de una KB en una nueva instalación, prestar especial atención a la compresión de los archivos javascript.  Un caso real Por ejemplo, el caso de la imagen, había un webpanel programado sin pattern que utilizaba un User Control que se instalaba con un Pattern.  Al cambiar la versión del Pattern, se actualizo el UC, cambiando de nombre y todos los objetos generados con el mismo pasaron a utilizar la nueva versión del UC, pero éste webpanel siguió usando el  UC viejo, que ya no estaba instalado.  Al especificarlo, no daba ningún warning y compilaba sin errores.  Solo