Northwind 2.0 Ting, du bør vide

Gælder for
Access til Microsoft 365 Access 2021 Access 2019

Indholdet her kan gælde for Northwind 2.0 Developer Edition og Starter Edition. 

Access VBA-reference

VBA (Visual Basic for Applications) er det programmeringssprog, der bruges i alle Office-produkter. Hvis du lærer VBA, kan du arbejde med alle Office-produkter (ikke kun Access).
Når du søger efter "sådan", skal du sørge for at søge efter Access-specifikke eksempler og medtage Microsoft Access i søgningen. Ofte vil løsninger til de andre Office-produkter fungere - men der er ingen garanti. Microsoft Access er et modent produkt. Det betyder, at der er mange eksempler derude; hvilket er godt for dig! 

Det betyder også, at ældre bøger om Access-programmering stadig er levedygtige at læse i. Mange af de ældre bøger er stadig tilgængelige på brugte bogsider til en brøkdel af deres oprindelige pris. Gå til Microsofts websted for at finde ud af, hvilke versioner af Access der stadig understøttes, og vælg dem.

Ressourcer til ophør af support til Office – Installer Office | Microsoft Learn

Nedenfor finder du nogle links til Access-dokumentation fra Microsoft.

Placeringer, der er tillid til, og aktiveret indhold

Microsoft Access-filer er Office-filer. Office-filer skal være på en "placering, der er tillid til" eller have deres "indhold aktiveret". Disse elementer betragtes som "sikre", fordi du har oprettet dem, eller de kommer fra en pålidelig kilde. Kontrollér, om der er tillid til placeringer, hver gang du åbner en Office-fil. Fra nu af omtaler vi den som Pålidelig/Aktiveret. BEMÆRK: Hvis en ny version af programmet frigives og åbnes fra en placering, der ikke er tillid til, gentages processen med at aktivere indholdet.

Få mere at vide om placeringer, der er tillid til:

Makroer, funktioner og underfunktioner

Makroer, funktioner og underordnede bruges til at implementere forretningslogik i din Access-database. Det er vigtigt for dig at forstå Omfang og Synlighed , før du går i gang.

Hændelser (f.eks. at klikke på et kontrolelement) på kontrolelementer i en formular (f.eks. knapper, tekstfelter, etiketter osv.) udløser andre processer, f.eks. tilføjelse, sletning af poster eller åbning af formularer. Disse processer kan gennemføres ved hjælp af enten makroer eller VBA. Northwind Starter Edition bruger hovedsageligt makroer og nogle VBA, hvor makroerne ikke kan udføre nødvendige funktioner. Northwind Developer Edition bruger primært VBA. 

Nogle kontrolelementtyper har indbyggede guider til automatisk oprettelse af en makro. Hvis du f.eks. føjer en kommandoknap til en formular, åbnes der en guide, der tilbyder flere valg af funktioner til knappen. Når du tilføjer et kombinationsfelt, åbnes en guide, som kan konfigureres til at finde en bestemt post i formularen. 

Navigationsruden er den vigtigste måde, hvorpå du kan få vist og få adgang til alle dine databaseobjekter, og den vises som standard i venstre side af Access-vinduet. 
Northwind-navigationsruden er blevet tilpasset. Vi har oprettet en brugerdefineret kategori kaldet Northwind Starter 2.0. Dette giver os mulighed for at organisere objekterne efter funktionsområde.

Omfanget og synligheden af variabler i VBA

Det er vigtigt at lære mere om omfang og synlighed i Access/Office. Du kan starte her:

Permanente variabler

Nogle gange har du brug for, at en variabel eksisterer, efter at det objekt, der oprettede den, ikke længere er omfattet af omfanget. Se omfang og synlighed ovenfor. Der er tre primære måder at gøre dette på: Offentlige variabler, MidlertidigeVariabler og Lagring af værdierne i en lokal tabel. Mange udviklere bruger en blanding af disse. Hver har sine fordele og ulemper.  Mere om hver her:

VBA-modul offentlig variabel:

