Northwind 2.0 coisas que você deve saber

VBA (Visual Basic for Applications) é a linguagem de programação usada em todos os Produtos do Office. O VBA de aprendizagem permite que você trabalhe com todos os produtos do Office (não apenas o Access).
Ao pesquisar por "como fazer", procure exemplos específicos do Access e inclua o Microsoft Access na pesquisa. Muitas vezes, as soluções para os outros produtos do Office funcionarão - mas não há garantia. O Microsoft Access é um produto maduro; isso significa que há muitos exemplos por aí; o que é ótimo para você! 

Isso também significa que os livros mais antigos sobre programação do Access ainda são viáveis para você examinar. Muitos dos livros mais antigos ainda estão disponíveis em sites de livros usados a uma fração de seu custo original. Verifique o site da Microsoft para determinar quais versões do Access ainda estão sendo compatíveis e siga com elas.

Fim dos recursos de suporte para o Office – Implantar o Office | Microsoft Learn  

Veja abaixo alguns links para a documentação do Access na Microsoft.

• Referência de Visual Basic for Applications de acesso (VBA) | Microsoft Learn

• Glossário VBA | Microsoft Learn

• Tópicos conceituais do Visual Basic | Microsoft Learn

• Visual Basic for Applications - Wikipédia

• VBA-Docs/API em main · MicrosoftDocs/VBA-Docs · Github

Os arquivos do Microsoft Access são arquivos do Office. Os arquivos do Office devem estar em um "Local Confiável" ou ter seu "conteúdo habilitado". Esses itens são considerados "seguros" porque você os criou ou eles vieram de uma fonte confiável. Verifique se locais confiáveis ocorrem sempre que você abre qualquer arquivo do office. Vamos nos referir a isso como Confiável/Habilitado daqui em diante. OBSERVAÇÃO: se uma nova versão do aplicativo for lançada e aberta de um local não confiável, o processo de habilitação do conteúdo será repetido.

Saiba mais sobre Locais Confiáveis.: 

• Locais confiáveis para arquivos do Office – Implantar o Office | Microsoft Learn

• Decidir se confia em um banco de dados (Suporte da Microsoft)

• Adicionar, remover ou alterar um local confiável (Suporte da Microsoft)

Macros, Funções e Subs são como você implementa a lógica de negócios no banco de dados access. É importante que você entenda Escopo e Visibilidade antes do início.

• Ação de macro RunCode | Microsoft Learn

• Introdução às macros | Suporte da Microsoft

• Instrução de função (VBA) | Microsoft Learn

• Sub instrução (VBA) | Microsoft Learn

Eventos (como clicar em um controle) em Controles em um formulário (por exemplo, botões, caixas de texto, rótulos etc.) disparam outros processos, como adicionar, excluir registros ou abrir formulários. Esses processos podem ser implementados usando macros ou VBA. Northwind Starter Edition usa principalmente macros e alguns VBA em que as macros não são capazes de executar as funções necessárias. O Northwind Developer Edition usa principalmente o VBA. 

Alguns tipos de controle têm assistentes internos para criar automaticamente uma macro. Por exemplo, adicionar um botão de comando a um formulário abre um assistente que oferece várias opções de funcionalidade para o botão. Adicionar uma caixa de combinação abre um assistente que pode ser configurado para encontrar um registro específico no formulário. 

O Painel de Navegação é a maneira main de exibir e acessar todos os objetos de banco de dados e ele é exibido no lado esquerdo da janela de acesso por padrão. 
O Painel de Navegação northwind foi personalizado. Criamos uma categoria personalizada chamada Northwind Starter 2.0. Isso nos permite organizar os objetos por área funcional.

• Use o Painel de Navegação | Suporte da Microsoft

• Personalizar o Painel de Navegação | Suporte da Microsoft

É importante saber mais sobre Escopo e Visibilidade no Access/Office. Você pode começar aqui: 

• Compreensão do escopo e da visibilidade (VBA) | Microsoft Learn

• Instrução pública (VBA) | Microsoft Learn

• Instrução privada (VBA) | Microsoft Learn

• Instrução estática (VBA) | Microsoft Learn

