Van toepassing op
Access voor Microsoft 365 Access 2021 Access 2019

De inhoud hier kan van toepassing zijn op Northwind 2.0 Developer Edition en Starter Edition. 

VBA (Visual Basic for Applications) is de programmeertaal die in alle Office-producten wordt gebruikt. Met VBA kunt u werken met alle Office-producten (niet alleen Met Access).Wanneer u zoekt naar 'instructies', moet u zoeken naar specifieke voorbeelden van Access en Microsoft Access opnemen in de zoekopdracht. Vaak werken oplossingen voor de andere Office-producten, maar er is geen garantie. Microsoft Access is een volwassen product; dat betekent dat er veel voorbeelden zijn; wat geweldig voor u is! 

Het betekent ook dat oudere boeken over Access-programmering nog steeds levensvatbaar zijn om naar te kijken. Veel van de oudere boeken zijn nog steeds beschikbaar op gebruikte boekensites voor een fractie van hun oorspronkelijke kosten. Controleer de Microsoft-website om te bepalen welke versies van Access nog steeds worden ondersteund en ga met die versies mee.

Einde van de ondersteuningsresources voor Office - Office implementeren | Microsoft Learn  

Hieronder ziet u enkele koppelingen naar Access-documentatie bij Microsoft.

Microsoft Access-bestanden zijn Office-bestanden. Office-bestanden moeten zich op een vertrouwde locatie bevinden of de inhoud ervan moeten zijn ingeschakeld. Deze items worden beschouwd als 'veilig' omdat u ze hebt gemaakt of ze afkomstig zijn van een betrouwbare bron. Controleer telkens wanneer u een Office-bestand opent op vertrouwde locaties. We verwijzen hiernaar als Vertrouwd/Ingeschakeld. OPMERKING: als er een nieuwe versie van de toepassing wordt uitgebracht en geopend vanaf een niet-vertrouwde locatie, wordt het proces voor het inschakelen van de inhoud herhaald.

Meer informatie over vertrouwde locaties: 

Met macro's, functies en subs implementeert u bedrijfslogica in uw Access-database. Het is belangrijk dat u het bereik en de zichtbaarheid begrijpt voordat u begint.

Gebeurtenissen (zoals het klikken op een besturingselement) op Besturingselementen in een formulier (bijvoorbeeld knoppen, tekstvakken, labels, enzovoort) activeren andere processen, zoals het toevoegen, verwijderen van records of het openen van formulieren. Deze processen kunnen worden geïmplementeerd met behulp van macro's of VBA. Northwind Starter Edition maakt voornamelijk gebruik van macro's en sommige VBA's waarbij macro's de benodigde functies niet kunnen uitvoeren. Northwind Developer Edition maakt voornamelijk gebruik van VBA. 

Sommige typen besturingselementen hebben ingebouwde wizards om automatisch een macro te maken. Als u bijvoorbeeld een opdrachtknop toevoegt aan een formulier, wordt er een wizard geopend die verschillende functionaliteitsopties voor de knop biedt. Als u een keuzelijst met invoervak toevoegt, wordt een wizard geopend die kan worden geconfigureerd om een bepaalde record op het formulier te vinden. 

Het navigatiedeelvenster is de belangrijkste manier om al uw databaseobjecten weer te geven en te openen. Het wordt standaard aan de linkerkant van het Access-venster weergegeven. Het navigatiedeelvenster Noordwind is aangepast. We hebben een aangepaste categorie gemaakt met de naam Northwind Starter 2.0. Hierdoor kunnen we de objecten ordenen op functioneel gebied.

Soms moet er een variabele bestaan nadat het object dat deze heeft gemaakt buiten het bereik valt. Zie Bereik en zichtbaarheid hierboven. Er zijn drie primaire manieren om dit te doen: Openbare variabelen, TempVars en De waarden opslaan in een lokale tabel. Veel ontwikkelaars gebruiken een combinatie hiervan. Elk heeft zijn voor- en nadelen.  Meer informatie hierover: 

Openbare variabele VBA-module: 

TempVars: 

De waarden opslaan in de lokale tabel

  • Openbare variabelen en TempVars bestaan voor de huidige sessie en vallen buiten het bereik wanneer de toepassing wordt gesloten. Maar wat gebeurt er als u gebruikersspecifieke variabelen in sessies wilt behouden? U kunt deze typen waarden opslaan in een lokale tabel. In Northwind 2.0 wordt een dergelijke variabele opgeslagen in een tabel met de naam SystemSettings. De waarde in de tabel is ShowWelcome. Deze waarde geeft aan of u het welkomstscherm wilt zien wanneer u zich aanmeldt of niet.

