El contenido aquí puede aplicarse a Northwind 2.0 Developer Edition y Starter Edition.
VBA (Visual Basic para Aplicaciones) es el lenguaje de programación usado en todos los productos de Office. Aprendizaje de VBA le permite trabajar con todos los productos de Office (no solo con Access).
Al buscar "procedimientos", asegúrese de buscar ejemplos específicos de Access e incluir Microsoft Access en la búsqueda. A menudo, las soluciones para los demás productos de Office funcionarán, pero no hay ninguna garantía. Microsoft Access es un producto para adultos; eso significa que hay muchos ejemplos por ahí; que es genial para ti.
También significa que los libros más antiguos sobre programación de Access aún son viables para que lo mire. Muchos de los libros más antiguos todavía están disponibles en sitios de libros usados a una fracción de su costo original. Consulte el sitio web de Microsoft para determinar qué versiones de Access siguen recibiendo soporte técnico y seguir con ellas.
Recursos de finalización del soporte para Office: Implementar Office | Microsoft Learn
A continuación se muestran algunos vínculos a la documentación de Access en Microsoft.
Los archivos de Microsoft Access son archivos de Office. Los archivos de Office deben estar en una "Ubicación de confianza" o tener su "contenido habilitado". Estos elementos se consideran "seguros" porque los creó o provienen de una fuente de confianza. La búsqueda de ubicaciones de confianza se produce cada vez que abre cualquier archivo de Office. A partir de aquí, nos referiremos a este como De confianza/Habilitado. NOTA: Si se publica una nueva versión de la aplicación y se abre desde una ubicación que no es de confianza, se repetirá el proceso de habilitar el contenido.
Obtenga más información sobre las ubicaciones de confianza:
Las macros, las funciones y los subs son la forma de implementar la lógica de negocios en la base de datos de Access. Es importante que comprenda el ámbito y la visibilidad antes de empezar.
Los eventos (como hacer clic en un control) de controles de un formulario (por ejemplo, botones, cuadros de texto, etiquetas, etc.) desencadenan otros procesos, como agregar, eliminar registros o abrir formularios. Estos procesos se pueden implementar con macros o VBA. Northwind Starter Edition usa principalmente macros y algunas VBA donde las macros no pueden realizar las funciones necesarias. Northwind Developer Edition usa principalmente VBA.
Algunos tipos de control tienen asistentes integrados para crear automáticamente una macro. Por ejemplo, agregar un botón de comando a un formulario abre un asistente que ofrece varias opciones de funcionalidad para el botón. Agregar un cuadro combinado abre un asistente que se puede configurar para buscar un registro determinado en el formulario.
El panel de navegación es la forma principal de ver y obtener acceso a todos los objetos de base de datos y se muestra en el lado izquierdo de la ventana de Access de forma predeterminada.
El panel de navegación de Northwind se ha personalizado. Hemos creado una categoría personalizada denominada Northwind Starter 2.0. Esto nos permite organizar los objetos por área funcional.
Es importante obtener información sobre el ámbito y la visibilidad en Access/Office. Puedes empezar aquí:
A veces es necesario que una variable exista después del objeto que lo creó va fuera del ámbito. Consulte Ámbito y visibilidad arriba. Hay tres formas principales de hacerlo: Variables públicas, TempVars y Almacenamiento de los valores en una tabla local. Muchos desarrolladores usan una mezcla de estos. Cada uno tiene sus ventajas y desventajas. Más información sobre cada uno de ellos aquí:
Variable pública del módulo VBA:
TempVars:
Almacenamiento de los valores en una tabla local
-
Existen variables públicas y TempVars para la sesión actual y salen del ámbito cuando se cierra la aplicación. Pero, ¿qué sucede si desea mantener variables específicas del usuario entre sesiones? Puede almacenar estos tipos de valores en una tabla local. En Northwind 2.0 una de estas variables se guarda en una tabla que se denomina SystemSettings. El valor de la tabla es ShowWelcome. Este valor indica a Access si desea ver la pantalla de inicio de sesión cada vez que inicie sesión o no.
Los desarrolladores a menudo necesitan pasar parámetros de un formulario a otro, o de un formulario a un informe. Estos parámetros transmiten información importante, que la función llamada usará después para configurarse a sí misma. Hay varias maneras de que el segundo formulario o informe obtenga información del primer formulario. Estas son algunas de estas maneras:
-
El segundo formulario puede "volver" al primer formulario para seleccionar algunos valores, posiblemente en un control visible o invisible. Por ejemplo:
lngCustomerID = Forms!FirstForm!cboCustomerID -
El primer formulario puede guardar valores en variables globales o en TempVars. Por ejemplo:
g_lngUserID = Me.cboUserID
TempVars.Add "UserID", Me.cboUserID
El método que se usa a menudo en Northwind Developer Edition, así como en nuestras vidas profesionales, usa el argumento OpenArgs de DoCmd.OpenForm o OpenReport. Por ejemplo:
DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)
Aquí combinamos dos técnicas: (1) el uso de OpenArgs para pasar el VendorID y VendorType y (2) el uso de la función StringFormat() para crear, por ejemplo, esta cadena:
CompanyID=5&CompanyTypeID=2
Esta cadena es muy similar a una cadena de consulta, tal y como se usa en un explorador. Contiene uno o más "pares nombre/valor" separados por el carácter y comercial:
name1=value1&name2=value2
La ventaja de esta cadena es que cada valor tiene un nombre. Compare esto con un enfoque más sencillo en el que solo establecería OpenArgs en "5,2". En tal caso, se necesitarían esfuerzos para averiguar qué significa cada valor. Asignar un nombre a cada valor hace que la cadena de consulta se "describa automáticamente", lo que es una buena práctica de programación.
En el extremo receptor de DoCmd.OpenForm , normalmente estamos en el evento Form_Open o Form_Load y queremos analizar la cadena OpenArgs en sus componentes.
En Northwind puede hacer esto con la función StringToDictionary . Toma una función tipo querystring y la analiza en sus componentes. A continuación, estos componentes se almacenan en un objeto Scripting.Dictionary . Tenga en cuenta que para ello es necesario usar Herramientas > Referencias y establecer una referencia a Microsoft Scripting Runtime (scrrun.dll).
Entre las características y ventajas del objeto Diccionario se incluyen las siguientes:
-
El orden de los elementos no es importante
-
Funciones sencillas para agregar y quitar elementos de la colección
-
Funciones para recorrer en bucle la colección, para que pueda saber qué hay en ella
-
Una función Existe para que pueda comprobar si hay algún elemento disponible
El uso del objeto diccionario aparece en Northwind. Por ejemplo, el evento Form_Load en frmGenericDialog.
Las macros creadas con asistentes para controles en Access rara vez incluyen control de errores; VBA creado con asistentes de control puede limitarse a un MsgBox Err.Description genérico.
En Northwind 2.0 le mostramos cómo mejorarlo al usar código VBA. Hemos implementado lo que se denomina controlador de errores global. Los errores que se producen en cualquier procedimiento llaman a una función en el nivel global para mostrar el error. La gran ventaja es que el control de errores es coherente. Y si el mensaje necesita cambiar (por ejemplo, para mostrar adicionalmente el número de error o registrar el error en un archivo), debe hacerse en un solo lugar.
clsErrorHandler es el módulo de clase que implementa el código de control de errores. Un módulo de clase mantiene todas sus funciones principales y auxiliares juntas en una unidad, encapsulando así el código.
La macro AutoExec llama a la función Inicio en modStartup. En Starter Edition, la función crea una instancia de clsErrorHandler y la guarda como una variable global que está disponible para su uso en toda la aplicación. En la edición Dev se usa una clase estática: vea los comentarios en la parte superior del módulo de clase.
De hecho, el código de control de errores en los procedimientos es tan coherente que pudimos crearlo todo en menos de cinco minutos usando código VBA específico que aplicó cada procedimiento con el controlador de errores adecuado. (Código no incluido en la plantilla). Las ediciones de plantillas Northwind 2.0 Starter y Developer se han equipado inicialmente con este enfoque de control de errores.
'
CONTROL DE ERRORES MEJORADO
A partir de la versión 2.2 de Northwind Developer Edition, se ha mejorado el controlador de errores, gracias a los comentarios de la comunidad Access. La edición Starter no cambia.
En esencia, el controlador de errores en la versión anterior (2.0 - publicada en abril de 2023) es:
Public Sub HandleError(…)
MsgBox Err.Description
End Sub
En la versión 2.2 se actualiza a:
Public Sub HandleError (…, Optional ByVal IsEventProcedure As Boolean = False)
If Not IsEventProcedure Then
Err.Raise lngError, strErrSource
End If
MsgBox Err.Description
End Sub
Para entender por qué se realizó este cambio, primero vamos a comprender qué hace que se ejecute el código:
-
La macro AutoExec llama al procedimiento Inicio, que realiza algunas inicializaciones antes de abrir el primer formulario.
-
El usuario interactúa con la aplicación, como abrir un formulario o hacer clic en un botón, lo que provoca que se accionen procedimientos de evento, como Form_Load y cmdPrintInvoice_Click.
'
Además de procedimientos de eventos, las aplicaciones tienen subrutinas y funciones (principalmente en módulos) y se llama a ese código desde los procedimientos de eventos. Estos procedimientos se denominan procedimientos "estándar".
En la versión 2.0 de Northwind, los procedimientos estándar administraban sus propios errores con los mensajes, pero no notifiquen de algún modo al procedimiento de evento de llamada que se ha producido un error. Esto puede ser malo si el procedimiento de evento tiene código posterior que se debe ejecutar independientemente del error anterior controlado por el procedimiento llamado. Por supuesto, podríamos reemplazar la subrutina con una función que devuelva un éxito o un error, y codificar el procedimiento de evento en consecuencia, pero no siempre es una opción.
En la versión 2.2 de Northwind, los procedimientos estándar no controlan los mensajes de error, sino que, si se usa Err.Raise, se notifica al procedimiento de evento de llamada. A continuación, el procedimiento de evento de llamada muestra el error generado y se reanuda en Exit_Handler. Esto es mejor, porque permite que el procedimiento de llamada concluya con gracia.
Para usar el código northwind versión 2.2, los procedimientos de evento deben pasar a HandleError un tercer argumento que indica que el autor de la llamada es un procedimiento de evento. Northwind Dev Edition se ha actualizado para hacerlo.
Un módulo de controlador de errores aún más eficaz sería compatible con procedimientos de "inserción y desapareciendo" en una "pila" (matriz). El primer elemento siempre sería el procedimiento de evento, por lo que no es necesario el argumento adicional. Esta implementación va más allá de los objetivos de Northwind Dev Edition.
MRU o Usados recientemente es una lista de pedidos y pedidos de compra usados recientemente. Es posible que desee volver a estos con frecuencia para ponerlos en el siguiente Estado. Las listas de MRU a menudo se ven en los productos de Office como una lista de archivos usados recientemente que puede que quiera volver a abrir.
en la edición Northwind Dev, para implementar la característica MRU (que no existe en la edición Starter), primero debe establecer los elementos siguientes:
-
Una tabla para almacenar información de MRU.
-
Código para actualizar la tabla cuando se abre un pedido o pedido de compra (PO).
-
Código para actualizar la lista desplegable de MRU en la cinta de opciones.
-
Código para cargar el elemento cuando se selecciona un elemento MRU de la cinta de opciones.
Echemos un vistazo a cada una de ellas con más detalle.
1. Tabla para almacenar información de MRU.
El diseño de la tabla MRU vale la pena revisar, especialmente sus índices. Tenga en cuenta que hay un índice duplicado SortIdx para ayudar a ordenar rápidamente los elementos MRU en la lista desplegable de la cinta de opciones, así como un índice único para exigir la regla de negocio que para cada usuario un elemento solo puede ocurrir una vez. Por ejemplo, abrir el mismo orden dos veces no crea dos registros en la tabla MRU.
La tabla aprovecha el hecho de que todos los campos de PK (clave principal) relacionados con MRU de la base de datos son Autonumeración, por lo que el tipo de datos Entero largo se puede usar para PKValue.
2. Código para actualizar la tabla cuando se abre un pedido o un pedido.
En NW2, decidimos agregar a la lista de MRU solo cuando se creó un registro nuevo, no cuando uno existente se actualizó de nuevo. Ciertamente, podríamos mover la llamada de AddToMRU de Form_AfterInsert a Form_AfterUpdate para apoyarlo.
Los procedimientos AddToMRU y DeleteFromMRU se implementan en modGlobal, que es un módulo estándar cuyos procedimientos públicos son visibles desde cualquier forma.
AddToMRU (como el nombre sugiere) agrega el nuevo elemento a la tabla MRU y, después, lo recorta de nuevo, eliminando el registro más antiguo, si ha crecido más allá del tamaño máximo (MAX_MRU_COUNT). El último paso es probablemente el menos conocido para los desarrolladores de Access: la lista desplegable de la cinta de opciones tiene que actualizarse y esto se consigue llamando a InvalidateControl. Esto es una señal para la cinta de opciones para volver a ejecutar su proceso de inicialización.
3. Código para actualizar la lista desplegable MRU en la cinta de opciones.
En el momento de inicio y después de llamar a InvalidateControl , se ejecuta un conjunto complejo de funciones para rellenar la cinta de opciones. Estos procedimientos son llamados por el XML de la cinta de opciones en la tabla uSysRibbons que dice en parte:
<group id="gCurrentStatus" label="MRU">
<box id="bxMRU" boxStyle="vertical">
<dropDown id="ddMRU"
getItemCount="ddMRU_GetItemCount"
getItemLabel="ddMRU_GetItemLabel"
getSelectedItemIndex="ddMRU_GetSelectedItemIndex"
getItemID="ddMRU_GetItemID"
onAction="ddMRU_OnAction"
screentip="Most Recently Used Objects">
</dropDown>
</box>
</group>Estas cuatro funciones de devolución de llamada rellenan la lista desplegable. Tenga en cuenta que esta es muy la misma idea que se describe aquí para los cuadros combinados estándar.
Si descommenta las líneas Debug.Print en modRibbonCallback y reinicia la aplicación, la Ventana inmediata presentará una secuencia como esta:
ddMRU_GetItemCount ddMRU 6
ddMRU_GetItemLabel ddMRU 0 Order 60, Proseware, Inc.
ddMRU_GetItemID ddMRU 0 2
ddMRU_GetItemLabel ddMRU 1 Order 62, Best For You Organics Company
ddMRU_GetItemID ddMRU 1 4
ddMRU_GetItemLabel ddMRU 2 Order 63, Wide World Importers
ddMRU_GetItemID ddMRU 2 5
ddMRU_GetItemLabel ddMRU 3 Order 66, Proseware, Inc.
ddMRU_GetItemID ddMRU 3 8
ddMRU_GetItemLabel ddMRU 4 Order 67, Best For You Organics Company
ddMRU_GetItemID ddMRU 4 9
ddMRU_GetItemLabel ddMRU 5 Order 68, Adatum Corporation
ddMRU_GetItemID ddMRU 5 10
ddMRU_GetSelectedItemIndex ddMRU 0
Aquí podemos ver que Access llama primero a un procedimiento que devuelve el número de elementos que se cargan en el argumento ByRef de ddMRU_GetItemCount. Este es también el momento en que se abre la consulta en la tabla MRU y se almacena en caché porque está a punto de usarse varias veces.
A continuación, la cinta llama repetidamente a dos procedimientos para obtener los valores Id. y Etiqueta de la lista desplegable de dos columnas.
Por último, llama a un procedimiento para desover el elemento que se debe seleccionar. (En nuestro caso, es el primero).
4. Código para cargar un elemento cuando se selecciona el elemento MRU de la cinta de opciones.
Al igual que con cualquier otro elemento de la cinta de opciones, la propiedad OnAction en el XML de la cinta de opciones especifica una función de devolución de llamada que se usará para realizar la acción:
onAction="ddMRU_OnAction"
Este procedimiento se implementa en modRibbonCallback. Vuelve a usar el conjunto de registros ya abierto para buscar el registro con el elemento seleccionado y, a continuación, según tableName obligatorio, abre el formulario correspondiente, pasando el valor de PK que se va a cargar.
-
Northwind 2.0 Developer Edition: Template-Tutorial
-
Northwind 2.0 Developer Edition: Todos los temas