• Entender o tempo de vida das variáveis (VBA) | Microsoft Learn

Às vezes, você precisa de uma variável para existir após o objeto que o criou sair do escopo. Consulte Escopo e Visibilidade acima. Há três maneiras primárias de fazer isso: Variáveis Públicas, TempVars e Armazenar os valores em uma tabela local. Muitos desenvolvedores usam uma combinação desses. Cada um tem seus prós e contras.  Mais sobre cada um aqui: 

Variável pública do módulo VBA: 

• Declarando variáveis (VBA) | Microsoft Learn

TempVars: 

• Objeto TempVars (Access) | Microsoft Learn

• Dica de energia: maximizar o uso de TempVars no Access 2007 e 2010 | Microsoft 365 Blog

Armazenando os valores na tabela local

• Variáveis públicas e TempVars existem para a sessão atual e saem do escopo quando o aplicativo é fechado. Mas e se você quiser manter variáveis específicas do usuário entre sessões? Você pode armazenar esses tipos de valores em uma tabela local. No Northwind 2.0, uma dessas variáveis é salva em uma tabela chamada SystemSettings. O valor na tabela é ShowWelcome. Esse valor informa ao Access se você quiser ver a tela De boas-vindas sempre que fizer logon ou não.

Os desenvolvedores geralmente precisam passar parâmetros de um formulário para outro ou de um formulário para um relatório. Esses parâmetros transmitem informações importantes, que a chamada função usará para se configurar. Há várias maneiras de o segundo formulário ou relatório obter informações do primeiro formulário. Aqui estão algumas dessas maneiras: 

1. O segundo formulário pode "olhar para trás" para o primeiro formulário para pegar alguns valores, possivelmente no controle visível ou invisível.  Por exemplo:
   lngCustomerID = Forms!FirstForm!cboCustomerID 

2. O primeiro formulário pode salvar valores em variáveis globais ou em TempVars. Por exemplo:
   g_lngUserID = Me.cboUserID 
   TempVars.Add "UserID", Me.cboUserID 

O método que geralmente é usado no Northwind Developer Edition, bem como em nossas vidas profissionais, está usando o argumento OpenArgs de DoCmd.OpenForm ou OpenReport. Por exemplo:

DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)

Estamos combinando duas técnicas aqui: (1) o uso de OpenArgs para passar o VendorID e o VendorType e (2) o uso da função StringFormat() para criar, por exemplo, esta cadeia de caracteres: 

CompanyID=5&CompanyTypeID=2 

Essa cadeia de caracteres se parece muito com uma cadeia de caracteres de consulta, como é usada em um navegador. Ele contém um ou mais "pares de nome/valor" separados pelo caractere ampersand: 

name1=value1&name2=value2

A vantagem de tal cadeia de caracteres é que cada valor tem um nome. Compare isso com uma abordagem mais simples em que você definiria OpenArgs apenas como "5,2".  Nesse caso, seria necessário esforço para descobrir o que cada valor significa. Nomear cada valor torna a cadeia de caracteres de consulta "autodescrevendo" que é uma boa prática de programação.

No final de recebimento do DoCmd.OpenForm , normalmente estamos no evento Form_Open ou Form_Load e queremos analisar a cadeia de caracteres OpenArgs em seus componentes.

No Northwind, você pode fazer isso com a função StringToDictionary . Ele usa uma função semelhante a querystring e a analisa em seus componentes. Esses componentes são armazenados em um objeto Scripting.Dictionary . Observe que isso exige que você use Ferramentas > Referências e defina uma referência ao Microsoft Scripting Runtime (scrrun.dll).

Os recursos e os benefícios do objeto Dictionary incluem estes:  

• A ordem dos elementos não é importante

• Funções simples para adicionar e remover elementos da coleção

• Funções para fazer loop sobre a coleção, para que você possa saber o que está nela

• Uma função Existe para que você possa testar se um determinado elemento estiver disponível

O uso do objeto dicionário é exibido em todo o Northwind. Por exemplo, o evento Form_Load no frmGenericDialog.

