Northwind 2.0 Coisas Que Deve Saber

O VBA (Visual Basic for Applications) é a linguagem de programação utilizada em todos os Produtos do Office. A aprendizagem do VBA permite-lhe trabalhar com todos os produtos do Office (e não apenas com o Access).
Ao procurar "procedimentos", certifique-se de que procura exemplos específicos do Access e inclui o Microsoft Access na pesquisa. Muitas vezes, as soluções para outros produtos do Office funcionam, mas não há garantias. O Microsoft Access é um produto maduro; isto significa que existem muitos exemplos lá fora; o que é ótimo para si! 

Também significa que os livros mais antigos sobre programação do Access ainda são viáveis para que possa ver. Muitos dos livros mais antigos ainda estão disponíveis em sites de livros usados a uma fração do seu custo original. Consulte o site da Microsoft para determinar que versões do Access ainda estão a ser suportadas e siga-as.

Fim dos recursos de suporte do Office – Implementar o Office | Microsoft Learn  

Seguem-se algumas ligações para a documentação do Access na Microsoft.

• Referência do Access Visual Basic for Applications (VBA) | Microsoft Learn

• Glossário do VBA | Microsoft Learn

• Tópicos conceptuais do Visual Basic | Microsoft Learn

• Visual Basic for Applications - Wikipédia

• VBA-Docs/API no principal · MicrosoftDocs/VBA-Docs · GitHub

Os ficheiros do Microsoft Access são ficheiros do Office. Os ficheiros do Office têm de estar numa "Localização Fidedigna" ou ter o "conteúdo ativado". Estes itens são considerados "seguros" porque os criou ou são provenientes de uma origem fidedigna. Verifique se existem Localizações Fidedignas sempre que abre qualquer Ficheiro do Office. Vamos referir-nos a isto como Fidedigno/Ativado a partir de agora. NOTA: se uma nova versão da aplicação for lançada e aberta a partir de uma localização não fidedigna, o processo de ativação do conteúdo será repetido.

Saiba mais sobre localizações fidedignas.: 

• Localizações Fidedignas para ficheiros do Office – Implementar o Office | Microsoft Learn

• Decidir se pretende confiar numa base de dados (Suporte da Microsoft)

• Adicionar, remover ou alterar uma localização fidedigna (Suporte da Microsoft)

Macros, Funções e Subs são a forma como implementa a lógica de negócio na sua base de dados do Access. É importante que compreenda o Âmbito e a Visibilidade antes de começar.

• 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

Os eventos (como clicar num controlo) em Controlos num formulário (por exemplo, botões, caixas de texto, etiquetas, etc.) acionam outros processos, como adicionar, eliminar registos ou abrir formulários. Estes processos podem ser implementados com macros ou VBA. O Northwind Starter Edition utiliza principalmente macros e alguns VBA onde as macros não conseguem executar as funções necessárias. A Northwind Developer Edition utiliza principalmente o VBA. 

Alguns tipos de controlo têm assistentes incorporados 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 localizar um registo específico no formulário. 

O Painel de Navegação é a principal forma de ver e aceder a todos os objetos da base de dados e é apresentado no lado esquerdo da janela do Access por predefinição. 
O Painel de Navegação da Northwind foi personalizado. Criámos uma categoria personalizada denominada Northwind Starter 2.0. Isto permite-nos organizar os objetos por área funcional.

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

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

É importante saber mais sobre o Âmbito e a Visibilidade no Access/Office. Pode começar aqui: 

• Compreender o âmbito e a visibilidade (VBA) | Microsoft Learn

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

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

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

• Compreender a duração das variáveis (VBA) | Microsoft Learn

Por vezes, é necessário que exista uma variável após o objeto que o criou ficar fora do âmbito. Veja Âmbito e Visibilidade acima. Existem três formas principais de o fazer: Variáveis Públicas, TempVars e Armazenar os valores numa tabela local. Muitos programadores utilizam uma combinação destes. Cada um tem os seus prós e contras.  Mais informações sobre cada um aqui: 

Variável Pública do Módulo VBA: 

• Declarar variáveis (VBA) | Microsoft Learn

TempVars: 

• Objeto TempVars (Access) | Microsoft Learn

• Sugestão de Energia: Maximizar a utilização de TempVars no Access 2007 e 2010 | Blogue do Microsoft 365

Armazenar os valores na tabela local

• As variáveis públicas e as TempVars existem para a sessão atual e ficam fora do âmbito quando a aplicação é fechada. Mas e se quiser manter variáveis específicas do utilizador entre sessões? Pode armazenar estes tipos de valores numa tabela local. Em Northwind 2.0, uma dessas variáveis é guardada numa tabela denominada SystemSettings. O valor na tabela é ShowWelcome. Este valor indica ao Access se pretende ver o ecrã de Boas-vindas sempre que iniciar sessão ou não.