Midlertidige:

Gemme værdierne i en lokal tabel

  • Der findes offentlige variabler og midlertidige variabler for den aktuelle session, og de falder uden for området, når programmet lukkes. Men hvad nu, hvis du vil beholde brugerspecifikke variabler på tværs af sessioner? Du kan gemme disse typer værdier i en lokal tabel. I Northwind 2.0 er en sådan variabel gemt i en tabel, der kaldes SystemSettings. Værdien i tabellen er ShowWelcome. Denne værdi fortæller Access, om du vil have vist velkomstskærmen, hver gang du logger på eller ej.

OpenArgs og StringFormat()

Udviklere har ofte brug for at overføre parametre fra én formular til en anden eller fra en formular til en rapport. Disse parametre formidler vigtige oplysninger, som den kaldte funktion derefter vil bruge til at konfigurere sig selv. Den anden formular eller rapport kan hente oplysninger fra den første formular på flere måder. Her er et par af disse måder:

  1. Den anden formular kan "se tilbage" til den første formular for at hente nogle værdier, muligvis i enten et synligt eller usynligt kontrolelement.  Det kunne f.eks. være:
    lngCustomerID = Forms!FirstForm!cboCustomerID 
  2. I den første form kan du gemme værdier som globale variabler eller midlertidige. Det kunne f.eks. være:
    g_lngUserID = Me.cboUserID 
    TempVars.Add "UserID", Me.cboUserID

Den metode, der ofte bruges i Northwind Developer Edition såvel som i vores professionelle liv, er at bruge OpenArgs-argumentet DoCmd.OpenForm eller OpenReport. Det kunne f.eks. være:

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

Vi kombinerer to teknikker her: (1) brugen af OpenArgs til at overføre VendorID og VendorType og (2) brug af funktionen StringFormat() til at oprette f.eks. denne streng:

CompanyID=5&CompanyTypeID=2 

Denne streng ligner meget en forespørgselsstreng, som det bruges i en browser. Den indeholder et eller flere "navn/værdi-par" adskilt af og-tegnet:

name1=value1&name2=value2

Fordelen ved en sådan streng er, at hver værdi har et navn. Sammenlign dette med en enklere tilgang, hvor du kun ville angive OpenArgs til "5,2".  I et sådant tilfælde vil det kræve en indsats at finde ud af, hvad hver værdi betyder. Ved at navngive hver værdi bliver forespørgselsstrengen "selvbeskrivende", hvilket er en god programmeringspraksis.

I den modtagende ende af DoCmd.OpenForm er vi typisk i hændelsen Form_Open eller Form_Load og ønsker at fortolke OpenArgs-strengen i dens komponenter.

I Northwind kan du gøre dette med funktionen StringToDictionary . Den tager en forespørgselsstreng-lignende funktion og fortolker den i sine komponenter. Disse komponenter gemmes derefter i et Scripting.Dictionary-objekt . Bemærk, at dette kræver, at du bruger værktøjsreferencer > og angiver en reference til Microsoft Scripting Runtime (scrrun.dll).

Funktioner og fordele ved objektet Ordbog omfatter følgende:

  • Rækkefølgen af elementer er ikke vigtig
  • Simple funktioner til at tilføje og fjerne elementer i samlingen
  • Funktioner til at loope over samlingen, så du kan vide, hvad den indeholder
  • Funktionen Findes, så du kan teste, om et bestemt element er tilgængeligt

Brug af ordbogsobjektet vises overalt i Northwind. Det Form_Load f.eks. hændelsen i frmGenericDialog.

Håndtering af fejl

Makroer, der er oprettet med kontrolelementguiderne i Access, indeholder sjældent fejlhåndtering overhovedet. VBA, der er oprettet med Kontrolelementguider, kan være begrænset til en generisk MsgBox Err.Description.