Ontwikkelaars moeten vaak parameters doorgeven van het ene formulier naar het andere, of van een formulier naar een rapport. Deze parameters geven belangrijke informatie over, die de aangeroepen functie vervolgens gebruikt om zichzelf te configureren. Er zijn verschillende manieren voor het tweede formulier of rapport om informatie op te halen uit het eerste formulier. Hier volgen een aantal van deze manieren: 

  1. Het tweede formulier kan 'terugkijken' naar het eerste formulier om enkele waarden op te halen, mogelijk in een zichtbaar of onzichtbaar besturingselement.  Bijvoorbeeld: lngCustomerID = Forms!FirstForm!cboCustomerID 

  2. Met het eerste formulier kunnen waarden worden opgeslagen in globale variabelen of in TempVars. Bijvoorbeeld: g_lngUserID = Me.cboUserID  TempVars.Add "UserID", Me.cboUserID 

De methode die vaak wordt gebruikt in Northwind Developer Edition en in ons professionele leven, is het argument OpenArgs van DoCmd.OpenForm of OpenReport. Bijvoorbeeld: DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)

We combineren hier twee technieken: (1) het gebruik van OpenArgs om de VendorID en VendorType door te geven, en (2) het gebruik van de functie StringFormat() om bijvoorbeeld deze tekenreeks te maken: 

CompanyID=5&CompanyTypeID=2 

Deze tekenreeks lijkt erg op een querytekenreeks zoals wordt gebruikt in een browser. Het bevat een of meer 'naam/waardeparen', gescheiden door het teken ampersand: 

name1=value1&name2=value2

Het voordeel van een dergelijke tekenreeks is dat elke waarde een naam heeft. Vergelijk dit met een eenvoudigere benadering waarbij u OpenArgs alleen instelt op '5,2'.  In een dergelijk geval kost het moeite om erachter te komen wat elke waarde betekent. Als u elke waarde een naam noemt, wordt de querytekenreeks 'zichzelf beschrijvend'. Dit is een goede programmeerpraktijk.

Aan het ontvangende einde van DoCmd.OpenForm bevinden we ons meestal in de gebeurtenis Form_Open of Form_Load en willen we de OpenArgs-tekenreeks parseren in de onderdelen.

In Northwind kunt u dit doen met de functie StringToDictionary . Het neemt een querystring-achtige functie en parseert deze in de onderdelen. Deze onderdelen worden vervolgens opgeslagen in een Scripting.Dictionary-object . Houd er rekening mee dat u hiervoor Hulpprogramma's > Verwijzingen moet gebruiken en een verwijzing moet instellen op Microsoft Scripting Runtime (scrrun.dll).

De volgende functies en voordelen van het object Woordenlijst zijn:  

  • De volgorde van elementen is niet belangrijk

  • Eenvoudige functies om elementen van de verzameling toe te voegen en te verwijderen

  • Functies om over de verzameling te lusen, zodat u weet wat erin zit

  • Een bestaat-functie , zodat u kunt testen of een bepaald element beschikbaar is

Het gebruik van het woordenlijstobject wordt overal in Northwind weergegeven. Bijvoorbeeld de gebeurtenis Form_Load in frmGenericDialog.

Macro's die met wizards voor besturingselementen in Access zijn gemaakt, bevatten zelden foutafhandeling; VBA die is gemaakt met wizards voor besturingselementen kan beperkt zijn tot een algemene MsgBox Err.Description.

In Northwind 2.0 laten we u zien hoe u dit beter kunt doen bij het gebruik van VBA-code. We hebben een zogenaamde globale fouthandler geïmplementeerd. Fouten die in een procedure optreden, roepen een functie aan op globaal niveau om de fout weer te geven. Het grote voordeel hier is dat foutafhandeling consistent is. En als het bericht moet worden gewijzigd (bijvoorbeeld om het foutnummer weer te geven of om de fout in een bestand te registreren), hoeft dit op slechts één plaats te worden gedaan. 

clsErrorHandler is de klassemodule die de foutafhandelingscode implementeert. Een klassemodule houdt alle hoofd- en helperfuncties samen in één eenheid, waardoor de code wordt ingekapseld.