As macros criadas com assistentes de controle no Access raramente incluem o tratamento de erros; O VBA criado com assistentes de controle pode ser limitado a um MsgBox Err.Description genérico.

No Northwind 2.0, mostramos como fazer melhor ao usar o código VBA. Implementamos o que é chamado de Manipulador Global de Erros. Erros que ocorrem em qualquer procedimento chamam uma função no nível global para mostrar o erro. A grande vantagem aqui é que o tratamento de erros é consistente. E se a mensagem precisar ser alterada (por exemplo, para mostrar adicionalmente o número de erro ou registrar o erro em um arquivo), ela precisa ser feita somente em um só lugar. 

clsErrorHandler é o Módulo de Classe que implementa o código de tratamento de erros. Um módulo de classe mantém todas as suas funções main e auxiliar juntas em uma unidade, encapsulando o código.

A macro AutoExec chama a função Inicialização no modStartup. No Starter Edition, a função cria uma instância do clsErrorHandler e a salva como uma variável global disponível para uso em todo o aplicativo. Na edição Dev, uma classe estática é usada – confira os comentários na parte superior do módulo de classe.

Na verdade, o código de tratamento de erros em procedimentos é tão consistente que fomos capazes de criar tudo isso em menos de cinco minutos usando código VBA específico que equipava cada procedimento com o manipulador de erros adequado. (Código não incluído no modelo). As edições de modelo do Northwind 2.0 Starter e do Desenvolvedor foram inicialmente equipadas com essa abordagem de tratamento de erros. 
'

MANIPULAÇÃO DE ERROS APRIMORADA

Começando com a versão 2.2 do Northwind Developer Edition, o manipulador de erros foi aprimorado, graças aos comentários da comunidade do Access. A edição inicial não foi alterada. 

Em essência, o manipulador de erros na versão anterior (2.0 – lançada em abril de 2023) é:

Public Sub HandleError(…)
    MsgBox Err.Description
End Sub

Na versão 2.2, ele é atualizado para:

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 que essa alteração foi feita, vamos primeiro entender o que faz o código ser executado:

• A macro AutoExec chama o procedimento Inicialização, que executa algumas inicializações antes de abrir o primeiro formulário.

• O usuário interage com o aplicativo, como abrir um formulário ou clicar em um botão, fazendo com que procedimentos de evento disparem, como Form_Load e cmdPrintInvoice_Click.
  '

Além dos procedimentos de evento, os aplicativos têm sub-rotinas e funções , principalmente em módulos, e esse código é chamado dos procedimentos de evento. Estes são chamados de procedimentos "padrão".

Na versão 2.0 do Northwind, os procedimentos padrão tratariam seus próprios erros com mensagens, mas não notificariam de alguma forma o procedimento de evento de chamada de que havia ocorrido um erro. Isso pode ser ruim se o procedimento de evento tiver um código subsequente que deve ser executado independentemente do erro anterior tratado pelo procedimento chamado. Claro, poderíamos substituir a sub-rotina por uma função que retorna êxito ou falha e codificar o procedimento de evento de acordo, mas isso nem sempre é uma opção.

No Northwind versão 2.2, os procedimentos padrão não lidam com mensagens de erro, mas sim, usando Err.Raise, denuncie-os de volta ao procedimento de evento de chamada. Em seguida, o procedimento de evento de chamada exibe o erro gerado e é retomado em Exit_Handler. Isso é melhor, pois permite que o procedimento de chamada seja concluído normalmente.

Para usar o código Northwind versão 2.2, os procedimentos de evento devem passar para o HandleError um terceiro argumento indicando que o chamador é um procedimento de evento. O Northwind Dev Edition foi atualizado para fazer isso.

Um módulo ainda mais poderoso do manipulador de erros teria suporte para procedimentos de "push e popping" em uma "pilha" (matriz). O primeiro elemento sempre seria o procedimento de evento, portanto, o argumento extra não é necessário. Essa implementação está além das metas da Northwind Dev Edition.

MRU ou Mais Recentemente Usado é uma lista de pedidos e pedidos de compra usados recentemente. Talvez você queira voltar a estes com frequência para colocá-los no próximo Status. As listas de MRU geralmente são vistas em produtos do Office como uma lista de arquivos usados recentemente que talvez você queira reabrir novamente.

