Xailer permite realizar varios tipos de operaciones de Drag & Drop, que son:
Muchos de vosotros estáis usando el evento OnInitialize de los formularios para realizar tareas de inicialización de algunos controles, carga de valores iniciales, etc.. Pero algunos lo están usando simplemente porque alguien les ha dicho que hagan esas tareas en ese evento, sin llegar a conocer realmente el porqué.
En este artículo intentaré aclarar los pasos que se ejecutan durante el proceso de creación de un formulario, incluido el momento en que se disparan algunos eventos. De esta forma, todos podrán tener más claro donde y cuando usar un evento u otro.
Muchos de vosotros ya conocéis que la jerarquía de clases de Xailer es bastante extensa y que, además, tiene la mayoría de estas clases duplicadas entre clases X y clases T. Concretamente, la jerarquía es algo así:
XComponent -> TComponent -> XWinObject -> TWinObject -> XControl -> TControl -> etc.
En la jerarquía que aparece en la ayuda no se muestra esta dualidad de clases, sino que aparecen sólo las clases T. Pero realmente existen también las clases X, y son precisamente estas las que contienen todo el código, permaneciendo las clases T completamente vacías. P.ej., la clase TControl está declarada así:
CLASS TControl FROM XControl
ENDCLASS
Y ahora bien, ¿para qué queremos tener las clases duplicadas? ¿qué conseguimos con esto?
En el artículo anterior vimos cómo se podía cambiar el código de arranque de una aplicación Xailer, de forma que se ejecute una función donde podemos hacer lo que queramos. Pues bien, ahora vamos a ver qué debemos poner en esa función para mostrar una ventana de entrada, al mismo tiempo que mostramos la ventana principal del programa; pero además, antes de dejar al usuario acceder a sus opciones, mostraremos la típica ventana de validación de usuario y contraseña y si no son correctos, abandonaremos el programa.
Cuando comenzamos un nuevo proyecto con Xailer, lo habitual es crear el proyecto y crear el formulario principal de la aplicación. Esto nos crea dos módulos fuente: uno con el mismo nombre del proyecto y otro con el nombre con que hayamos grabado el formulario.
Tradicionalmente en xBase el control de errores en el manejo de bases de datos se ha realizado a priori, es decir, se evitaba que se produjese ningún error de ejecución y para ello se utilizaban funciones como RLock(), FLock() o NetErr(). RLock() y FLock() son funciones que permiten realizar actualizaciones cuando el fichero DBF no es abierto en modo exclusivo, y NetErr() permite comprobar basicamente si una operación USE o APPEND BLANK se ha producido correctamente. Lógicamente con Xailer puede seguir utilizando este mismo sistema.