De macro AutoExec roept de functie Opstarten aan in modStartup. In Starter Edition maakt de functie een exemplaar van clsErrorHandler en slaat deze op als een globale variabele die beschikbaar is voor gebruik in de hele toepassing. In de Dev-editie wordt een statische klasse gebruikt. Zie de opmerkingen boven aan de klassemodule.

In feite is de foutafhandelingscode in procedures zo consistent dat we deze allemaal in minder dan vijf minuten konden maken met behulp van specifieke VBA-code die elke procedure heeft uitgerust met de juiste fouthandler. (Code is niet opgenomen in de sjabloon). Zowel Northwind 2.0 Starter- als Developer-sjabloonversies waren in eerste instantie uitgerust met deze foutafhandelingsbenadering.  '

VERBETERDE FOUTAFHANDELING

Vanaf versie 2.2 van Northwind Developer Edition is de fouthandler verbeterd, dankzij feedback van de Access-community. De starterseditie is ongewijzigd. 

In wezen is de fouthandler in de vorige versie (2.0 - uitgebracht in april 2023):

Public Sub HandleError(…)     MsgBox Err.DescriptionEnd Sub

In versie 2.2 wordt een upgrade uitgevoerd naar:

Public Sub HandleError (…, Optional ByVal IsEventProcedure As Boolean = False)     If Not IsEventProcedure Then         Err.Raise lngError, strErrSource     End If     MsgBox Err.DescriptionEnd Sub

Laten we eerst begrijpen waarom deze wijziging is aangebracht:

  • Met de macro AutoExec wordt de opstartprocedure aangeroepen, waarmee enkele initialisaties worden uitgevoerd voordat het eerste formulier wordt geopend.

  • De gebruiker communiceert met de toepassing, zoals het openen van een formulier of het klikken op een knop, waardoor gebeurtenisprocedures worden geactiveerd, zoals Form_Load en cmdPrintInvoice_Click. '

Naast gebeurtenisprocedures hebben toepassingen subroutines en functies, meestal in modules, en die code wordt aangeroepen vanuit de gebeurtenisprocedures. Dit worden 'standaard'-procedures genoemd.

In versie 2.0 van Northwind zouden de standaardprocedures hun eigen fouten met berichten verwerken, maar ze zouden de aanroepende gebeurtenisprocedure niet op de hoogte stellen dat er een fout was opgetreden. Dit kan slecht zijn als de gebeurtenisprocedure volgende code bevat die moet worden uitgevoerd ongeacht de vorige fout die is verwerkt door de aangeroepen procedure. Natuurlijk kunnen we de subroutine vervangen door een functie die succes of fout retourneert en de gebeurtenisprocedure dienovereenkomstig codeerden, maar dat is niet altijd een optie.

In Northwind versie 2.2 verwerken de standaardprocedures geen foutberichten, maar rapporteren ze met behulp van Err.Raise terug naar de procedure voor het aanroepen van de gebeurtenis. De procedure voor het aanroepen van de gebeurtenis geeft vervolgens de gegenereerde fout weer en wordt hervat op Exit_Handler. Dit is beter, omdat hiermee de aanroepprocedure correct kan worden afgesloten.

Als u de code van Northwind versie 2.2 wilt gebruiken, moeten gebeurtenisprocedures worden doorgegeven aan HandleErrof een derde argument dat aangeeft dat de aanroeper een gebeurtenisprocedure is. Northwind Dev Edition is bijgewerkt om dit te doen.

Een nog krachtigere fouthandlermodule zou ondersteuning bieden voor 'pushing and popping'-procedures op een 'stack' (matrix). Het eerste element is altijd de gebeurtenisprocedure, dus het extra argument is niet nodig. Deze implementatie valt buiten de doelstellingen van Northwind Dev Edition.

MRU of Meest recent gebruikt is een lijst met recent gebruikte orders en inkooporders. U kunt teruggaan naar deze vaak om ze in de volgende status te plaatsen. MRU-lijsten worden in Office-producten vaak gezien als een lijst met recent gebruikte bestanden die u mogelijk opnieuw wilt openen.

in de Northwind Dev-editie moet u eerst de volgende items instellen om de MRU-functie (die niet bestaat in de Starter-editie) te implementeren: 

  1. Een tabel voor het opslaan van MRU-gegevens.

  2. Code voor het bijwerken van de tabel wanneer een order of inkooporder (PO) wordt geopend.

  3. Code voor het bijwerken van de MRU-vervolgkeuzelijst op het lint.

  4. Code voor het laden van het item wanneer een MRU-item is geselecteerd op het lint.