I Northwind 2.0 viser vi dig, hvordan du gør det bedre, når du bruger VBA-kode. Vi har implementeret det, der kaldes en global fejlbehandler. Fejl, der opstår i en hvilken som helst procedure, kalder en funktion på globalt niveau for at vise fejlen. Den store fordel her er, at fejlhåndteringen er konsekvent. Og hvis meddelelsen skal ændres (f.eks. for yderligere at vise fejlnummeret eller for at logge fejlen i en fil), skal det kun gøres ét sted. 

clsErrorHandler er klassemodulet, der implementerer fejlhåndteringskoden. Et klassemodul holder alle sine hoved- og hjælpefunktioner samlet i én enhed og indkapsler således koden.

AutoExec-makroen kalder funktionen Start i modStartup. I Starter Edition opretter funktionen en forekomst af clsErrorHandler og gemmer den som en global variabel, der er tilgængelig til brug i hele programmet. I Dev Edition bruges en statisk klasse – se kommentarerne øverst i klassemodulet.

Faktisk er fejlhåndteringskoden i procedurer så konsistent, at vi var i stand til at oprette det hele på mindre end fem minutter ved hjælp af specifik VBA-kode, der udstyrede hver procedure med den korrekte fejlbehandler. (Kode er ikke inkluderet i skabelonen). Både Northwind 2.0 Starter- og Developer-skabelonudgaver var oprindeligt udstyret med denne fejlhåndteringstilgang. 
'

FORBEDRET FEJLHÅNDTERING

Fra og med version 2.2 af Northwind Developer Edition er fejlbehandlingen blevet forbedret takket være feedback fra Access-community'et. Starter edition er uændret. 

I bund og grund er fejlbehandleren i den tidligere version (2.0 – udgivet i april 2023):

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

I version 2.2 er den opgraderet til:

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

For at forstå, hvorfor denne ændring blev foretaget, så lad os først forstå, hvad der får programkode til at køre:

  • AutoExec-makroen kalder proceduren Start, som udfører nogle initialiseringer, før den første formular åbnes.
  • Brugeren interagerer med programmet, f.eks. ved at åbne en formular eller klikke på en knap, hvilket udløser hændelsesprocedurer, f.eks. Form_Load og cmdPrintInvoice_Click.
    '

Ud over begivenhedsprocedurer har applikationer subrutiner og funktioner - for det meste i moduler - og den kode kaldes fra hændelsesprocedurerne. Disse kaldes "standardprocedurer".

I version 2.0 af Northwind håndterer standardprocedurerne deres egne fejl med meddelelser, men de giver på ingen måde den kaldende hændelsesprocedure besked om, at der er opstået en fejl. Dette kan være skadeligt, hvis hændelsesproceduren har efterfølgende kode, der skal køre uanset den tidligere fejl, der håndteres af den kaldte procedure. Selvfølgelig kunne vi erstatte subrutinen med en funktion, der returnerer succes eller fiasko, og kode hændelsesproceduren i overensstemmelse hermed, men det er ikke altid en mulighed.

I Northwind version 2.2 håndterer standardprocedurerne ikke fejlmeddelelser, men i stedet kan du ved hjælp af Err.Raise rapportere dem tilbage til den kaldende hændelsesprocedure. Proceduren for kaldehændelsen viser derefter den udløste fejl og genoptages ved Exit_Handler. Dette er bedre, fordi det gør det muligt for kaldeproceduren at afslutte yndefuldt.

Hvis du vil bruge Northwind version 2.2-koden, skal hændelsesprocedurer overføre et tredje argument til HandleError , der angiver, at kalderen er en hændelsesprocedure. Northwind Dev Edition er blevet opdateret til at gøre det.

Et endnu mere kraftfuldt fejlbehandlingsmodul ville have understøttelse af "pushing and popping"-procedurer på en "stack" (array). Det første element vil altid være begivenhedsproceduren, så det ekstra argument er ikke nødvendigt. Denne implementering ligger ud over målene med Northwind Dev Edition.

MRU-liste

MRU eller Senest anvendte er en liste over senest anvendte ordrer og indkøbsordrer. Det kan være en god ide at gå tilbage til disse ofte for at placere dem i den næste status. MRU-lister ses ofte i Office-produkter som en liste over senest anvendte filer, som du måske ønsker at åbne igen.