na edição Northwind Dev, para implementar o recurso MRU (que não existe na edição Starter), primeiro você deve estabelecer os seguintes itens: 

1. Uma tabela para armazenar informações de MRU.

2. Código para atualizar a tabela quando uma PO (ordem de compra ou pedido) for aberta.

3. Código para atualizar a lista suspensa MRU na faixa de opções.

4. Código para carregar o item quando um item mru é selecionado na faixa de opções.

Vamos examinar cada uma delas com mais detalhes. 

1. Tabela para armazenar informações de MRU.

Vale a pena examinar o design da MRU da tabela, especialmente seus índices. Observe que há um SortIdx de índice duplicado para ajudar na classificação rápida dos itens mru na lista suspensa da faixa de opções, bem como um índice exclusivo para impor a regra de negócios que para cada usuário um item pode ocorrer apenas uma vez. Por exemplo, abrir a mesma ordem duas vezes não cria dois registros na tabela MRU.

A tabela aproveita o fato de que todos os campos PK (chave primária) relacionados à MRU no banco de dados são AutoNumber, de modo que o tipo de dados Long Integer pode ser usado para PKValue.

2. Código para atualizar a tabela quando um pedido ou P.O. é aberto.

No NW2, optamos por adicionar à lista de MRU somente quando um novo registro foi criado, não quando um existente foi atualizado novamente. Certamente poderíamos mover a chamada AddToMRU de Form_AfterInsert para Form_AfterUpdate para dar suporte a isso.

Os procedimentos AddToMRU e DeleteFromMRU são implementados no modGlobal, que é um Módulo Standard cujos procedimentos públicos estão visíveis de qualquer formulário.

AddToMRU (como o nome sugere) adiciona o novo item à tabela MRU e, opcionalmente, o corta de volta, excluindo o registro mais antigo, se ele tiver crescido além do tamanho máximo (MAX_MRU_COUNT). A última etapa provavelmente é a menos conhecida para os desenvolvedores do Access: a lista suspensa da faixa de opções precisa ser atualizada e isso é realizado chamando InvalidateControl. Este é um sinal para a faixa de opções para executar novamente seu processo de inicialização. 

3. Código para atualizar a lista suspensa mru na faixa de opções. 

No momento da inicialização e, depois que InvalidateControl for chamado, um conjunto complexo de funções é executado para preencher a faixa de opções.  Esses procedimentos são chamados pelo Ribbon XML na tabela uSysRibbons que diz em 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>

Essas quatro funções de retorno de chamada preenchem a lista suspensa. Observe que essa é a mesma ideia descrita aqui para caixas de combinação padrão.

Se você descompactar as linhas Debug.Print no modRibbonCallback e reiniciar o aplicativo, a Janela Imediata apresentará uma sequência 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

Podemos ver aqui que o Access está chamando primeiro um procedimento que retorna o número de itens a serem carregados no argumento ByRef de ddMRU_GetItemCount. Essa também é a hora em que abrimos a consulta na tabela MRU e a armazenamos em cache porque ela está prestes a ser usada várias vezes. 

Em seguida, a faixa de opções chama repetidamente dois procedimentos para obter os valores ID e Label para a lista suspensa de duas colunas. 

Por fim, ele chama um procedimento para desabilitar qual item deve ser selecionado. (No nosso caso, é o primeiro.) 

4. Código para carregar um item quando o item MRU é selecionado na faixa de opções.

Como acontece com qualquer outro item de faixa de opções, a propriedade OnAction no Ribbon XML especifica uma função de retorno de chamada a ser usada para executar a ação:

onAction="ddMRU_OnAction"

Esse procedimento é implementado no modRibbonCallback. Ele reutiliza o conjunto de registros já aberto para localizar o registro com o item selecionado e, dependendo do TableName necessário, abre o formulário correspondente, passando o valor PK a ser carregado.

• Northwind 2.0 Developer Edition: Template-Tutorial

• Northwind 2.0 Developer Edition: todos os tópicos