Somos Expertos Access. Contacto atravez de Skype Skype logo expertos_7

Retrasos al cargar subformularios

En la primera parte , Juan habló de la secuencia de eventos disparados al cargar un formulario con un número de subformularios y cómo se puede reducir los efectos de eventos en cascada debido a operaciones realizadas en la carga (load event). Vamos a hablar de cómo podemos retrasar la carga de los subformularios. Al deshabilitar la carga del subformulario , no sólo aseguramos de que el formulario padre pueda cargar completamente primero , sino también reducimos la carga general utilizando sólo el subformulario que el usuario necesita.

Solución incorporada

Si estás en Access 2010 o posterior , y estás trabajando en un nuevo proyecto, debes mirar sin duda el panel de navegación introducido en Access 2010 . Se trata básicamente de un panel con pestañas y un subformulario combinados en un potente sistema de navegación . Lo mejor de todo, permite la carga retrasada, todo gratis, sin necesidad de codificación de su parte. Cada vez que se cambia una ficha sobre el control de la navegación , el viejo subformulario se descarga y a continuación, el nuevo subformulario se carga . Esto es muy bueno si los usuarios en general tienen que visitar un subformulario solo una vez y no necesitan cambiar entre subformularios a menudo .

Sin embargo , el panel de navegación siempre se ajusta de manera perfecta . Por un lado, puede que tenga que trabajar en proyectos que soporten Access 2007 o anterior. Otra consideración es si se necesitan dos subformularios que sean capaces de interactuar uno con el otro, realmente no se puede hacer eso con un control de navegación que siempre tiene un solo subformulario cargado en todo momento. Por último, a lo mejor el flujo de trabajo del usuario es tal que el sistema tiene que ser capaz de cambiar entre dos subformulario de manera rápida , porlo tanto, prefiere tener más lento el tiempo de carga inicial para intercambiar formularios o tener un formulario principal cargado en todo momento y retrasar la carga sólo de las pestañas adicionales.

Hacerlo a la manera de la vieja escuela

La mayor parte del tiempo, cuando un formulario tiene varios subformularios, lo ponemos en un  control de pestañas, alojando en cada pestaña un solo subformulario. Tenga en cuenta que también es posible utilizar un único control de subformulario agrupados con la opción de de botones agrupados o controles similares lo que nos dan un comportamiento muy similar al control de navegación, pero tendría también el mismo problema – la imposibilidad de cargar y almacenar en caché un subformulario. Así que para el resto del artículo, vamos a trabajar con el control de pestañas y el control de subformulario en cada pestaña de la página de diseño.

El primer paso es no cargar ningún formulario en el control de subformularios. Por lo general,configuramos la propiedad SourceObject (objeto fuente) a un formulario o un informe sobre un control de subformulario . En este caso , estaríamos en blanco.

 

Vamos a llenar la propiedad SourceObject a través del evento de cambio (onchange) del control de pestañas. El código mínimo para lograr esto sería algo así:

Private Sub tabCtl_Change()

Dim ctlSubForm As Access.Subform
Dim strSource As String

Select Case tabCtl.Value
Case 1 ‘Second Page
Set ctlSubForm = Me.frmCustomers
strSource = “frmCustomers”
Case 2 ‘Third Page
Set ctlSubForm = Me.frmOrders
strSource = “frmOrders”
Case 3 ‘Fourth Page
Set ctlSubForm = Me.frmTransactions
strSource = “frmTransactions”
End Select

If Len(ctlSubForm.SourceObject) = 0 Then
ctlSubForm.SourceObject = strSource
End If

End Sub

Con este cambio, hemos sido capaces de retrasar la carga y asegurarnos de que la carga sólo se produzca exactamente una vez, siempre y cuando el formulario primario se mantenga abierto. Este enfoque ayuda a reducir el tiempo de carga de un subformulario de manera que el formulario principal pueda cargar rápidamente y sólo tarda un poco más cuando el usuario selecciona uno de la pestaña.

Con frecuencia, alguna de esas pestañas, es la pestaña predeterminada que  se desea mostrar en la página, de modo que en este caso puede haber ningún punto de retardo de carga de éste subformulario. En este escenario, dejaremos  la propiedad SourceObject populada y la obviaremos . Es por esto que el código de ejemplo muestra es para después de la segunda página y en adelante , en lugar de trabajar con la primera.

Vincular o no vincular, he aquí la pregunta.