Hvis du vil implementere MRU-funktionen i Northwind Dev Edition (som ikke findes i Starter Edition), skal du først oprette følgende elementer:

  1. En tabel til lagring af MRU-oplysninger.
  2. Kode, der skal opdateres tabellen, når en ordre eller indkøbsordre (IO) åbnes.
  3. Kode til opdatering af MRU-rullemenuen på båndet.
  4. Kode for at indlæse elementet, når et MRU-element vælges på båndet.

Lad os se nærmere på hver af disse. 

1. Tabel til lagring af MRU-oplysninger.

Designet af tabel MRU er værd at gennemgå, især dens indekser. Bemærk, at der er et dubletindeks SortIdx , som hjælper med hurtig sortering af MRU-elementerne på rullelisten på båndet, samt et entydigt indeks til at håndhæve forretningsreglen om, at et element kun kan forekomme én gang for hver bruger. Hvis du f.eks. åbner den samme ordre to gange, oprettes der ikke to poster i MRU-tabellen.

Tabellen udnytter, at alle MRU-relaterede PK-felter (primær nøgle) i databasen er autonummerering, så datatypen Langt heltal kan bruges til PKValue.

2. Kode til at opdatere tabellen, når en ordre eller ordre eller ordre åbnes.

I NW2 valgte vi kun at tilføje til MRU-listen, når en ny post blev oprettet, ikke når en eksisterende blev opdateret igen. Vi kunne bestemt flytte AddToMRU-opkaldet fra Form_AfterInsert til Form_AfterUpdate for at understøtte det.

AddToMRU- og DeleteFromMRU-procedurerne implementeres i modGlobal, som er et Standard-modul, hvis offentlige procedurer er synlige fra enhver form.

AddToMRU (som navnet antyder) føjer det nye element til MRU-tabellen og trimmer det derefter tilbage og sletter den ældste post, hvis den er vokset ud over den maksimale størrelse (MAX_MRU_COUNT). Det sidste trin er nok det mindst kendte for Access-udviklere: Rullelisten på båndet skal opdateres, og det gøres ved at kalde InvalidateControl. Dette er et signal til båndet om at køre initialiseringsprocessen igen. 

3. Kode til opdatering af MRU rulleliste på båndet.

På opstartstidspunktet, og efter at InvalidateControl er kaldt, udføres et komplekst sæt funktioner for at udfylde båndet.  Disse procedurer kaldes af bånd-XML i tabellen uSysRibbons , som blandt andet siger:


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

Disse fire tilbagekaldsfunktioner udfylder rullelisten. Bemærk, at det er meget den samme idé, som beskrevet heri for standardkombinationsfelter.

Hvis du fjerner kommentaren til Debug.Print linjerne i modRibbonCallback og genstarter programmet, viser vinduet Immediate en sekvens som denne: 


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

Vi kan se her, at Access først kalder en procedure, der returnerer antallet af elementer, der skal indlæses i argumentet ByRef for ddMRU_GetItemCount. Det er også det tidspunkt, hvor vi åbner forespørgslen på MRU-tabellen og cachelagrer den, fordi den er ved at blive brugt flere gange. 

Båndet kalder derefter to procedurer gentagne gange for at hente id- og etiketværdierne for rullelisten med to kolonner. 

Endelig kaldes der en procedure for at fjerne det element, der skal vælges. (I vores tilfælde er det den første.)

4. Kode til indlæsning af et element, når MRU-elementet er valgt på båndet.

Som med alle andre elementer på båndet angiver egenskaben VedHandling i bånd-XML'en tilbagekaldsfunktion, der skal bruges til at udføre handlingen:


onAction="ddMRU_OnAction"

Denne procedure er implementeret i modRibbonCallback. Det genbruger det allerede åbne postsæt til at finde posten med det valgte element og åbner derefter, afhængigt af det påkrævede Tabelnavn, den tilsvarende formular og overfører den PK-værdi, der skal indlæses.

Få mere at vide