Laten we elk van deze meer in detail bekijken. 

1. Tabel voor het opslaan van MRU-informatie.

Het ontwerp van tabel-MRU is het bekijken waard, met name de indexen. Houd er rekening mee dat er een dubbele index SortIdx is om te helpen bij het snel sorteren van de MRU-items in de vervolgkeuzelijst op het lint, evenals een unieke index om de bedrijfsregel af te dwingen dat voor elke gebruiker een item slechts één keer kan voorkomen. Als u bijvoorbeeld dezelfde volgorde tweemaal opent, worden er niet twee records in de MRU-tabel gemaakt.

De tabel maakt gebruik van het feit dat alle AAN MRU gerelateerde PK-velden (primaire sleutel) in de database AutoNummering zijn, zodat het gegevenstype Lang geheel getal kan worden gebruikt voor PKValue.

2. Code om de tabel bij te werken wanneer een order of P.O. wordt geopend.

In NW2 hebben we ervoor gekozen om alleen toe te voegen aan de MRU-lijst wanneer er een nieuwe record is gemaakt, niet wanneer een bestaande record opnieuw is bijgewerkt. We kunnen de AddToMRU-aanroep zeker verplaatsen van Form_AfterInsert naar Form_AfterUpdate om dat te ondersteunen.

De procedures AddToMRU en DeleteFromMRU worden geïmplementeerd in modGlobal, een standaardmodule waarvan de openbare procedures vanuit elke vorm zichtbaar zijn.

AddToMRU (zoals de naam al aangeeft) voegt het nieuwe item toe aan de MRU-tabel en snijdt het vervolgens terug, waarbij de oudste record wordt verwijderd, als het groter is geworden dan de maximale grootte (MAX_MRU_COUNT). De laatste stap is waarschijnlijk de minst bekende voor Access-ontwikkelaars: de vervolgkeuzelijst op het lint moet worden vernieuwd en dat wordt gedaan door InvalidateControl aan te roepen. Dit is een signaal naar het lint om het initialisatieproces opnieuw uit te voeren. 

3. Code om de MRU-vervolgkeuzelijst op het lint bij te werken. 

Tijdens het opstarten en nadat InvalidateControl is aangeroepen, wordt een complexe set functies uitgevoerd om het lint te vullen.  Deze procedures worden aangeroepen door het XML-bestand van het lint in tabel uSysRibbons , dat gedeeltelijk zegt:

<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>

Deze vier callback-functies vullen de vervolgkeuzelijst. Houd er rekening mee dat dit hetzelfde idee is als hier wordt beschreven voor standaard comboboxes.

Als u de regels Debug.Print in modRibbonCallback ongedaan maakt en de toepassing opnieuw start, wordt in het venster Direct een reeks weergegeven die er als volgt uitziet: 

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

We kunnen hier zien dat Access eerst een procedure aanroept die het aantal items retourneert dat moet worden geladen in het argument ByRef van ddMRU_GetItemCount. Dit is ook het moment waarop we de query in de MRU-tabel openen en in de cache opslaan, omdat deze op het punt staat om meerdere keren te worden gebruikt. 

Het lint roept vervolgens herhaaldelijk twee procedures aan om de id- en labelwaarden voor de vervolgkeuzelijst met twee kolommen op te halen. 

Ten slotte wordt een procedure aangeroepen om te bepalen welk item moet worden geselecteerd. (In ons geval is het de eerste.) 

4. Code voor het laden van een item wanneer het MRU-item is geselecteerd op het lint.

Net als bij elk ander lintitem geeft de eigenschap OnAction in de XML van het lint een callback-functie op die moet worden gebruikt om de actie uit te voeren:

onAction="ddMRU_OnAction"

Deze procedure is geïmplementeerd in modRibbonCallback. De al geopende recordset wordt opnieuw gebruikt om de record met het geselecteerde item te vinden. Vervolgens wordt, afhankelijk van de vereiste TableName, het bijbehorende formulier geopend, waarbij de PK-waarde wordt doorgegeven die moet worden geladen.

Facebook LinkedIn E-mail

Meer hulp nodig?

Meer opties?

Verken abonnementsvoordelen, blader door trainingscursussen, leer hoe u uw apparaat kunt beveiligen en meer.

Voordelen van Microsoft 365-abonnementen

Microsoft 365-training

Microsoft-beveiliging

Toegankelijkheidscentrum