Muitas vezes, os programadores precisam de transmitir parâmetros de um formulário para outro ou de um formulário para um relatório. Estes parâmetros transmitem informações importantes, que a função denominada utilizará para se configurar. Existem várias formas de o segundo formulário ou relatório obter informações do primeiro formulário. Eis algumas dessas formas: 

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

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

O método que é frequentemente utilizado na Northwind Developer Edition, bem como na nossa vida profissional, está a utilizar o argumento OpenArgs do DoCmd.OpenForm ou OpenReport. Por exemplo:

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

Estamos a combinar duas técnicas aqui: (1) a utilização de OpenArgs para transmitir o VendorID e VendorType e (2) a utilização da função StringFormat() para criar, por exemplo, esta cadeia: 

CompanyID=5&CompanyTypeID=2 

Esta cadeia é muito semelhante a uma cadeia de consulta, tal como é utilizada num browser. Contém um ou mais "pares nome/valor" separados pelo caráter de e comercial: 

name1=value1&name2=value2

A vantagem de tal cadeia é que cada valor tem um nome. Compare esta opção com uma abordagem mais simples, na qual definiria OpenArgs apenas como "5,2".  Nesse caso, seria necessário um esforço para descobrir o que cada valor significa. Atribuir um nome a cada valor torna a cadeia de consulta "autodescritiva", o que é uma boa prática de programação.

Na extremidade receção do DoCmd.OpenForm , normalmente estamos no evento Form_Open ou Form_Load e queremos analisar a cadeia OpenArgs nos respetivos componentes.

Em Northwind, pode fazê-lo com a função StringToDictionary . Utiliza uma função semelhante a uma consulta e analisa-a nos respetivos componentes. Estes componentes são então armazenados num objeto Scripting.Dictionary . Tenha em atenção que, para tal, tem de utilizar as Ferramentas > Referências e definir uma referência para o Microsoft Scripting Runtime (scrrun.dll).

As funcionalidades e os benefícios do objeto Dicionário incluem:  

• A ordem dos elementos não é importante

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

• Funções para repetir o ciclo sobre a coleção, para que possa saber o que está nela

• Uma função Existe para que possa testar se um determinado elemento está disponível

A utilização do objeto de dicionário é apresentada em Northwind. Por exemplo, o evento Form_Load em frmGenericDialog.

As macros criadas com Assistentes de Controlo no Access raramente incluem processamento de erros; O VBA criado com Assistentes de Controlo pode estar limitado a um MsgBox Err.Description genérico.

Em Northwind 2.0, mostramos-lhe como fazê-lo melhor ao utilizar código VBA. Implementámos o que é chamado de Processador de Erros Global. Os erros que ocorrem em qualquer procedimento chamam uma função ao nível global para mostrar o erro. A grande vantagem aqui é que o processamento de erros é consistente. E se a mensagem precisar de ser alterada (por exemplo, para mostrar o número de erro ou para registar o erro num ficheiro), esta tem de ser feita apenas num único local. 

clsErrorHandler é o Módulo de Classe que implementa o código de processamento de erros. Um módulo de classe mantém todas as suas funções principais e auxiliares juntas numa unidade, encapsulando assim o código.

A macro AutoExec chama a função Arranque no modStartup. No Starter Edition, a função cria uma instância de clsErrorHandler e guarda-a como uma variável global que está disponível para utilização em toda a aplicação. Na edição Dev, é utilizada uma classe estática – veja os comentários na parte superior do módulo de classe.

Na verdade, o código de processamento de erros nos procedimentos é tão consistente que conseguimos criar tudo em menos de cinco minutos com código VBA específico que equipava cada procedimento com o processador de erros adequado. (Código não incluído no modelo). As edições de modelos Northwind 2.0 Starter e Developer foram inicialmente equipadas com esta abordagem de processamento de erros. 
'

PROCESSAMENTO DE ERROS MELHORADO

A partir da versão 2.2 da Northwind Developer Edition, o processador de erros foi melhorado, graças ao feedback da comunidade do Access. A edição Starter não mudou. 

Essencialmente, o processador 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, é 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 compreender por que motivo esta alteração foi efetuada, vamos começar por compreender o que faz com que o código seja executado:

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

• O utilizador interage com a aplicação, como abrir um formulário ou clicar num botão, fazendo com que os procedimentos de eventos acionem, como Form_Load e cmdPrintInvoice_Click.
  '

Além dos procedimentos de eventos, as aplicações têm subroutinas e funções, principalmente em módulos, e esse código é chamado a partir dos procedimentos de evento. Estes procedimentos são denominados procedimentos "padrão".

Na versão 2.0 da Northwind, os procedimentos padrão processariam os seus próprios erros com mensagens, mas de alguma forma não notificariam o procedimento de evento de chamada de que tinha ocorrido um erro. Isto pode ser mau se o procedimento do evento tiver código subsequente que deve ser executado independentemente do erro anterior processado pelo procedimento chamado. Claro que podemos substituir a subrreplicação por uma função que devolve êxito ou falha e codificar o procedimento do evento em conformidade, mas isso nem sempre é uma opção.