Este ejemplo también asume que estaremos usando la conexión incorporada en formulario- subformulario dejando las propiedades LinkMasterFields  y LinkChildFields  llenas. Sin embargo,  hemos encontrado que a veces necesitamos que el control adicional, sea capaz de especificar el filtro que ha sido configurado por el usuario en el formulario padre. A veces, es sólamente que no es necesaria la vinculación, especialmente en un formulario principal, donde un usuario puede iniciar diferentes flujos de trabajo que no están relacionados entre sí.

En este escenario, dejaríamos también en blanco ambas propiedades LinkMasterFields y LinkChildFields. Luego, para cada subformulario estableceremos el registro inicial a su equivalente de “SELECT * FROM tblSource WHERE 1 = 0 ; ” Como Juan expuso en la primera parte, utilizando los criterios imposibles ” 1 = 0 ” se asegura de que el formulario se carga rápidamente y sin tirar ningún registro para que entonces podemos aplicar el filtro . Esto es necesario ya que con un subformulario, no tenemos ninguna posibilidad de pasar los filtros hasta que se haya cargado el subformulario. El código de ejemplo a continuación, cambia a algo como esto :

If Len(ctlSubForm.SourceObject) = 0 Then

Limpiando

Esto es sólo un comienzo , pero esperamos que por ahora , usted tengauna buena idea de qué tan lejos puede ir con el control manual de carga de subformularios y si es necesario , el filtrado . Sin embargo , cuando el formulario principal se ha desplazado a un registro diferente , y usted tampoco encuentra que los subformularios vinculados ya cargados toman demasiado tiempo o que los subformularios no vinculadas están ahora fuera de sincronización. Tenemos que hacer frente a esta situación. El problema con el subformulario vinculado es que a menos que utilice un sistema de navegación personalizada , no se puede interceptar fácilmente cuando los usuarios han hecho clic en los botones de la barra de navegación para desplazarse a otro registro. Cerrando el subformulario en un evento  de formulario principal sería demasiado tarde porque la navegación obligaría al subformulario vinculado a rehacer el  filtro. Si no desea utilizar un sistema de navegación personalizado entonces puede que tenga que considerar el uso de subformularios no enlazados y manejar los filtros usted mismo.

Para este ejemplo , vamos a suponer que para ir a un nuevo récord en el formulario principal se requiere que cerremos todos los subformularios no vinculadas y también pongamos al usuario de vuelta a la primera página ,  lo que requiere que el usuario vuelva a seleccionar una pestaña con el fin de disparar el evento de cambio (onchange) y , por tanto, cargar el subformulario. Aquí está el código que usted podría poner en el formulario principal:

Select Case True
Case Me.NewRecord, varBookmark <> Me.Bookmark
Me.frmCustomers.SourceObject = vbNullString
Me.frmOrders.SourceObject = vbNullString
Me.frmTransactions.SourceObject = vbNullString
Me.tabCtl.Value = 0
If Me.NewRecord Then
varBookmark = Null
Else
varBookmark = Me.Bookmark
End If
End Select

End Sub

Puede darse el caso de que en algunos flujos de trabajo , los usuarios quieran ser capaces de permanecer en la misma pestaña cuando se navega a un registro padre diferente. Esto es fácil de lograr comprobando el valor del control de pestañas y saltando la configuración de la propiedad SourceObject (objecto fuente) del subformulario para vbNullString

Conclusion

Con suerte, los ejemplos proporcionados aquí les darán una buena idea de cómo se puede mejorar la experiencia del usuario tomando mayor control de cómo las cargar los subformularios y si es necesario desvincularlos y administrar los filtros usted mismo. Si usted tiene alguna idea mejor o desea compartir la experiencia, por favor hágalo en nuestros comentarios.

Feliz subforming!

 

Publicado en Access Help, VBA

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

 

Quienes Somos

ExpertosMicrosoftAccess.com es un servicio de la empresa IT Impact, Inc., una compañía de programación y servicios para empresas en Latino América. Ofrecemos servicios en .Net, SQL Server y Microsoft Access. Muchos de nuestros desarrolladores han obtenido el galardón de Access MVP, un título proveído por Microsoft a aquellos que han hecho aportes a la comunidad y que han demostrado tener conocimientos superiores del producto.

Nuestro Equipo

  • Le ayudamos a "Descubrir el poder de sus datos™" con reportes y sistemas de Access excepcionales .
  • Creamos soluciones de bases de datos personalizadas utilizando Microsoft Access y / o SQL Server.
  • Nuestros consultores ganaron sus estrellas en las empresas de servicios y/o manufactura antes de convertirse en programadores.

Blogs anteriores