[titulo]
Formularios en Componentes de Código Técnicas Depuradas para Suministrar Formularios desde Componentes ActiveX con Visual Basic
Parte I, Formularios Modales en Proceso [/titulo]
|
Suministrar Formularios desde componentes es una buena estrategia de desarrollo. Los formularios ocupan espacio considerable en el ambiente de desarrollo de un proyecto. No es necesario mantener cada formulario en el proyecto principal, de hecho el único formulario de una aplicación podría ser el inicial, hablando técnicamente el Front End de la solución. Empaquetar formularios en componentes de código permitirá a una aplicación robusta evolucionar en tamaño y desarrollo libre de sobrecarga. Sin embargo, usar Formularios en Componentes tiene su intríngulis y suele ser un tema relativamente nuevo para programadores Visual Basic corrientes, quizá extraño y difícil. Puede que Ud. haya empacado ya muchos formularios en componentes de código, sin embargo, los modelos que sugiero en este articulo son altamente competentes, y representan una alternativa simple y robusta al mismo tiempo. |
Inicialmente pense escribir este articulo para que cubriera los formularios modales y no modales, sin embargo el escrito se extendió tanto, que decidí dividirlo en dos partes: en (1) Formularios Modales en Componentes en Proceso, (2) Formularios no Modales en Componentes en Proceso, con alguna nota sobre formularios en componentes fuera de proceso.
Otra difícil decisión que tuve que tomar fue: ¿Escribo todo basado en interfaces múltiples, o uso el estilo tradicional?. Vaya decisión. Si me decidia por usar interfaces, quizás programadores noveles e intermedios en Visual Basic no leerían este articulo, o quiza lo leerían y perciban un extraño modo de hacer difícil las cosas fáciles. La programación orientada a Interfaces presenta unos perfiles si no avanzados, poco frecuentes entre programadores (en especial aquellos que vienen de la antigua OOP), y reviste mayores explicaciones que pueden terminar en desanimar al lector. De otro lado la programación tradicional será aceptada inmediatamente en todos los niveles de programadores Visual Basic, y finalmente, el articulo será útil. Bien, que me condenen al infierno de Dante los programadores avanzados en Visual Basic, use programación tradicional en los modelos de código de este articulo. Sin embargo, para expirar en parte mi pecado, escribí un ejemplo en un anexo para explicar exactamente como usar lo mismo pero con interfaces. Si me preguntan: ¿Cuál es mejor?, la respuesta es: La programación orientada a interfaces tiene mayores beneficios, pero en grandes desarrollos.
Introducción Para iniciar en el tema, le podría sugerir indagar por «Creación de una DLL ActiveX» y «Creación de un Componente EXE ActiveX», en la documentación estándar de Visual Basic (libros en pantalla para VB5 o MSDN para VB6). Esta documentación es ideal, lo robustecerá en conocimientos y lo pondrá al tanto de los beneficios y precauciones de usar formularios dentro de componentes. Sin embargo, a través de mi experiencia he delineado algunos modelos de código que contribuyen a solucionar sistemáticamente las necesidades de usar formularios en componentes.
En general, las fallas comunes de una mala programación de formularios en componentes provienen de dejar objetos sueltos, en particular por el entorno conceptual de iniciar y terminar un Formulario. En general, la clave del éxito de usar formularios en componentes se fundamente en que la clase que envuelve el formulario es la encargada de controlar la vida del formulario, y no el formulario quien dictamina su permanencia en memoria. Quizá se sorprenda, pero dominar las referencias a un objeto puede ser más difícil de lo presupuestado. Los modelos aquí expuestos suministran total dominio sobre la instancia del formulario.
Necesariamente los formularios se deben envolver en clases las cuales suministran la interfaz. ¿Cómo va el código dentro de la clase y dentro del formulario?; este articulo es una cátedra.
Pense escribir este articulo con un estilo más deductivo y formal, delegando los modelos de código en líneas generales, pero recordé unas palabras en el prologo de Bruce McKenney, autor de Hardcore Visual Basic: «Ejemplos!!!! Maldición ». Esta realmente me parece una brillante sugerencia para escritos técnicos de programación. Bien, así se hará, explicare con un ejemplos reales y resaltaré aquellas partes que se deberán reemplazar para beneficiarse del código.
Formularios Modales en Componentes en Proceso Los formularios modales tienen una misión clásica: Una ventana que recoge datos suministrados por el usuario y los devuelve a la aplicación para que haga algo. Asi pues, los formularios modales son idóneos para ser empaquetados en componentes. Un programa bien diseñado (con mentalidad de objetos) no almacena formularios que se presentarán modales en su proyecto principal.
Ejecución proceso significa una DLL ActiveX, o un Control ActiveX, instalados en el PC del cliente. En general aquí hablaré de componentes de código, más precisamente DLLs ActiveX, sin embargo, los Controles ActiveX a la larga son componentes de código con ciertas particularidades: Básicamente: (1) tiene interfaz gráfica para ser perfilada en tiempo de diseño, y (2) el contenedor (generalmente un Formulario) tras bambalinas controla la vida del control. Los formularios empaquetados en controles ActiveX perfectamente pueden seguir las reglas de este articulo.
Por demás, bebiera seguir las normas de diseño de formularios modales, p.e.
BorderStyle=Fixed (yo prefiero
Fixed ToolWindow),
TabStrips, y así sucesivamente. También es conveniente usar el prefijo
dlg, en vez de
frm, para los formularios que se presentaran modales.
Según mi criterio, la estrategia de código para suministrar formularios depende de dos casos: Formularios Modales Eventuales y Formularios Modales Frecuentes (en memoria).
1. Formularios Modales Eventuales Pasivos Me refiero a aquellos que se usan muy pocas veces dentro de la aplicación y no suministran servicios activos (por ejemplo el Formulario Acerca De). Es decir, los podemos cargar en memoria cuando se solicitan, y eliminarlos cuando se cierran. Este caso es el más sencillo de programar, observe el código de la clase que envuelve un formulario dlgAbout:
'// CLASE : cls_About
'// DESCRIPCIÖN : Envuelve un Formulario Modal Volatil Pasivo
Option Explicit
Public Sub ShowDialog(ClientApp As Object)
Dim dlg As dlgAbout
If Not TypeOf ClientApp Is App Then
Exit Sub
End If
Set dlg = New dlgAbout
Load dlg
With dlg
.FillLabels ClientApp
.Show vbModal
End With
Unload dlg
End Sub |
El código dentro del Formulario es el siguiente:
'// FORMULARIO : dlgAbout
'// DESCRIPCIÖN : Muestra de un Formulario Modal Volatil Pasivo
Option Explicit
Public Sub FillLabels(App As App)
lblTitle = App.Title
'//...and so forth
End Sub
Private Sub cmdOk_Click()
Hide
DoEvents
End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
If UnloadMode = vbFormControlMenu Then
cmdOk.Value = True
Else
Unload Me
End If
End Sub |
Como el formulario es pasivo (no toma ni retorna datos), no se requiere de más código. Noté que el método ShowDialog tiene parámetros para configurar el formulario, y este a su vez tiene el método publico FillLabels. La lista de parámetros en este método la usaria para pasar la información con la cual se configurará el formulario.
|
Todo aquello que vaya en cursiva, dentro de los bloques de código, es lo que Ud. debiera modificar para emplear el modelo. |
Finalmente, el código en el cliente que invoca el formulario (supongamos un botón cmdAbout) es:
Private Sub cmdAbout_Click()
Dim obj As cls_About
Set obj = New cls_About
obj.ShowDialog App
Set obj = Nothing
End Sub |
2. Formularios Modales Eventuales que Retornan Datos Otro es el caso para formularios eventuales que retornan datos al cliente. Simplemente delegamos los valores recogidos en controles como propiedades limpias de la clase. Además, el formulario deberá tener un botón Acept y uno Cancel. Normalmente, en beneficio de usar teclado, se sigue la lógica de que el botón Acept tiene la propiedad Default=True, y el botón Cancel tiene la propiedad Cancel=True. He aquí el ejemplo:
Se trata de un formulario dlgLoging, el cual recoge el nombre y contraseña del usuario. Normalmente este tipo de formulario se presenta una sola vez en el proceso de una aplicación. El modelo de código de la clase que envuelve este dialogo es el siguiente:
'// CLASE : cls_Loging
'// DESCRIPCIÖN : Envuelve un formulario modal eventual que devuelve datos
Option Explicit
'//RETORNO
Public Acept As Boolean
'//RETORNO DEL CUADRO DE DIALOGO
Public User As String
Public Password As String
Public Sub ShowDialog()
Dim dlg As dlgLoging
Set dlg = New dlgLoging
Load dlg
With dlg
.Show vbModal
Acept = .Acept
If Acept Then
User = .txtUser
Password = .txtPassword
End If
End With
Unload dlg
End Sub |
La clase retorna limpiamente User y Password como propiedades, siempre que el usuario usa el comando Aceptar.
|
Note que implemente las propiedades User y Password como variables publicas. En general, en diseño de objetos poco se hace, es más conveniente usar la pareja de procedimientos Get y Let. No obstante, en este caso puede ser una excepción y es perfectamente válido, ya que realmente son delegaciones simples y es el formulario quien debiera filtrar los datos si fuese necesario. Por ejemplo tras el botón Acepar, se podrían usar procedimientos de validación. |
Los valores que retorna el dialogo provienen de valores de controles en el formulario, como TextBox, CheckBox, etc. En este ejemplo son dos TextBox. El modelo de código en el formulario es el siguiente:
'// FORMULARIO : dlgLoging
'// DESCRIPCIÖN : Formulario modal eventual que devuelve datos
Option Explicit
'//RETORNO
Public Acept As Boolean
Private Sub cmdAcept_Click()
'//Valida Datos. Si son validos los datos sigue con:
Hide
DoEvents
Acept = True
End Sub
Private Sub cmdCancel_Click()
Hide
DoEvents
Acept = False
End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
If UnloadMode = vbFormControlMenu Then
cmdCancel.Value = True
Else
Unload Me
End If
End Sub |
El código en el cliente debe seguir este modelo (evaluamos la propiedad Acept):
Private Sub cmdModalVolatil_Click()
Dim obj As cls_Loging
Set obj = New cls_Loging
With obj
.ShowDialog
If .Acept Then
MsgBox "Procesa el formulario anterior"
Debug.Print "User ="; .User
Debug.Print "Password ="; .Password
End If
End With
Set obj = Nothing
End Sub |
Este mismo ejemplo fue el que use en el Anexo I para mostrar la implementación usando interfaces múltiples. 3. Formularios Modales Frecuentes (En Memoria) Son aquellos Formularios que se usarán frecuentemente, por ejemplo aquel formulario que pide los parámetros del filtro para una consulta. Como caso clásico tenemos el formulario Buscar. Es conveniente mantener estos formularios en memoria por razones de rapidez de la aplicación. En este caso es conveniente jugar con eventos, dan una salida limpia e intuitiva. El ejemplo que seguiré será un formulario que lee un nombre y apellido de un empleado, un clásico dlgGetEmployee. El modelo de código en la clase que envuelve el dialogo es el siguiente (recuerde que las palabras en cursiva indican aquel código que cambia para un caso particular):
'//CLASE : cls_GetEmployee
'//DESCRIPCIÖN : Envuelve un formulario modal en memoria
Option Explicit
'//FORMULARIO
Dim WithEvents dlg As dlgGetEmployee
'//RETORNO
Public Acept As Boolean
'//Retorno del cuadro de dialog
Public EmployeeFirstName As String
Public EmployeeLastName As String
Private Sub Class_Terminate()
If Not dlg Is Nothing Then
Unload dlg
End If
End Sub
Public Sub ShowDialog()
If dlg Is Nothing Then
Set dlg = New dlgGetEmployee
Load dlg
End If
dlg.Show vbModal
End Sub
Private Sub dlg_Acept(Value As Boolean)
Acept = Value
If Value Then
EmployeeFirstName = dlg.txtFirstName
EmployeeLastName = dlg.txtLastName
End If
End Sub |
Como regla estándar, el formulario debe tener un botón Aceptar y un botón Cancelar. También, los valores que retorna el dialogo provienen de valores de controles en el formulario, como TextBox, CheckBox, etc. El modelo de código en el formulario es:
'// FORMULARIO : dlgGetEmployee
'// DESCRIPCIÖN : Modelo de formulario modal en memoria
Option Explicit
'//EVENTS
Public Event Acept(Value As Boolean)
Private Sub cmdAcept_Click()
'//Valida Datos. Si son validos los datos sigue con:
Hide
DoEvents
RaiseEvent Acept(True)
End Sub
Private Sub cmdCancel_Click()
Hide
DoEvents
RaiseEvent Acept(False)
End Sub
Private Sub Form_QueryUnload(Cancel As Integer, UnloadMode As Integer)
If UnloadMode = vbFormControlMenu Then
cmdCancel.Value = True
Else
Unload Me
End If
End Sub |
El código en el cliente debe seguir este modelo:
'//Cuadro de dialogo en memoria
Private dlgGetEmployee As cls_GetEmployee
Private Sub cmdGetEmployee_Click()
With dlgGetEmployee
.ShowDialog
If .Acept Then
MsgBox "Procesa el formulario anterior"
Debug.Print "EmployeeFirstName ="; .EmployeeFirstName
Debug.Print "EmployeeLastName ="; .EmployeeLastName
End If
End With
End Sub
Private Sub Form_Load()
Set dlgGetEmployee = New cls_GetEmployee
End Sub
Private Sub Form_Unload(Cancel As Integer)
Set dlgGetEmployee = Nothing
End Sub |
La clase se mantiene en memoria del cliente, pero el formulario solo se cargará la primera vez que es llamado. Esto es un buen diseño.
ANEXO I Usando Programación Orientada a Interfaces Múltiples La Programación Orientada a Interfaces Múltiples suministra un estilo de programación lejanamente superior a la programación tradicional. Representa el perfil mejor elaborado de programación de objetos y reutilización de código con Visual Basic (si bien, supera en varios aspectos al paradígma dogmático de la OOP).
Escribiré el ejemplo de «Formularios Modales Eventuales que Retornan Datos», usando interfaces. Se requieren tres pasos.
Paso 1: Definir la interfaz abstracta. Como repasará en el caso que traté (numeral 2), la clase solo suministra dos atributos: La propiedad
Acept y el método
ShowDialog. Bien, la interfaz abstracta, que he bautizado
IVolatilModal, es así de simple:
'//CLASE : IVolatilModal
'//DESCRIPCIÓN : Interfaze que envuelve un formulario modal
Public Property Get Acept() As Boolean
End Property
Public Sub ShowDialog()
End Sub |
Note que la propiedad
Acept tiene solo el procedimiento
Get, lo cual significa que la interfaz suministra la propiedad para
solo lectura.
Recuerde que para las clases abstractas, la propiedad Insancing debe ser
2-PublicNotCreatable.
Paso 2: Implementar la interfaz en la clase que envuelve al formulario. La clase que envuelve el formulario cambia ligeramente. Los datos que sede el cuadro de dialogo son atributos particulares de la interfaz que implementa
IVolatiolModal, en este ejemplo llamaré a esta nueva interfaz
CLoging. Aquí esta el código de la clase que envuelve el formulario:
'//CLASE : CLoging
'//DESCRIPCIÓN : Modelo de clase que envuelve un formulario modal
Option Explicit
'//Implementa la interfaz
Implements IVolatilModal
'//Miembro heredado de la Implementación
Private Acept As Boolean
'//Retrono del cuadro de dialogo
Public User As String
Public Password As String
Private Property Get IVolatilModal_Acept() As Boolean
IVolatilModal_Acept = Acept
End Property
Private Sub IVolatilModal_ShowDialog()
Dim dlg As dlgLoging
Set dlg = New dlgLoging
Load dlg
With dlg
.Show vbModal
Acept = .Acept
If Acept Then
User = .txtUser
Password = .txtPassword
End If
End With
Unload dlg
End Sub |
NOTA. En mi privada norma de codificación (si se puede llamar Húngara), uso el prefijo cls_
ClassName para clases con una única interfaz. Mientras que uso C
ClassName para clases con varias interfaces. No me ponga cuidado, solo es un pequeño capricho.
El código dentro del formulario ni su interfaz cambian, así que no hay necesidad de repetir estas líneas. Esto quiere decir que solo cambia la implementación del formulario dentro del componente.
Paso 3. Usar la Interfaz en el cliente. Ahora debemos declarar un objeto para la interfaz y otro para la clase particular que implementa la interfaz. El código tiene esta forma (como ejemplo, un botón
cmdLogging que muestra el formulario):
Private Sub cmdLogging_Click()
Dim dlg As CLoging '//Subclase
Dim vm As IVolatilModal '//Superclase
Set dlg = New CLoging
Set vm = dlg
With vm
.ShowDialog
If .Acept Then
MsgBox "Procesa el formulario anterior"
Debug.Print "User ="; dlg.User
Debug.Print "Password ="; dlg.Password
End If
End With
Set dlg = Nothing
End Sub |
Este caso se vé muy elegante. Sin embargo, seré sincero, este caso es simple. Los demás modelos requieren algo más profundo y complicado para poder implementar interfaces. Por ejemplo, analice las consecuencias de los eventos. Buena suerte.
¿Porque emplear Interfaces Múltiples? A parte de tener un código reutilizable, suministrar una plantilla de diseño, y tener un código listo para ser usado en desarrollos pesados, tenemos nada menos y nada más que
poliformismo. Por ejemplo, podríamos agrupar formularios de acceso a datos que implementen la interfaz
IVolatilModal (algo más elaborada) y administrarlos desde procedimientos únicos.