Na versão 2.2 da Northwind, os procedimentos padrão não processam mensagens de erro, mas sim, através de Err.Raise, reportam-nas ao procedimento de evento de chamada. Em seguida, o procedimento de evento de chamada apresenta o erro gerado e retoma a Exit_Handler. Isto é melhor, porque permite que o procedimento de chamada conclua graciosamente.

Para utilizar o código northwind versão 2.2, os procedimentos de evento têm de passar para HandleError um terceiro argumento que indica que o chamador é um procedimento de evento. A Northwind Dev Edition foi atualizada para o fazer.

Um módulo de processador de erros ainda mais poderoso teria suporte para procedimentos de "emitir e estalar" numa "pilha" (matriz). O primeiro elemento seria sempre o procedimento do evento, pelo que o argumento adicional não é necessário. Esta implementação está para além dos objetivos da Northwind Dev Edition.

MRU ou Utilizado Mais Recentemente é uma lista das Encomendas e Encomendas de Compras utilizadas recentemente. Poderá querer voltar a estes frequentemente para colocá-los no Estado seguinte. As listas de MRU são frequentemente vistas nos produtos do Office como uma lista dos ficheiros utilizados recentemente que poderá querer reabrir.

na edição Northwind Dev, para implementar a funcionalidade MRU (que não existe na edição Starter), primeiro tem de estabelecer os seguintes itens: 

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

2. Código para atualizar a tabela quando uma encomenda ou nota de encomenda (PO) é aberta.

3. Código para atualizar o menu pendente MRU no friso.

4. Código para carregar o item quando um item mru é selecionado no friso.

Vamos analisar cada um destes detalhes mais detalhadamente. 

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

Vale a pena rever a estrutura da tabela MRU, especialmente os respetivos índices. Tenha em atenção que existe um SortIdx de índice duplicado para ajudar na ordenação rápida dos itens mru na lista pendente do friso, bem como um índice exclusivo para impor a regra de negócio que, para cada utilizador, um item só pode ocorrer uma vez. Por exemplo, abrir a mesma encomenda duas vezes não cria dois registos na tabela MRU.

A tabela tira partido do facto de todos os campos PK (chave primária) relacionados com MRU na base de dados serem Numeração Automática, pelo que o tipo de dados Número Inteiro Longo pode ser utilizado para PKValue.

2. Código para atualizar a tabela quando uma encomenda ou P.O. é aberta.

No NW2, optámos por adicionar à lista de MRU apenas quando foi criado um novo registo, não quando um existente foi atualizado novamente. Podemos certamente mover a chamada AddToMRU de Form_AfterInsert para Form_AfterUpdate para o suportar.

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

AddToMRU (como o nome sugere) adiciona o novo item à tabela MRU e, opcionalmente, corta-o novamente, eliminando o registo mais antigo, se tiver crescido para além do tamanho máximo (MAX_MRU_COUNT). O último passo é provavelmente o menos conhecido para os programadores do Access: o menu pendente do friso tem de ser atualizado e isso é conseguido ao chamar InvalidateControl. Este é um sinal para o friso para executar novamente o processo de inicialização. 

3. Código para atualizar o menu pendente MRU no friso. 

No momento do arranque e depois de InvalidateControl ser chamado, é executado um conjunto complexo de funções para preencher o friso.  Estes procedimentos são chamados pelo XML do Friso 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>

Estas quatro funções de chamada de retorno povoam o menu pendente. Tenha em atenção que esta é a mesma ideia descrita aqui para caixas de combinação padrão.

Se anular o comentário das linhas Debug.Print no modRibbonCallback e reiniciar a aplicação, 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á a chamar primeiro um procedimento que devolve o número de itens a carregar no argumento ByRef de ddMRU_GetItemCount. Esta é também a altura em que abrimos a consulta na tabela MRU e a colocamos em cache porque está prestes a ser utilizada várias vezes. 

Em seguida, o friso chama repetidamente dois procedimentos para obter os valores de ID e Etiqueta para o menu pendente de duas colunas. 

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

4. Código para carregar um item quando o item MRU está selecionado no friso.

Tal como acontece com qualquer outro item do friso, a propriedade OnAction no XML do Friso especifica uma função de chamada de retorno a ser utilizada para executar a ação:

onAction="ddMRU_OnAction"

Este procedimento é implementado no modRibbonCallback. Utiliza novamente o conjunto de registos já aberto para localizar o registo com o item selecionado e, em seguida, dependendo do TableName necessário, abre o formulário correspondente, transmitindo o valor PK a carregar.

• Northwind 2.0 Developer Edition: Template-Tutorial

• Northwind 2.0 Developer Edition: Todos os tópicos