Indholdet her kan gælde for Northwind 2.0 Developer Edition og Starter Edition.
VBA (Visual Basic for Applications) er det programmeringssprog, der bruges i alle Office-produkter. Læring VBA giver dig mulighed for at arbejde med alle Office-produkter (ikke kun Access).
Når du søger efter "sådan gør du", 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 voksenprodukt. det betyder, at der er mange eksempler derude; hvilket er fantastisk for dig!
Det betyder også, at ældre bøger om Access-programmering stadig er levedygtige for dig at se på. Mange af de ældre bøger er stadig tilgængelige på brugte bog sites på en brøkdel af deres oprindelige omkostninger. Kontrollér Microsoft-webstedet for at finde ud af, hvilke versioner af Access der stadig understøttes, og vælg dem.
Ophør af supportressourcer til Office – Installer Office | Microsoft Learn
Nedenfor finder du nogle links til Access-dokumentation hos Microsoft.
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 fordi de kommer fra en pålidelig kilde. Kontrollér, om der er tillid til placeringer, der er tillid til, hver gang du åbner en office-fil. Vi kalder det "Betroet/Aktiveret" herfra. 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 er den måde, du implementerer forretningslogik i din Access-database på. Det er vigtigt for dig at forstå Omfang og Synlighed før din start.
Hændelser (f.eks. at klikke på et kontrolelement) på kontrolelementer i en formular (f.eks. knapper, tekstfelter, navne osv.) udløser andre processer, f.eks. tilføjelse, sletning af poster eller åbning af formularer. Disse processer kan implementeres ved hjælp af enten makroer eller VBA. Northwind Starter Edition bruger mest makroer, og nogle VBA-filer, hvor makroer ikke kan udføre de nødvendige funktioner. Northwind Developer Edition bruger primært VBA.
Nogle kontrolelementtyper har indbyggede guider til automatisk at oprette en makro. Hvis du f.eks. føjer en kommandoknap til en formular, åbnes en guide, der indeholder flere valgmuligheder for knappen. Når du tilføjer et kombinationsfelt, åbnes en guide, der kan konfigureres til at finde en bestemt post i formularen.
Navigationsruden er den primære 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.
Navigationsruden Northwind 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.
Det er vigtigt at lære om omfang og synlighed i Access/Office. Du kan starte her:
Nogle gange skal der findes en variabel, efter at det objekt, der oprettede det, er uden for området. Se Omfang og synlighed ovenfor. Det kan du gøre på tre primære måder: Offentlige variabler, TempVars 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 enkelt her:
Offentlig VBA-modulvariabel:
TempVars:
Lagring af værdierne i en lokal tabel
-
Offentlige variabler og TempVars findes for den aktuelle session og går uden for området, når programmet lukkes. Men hvad nu, hvis du vil bevare brugerspecifikke variabler på tværs af sessioner? Du kan gemme disse typer af værdier i en lokal tabel. I Northwind 2.0 gemmes en sådan variabel 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.
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 bruger 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:
-
Den anden formular kan "se tilbage" på den første formular for at hente nogle værdier, muligvis i enten synligt eller usynligt kontrolelement. For eksempel:
lngCustomerID = Forms!FirstForm!cboCustomerID -
Den første formular kan gemme værdier i globale variabler eller i TempVars. For eksempel:
g_lngUserID = Me.cboUserID
TempVars.Add "UserID", Me.cboUserID
Den metode, der ofte bruges i Northwind Developer Edition samt i vores professionelle liv, bruger argumentet OpenArgs fra DoCmd.OpenForm eller OpenReport. For eksempel:
DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)
Vi kombinerer to teknikker her: (1) brugen af OpenArgs til at videregive i VendorID og VendorType, og (2) brugen af funktionen StringFormat() til at oprette f.eks. denne streng:
CompanyID=5&CompanyTypeID=2
Denne streng ligner i høj grad en forespørgselsstreng, som bruges i en browser. Den indeholder et eller flere "navne-/værdipar" 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 metode, hvor du kun indstiller OpenArgs til "5,2". I et sådant tilfælde ville det tage en indsats for at finde ud af, hvad hver værdi betyder. Hvis du navngiver hver enkelt værdi, bliver forespørgselsstrengen "selvbeskrivende", hvilket er en god programmeringspraksis.
I den modtagende ende af DoCmd.OpenForm befinder vi os typisk i Form_Open - ellerF-orm_Load-hændelsen og vil fortolke OpenArgs-strengen i dens komponenter.
I Northwind kan du gøre dette med funktionen StringToDictionary . Det tager en forespørgselsstrenglignende funktion og fortolker den i dens komponenter. Disse komponenter gemmes derefter i et Scripting.Dictionary-objekt . Bemærk, at dette kræver, at du bruger Værktøjer > Referencer og angiver en reference til Microsoft Scripting Runtime (scrrun.dll).
Funktionerne og fordelene ved ordbogsobjektet omfatter følgende:
-
Rækkefølgen af elementer er ikke vigtig
-
Enkle funktioner til at tilføje og fjerne elementer i samlingen
-
Funktioner til at skifte mellem samlingerne, så du ved, hvad der er i den
-
Funktionen Findes , så du kan teste, om et bestemt element er tilgængeligt
Brug af ordbogsobjektet vises i hele Northwind. Den Form_Load hændelse i frmGenericDialog.
Makroer, der oprettes med kontrolelementguider i Access, omfatter 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 procedure, kalder en funktion på globalt niveau for at vise fejlen. Den store fordel her er, at fejlhåndtering er ensartet. Og hvis meddelelsen skal ændres (f.eks. for at vise fejlnummeret eller logge fejlen på en fil), skal den kun udføres på ét sted.
clsErrorHandler er det klassemodul, der implementerer fejlhåndteringskoden. Et klassemodul holder alle de vigtigste funktioner og hjælperfunktioner samlet i én enhed og indkapsler dermed 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-udgave bruges en statisk klasse – se kommentarerne øverst i klassemodulet.
Faktisk er fejlhåndteringskoden i procedurer så ensartet, 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. (Koden er ikke inkluderet i skabelonen). Både Northwind 2.0 Starter- og Developer-skabelonudgaver blev oprindeligt udstyret med denne fejlhåndteringsmetode.
'
FORBEDRET FEJLHÅNDTERING
Fra og med version 2.2 af Northwind Developer Edition er fejlbehandleren blevet forbedret takket være feedback fra Access-communityet. Starterudgaven er uændret.
Kort sagt er fejlbehandleren i den tidligere version (2.0 - udgivet i april 2023):
Public Sub HandleError(…)
MsgBox Err.Description
End Sub
I version 2.2 opgraderes den 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
Lad os først forstå, hvorfor denne ændring blev foretaget, så lad os først forstå, hvad der får kode til at køre:
-
AutoExec-makroen kalder startproceduren, som udfører nogle initialiseringer, før den første formular åbnes.
-
Brugeren interagerer med programmet, f.eks. åbner en formular eller klikker på en knap, hvilket medfører, at hændelsesprocedurer udløses, f.eks. Form_Load og cmdPrintInvoice_Click.
'
Ud over hændelsesprocedurer har applikationer subrutiner og funktioner – for det meste i moduler – og denne kode kaldes fra hændelsesprocedurerne. Disse kaldes "standardprocedurer".
I version 2.0 af Northwind ville standardprocedurerne håndtere deres egne fejl med meddelelser, men de ville ikke på en eller anden måde give den kaldende hændelsesprocedure besked om, at der var opstået en fejl. Dette kan være forkert, hvis hændelsesproceduren har efterfølgende kode, der skal køre, uanset den forrige fejl, der håndteres af den kaldes procedure. Selvfølgelig kan 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 rapportér dem tilbage til den kaldende hændelsesprocedure ved hjælp af Err.Raise. Proceduren for kaldende hændelse viser derefter den opståne fejl og fortsætter på Exit_Handler. Dette er bedre, fordi det giver opkaldsproceduren mulighed for at afslutte yndefuldt.
Hvis du vil bruge Northwind version 2.2-koden, skal hændelsesprocedurer overføres til HandleError et tredje argument, der angiver, at den kaldende er en hændelsesprocedure. Northwind Dev Edition er blevet opdateret for at gøre det.
Et endnu mere effektivt fejlbehandlermodul ville have understøttelse af "skubbe og poppe"-procedurer på en "stak" (matrix). Det første element vil altid være hændelsesproceduren, så det ekstra argument er ikke nødvendigt. Denne implementering er uden for målene i Northwind Dev Edition.
MRU eller Senest anvendte er en liste over de 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 gerne vil åbne igen igen.
i Northwind Dev-udgaven skal du først oprette følgende elementer for at implementere MRU-funktionen (som ikke findes i Starter-udgaven):
-
En tabel til lagring af MRU-oplysninger.
-
Kode til at opdatere tabellen, når en ordre eller indkøbsordre (PO) åbnes.
-
Kode til opdatering af MRU-rullemenuen på båndet.
-
Kode til at indlæse elementet, når et MRU-element er markeret på båndet.
Lad os se nærmere på hver af disse.
1. Tabel til lagring af MRU-oplysninger.
Designet af tabellen MRU er værd at gennemgå, især dens indekser. Bemærk, at der er et duplikeret indeks SortIdx , der kan hjælpe med hurtig sortering af MRU-elementerne på rullelisten på båndet samt et entydigt indeks til at gennemtvinge forretningsreglen om, at et element kun kan forekomme én gang for hver bruger. Hvis du f.eks. åbner den samme rækkefølge to gange, oprettes der ikke to poster i MRU-tabellen.
Tabellen udnytter det faktum, 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 opdatering af tabellen, når en ordre eller postboks åbnes.
I NW2 valgte vi kun at føje til MRU-listen, når der blev oprettet en ny post, ikke når en eksisterende post blev opdateret igen. Vi kunne helt sikkert flytte AddToMRU opkaldet fra Form_AfterInsert til Form_AfterUpdate til at støtte det.
Procedurerne AddToMRU og DeleteFromMRU implementeres i modGlobal, som er et standardmodul, hvis offentlige procedurer er synlige fra enhver form.
AddToMRU (som navnet antyder) føjer det nye element til MRU-tabellen og kan derefter trimme det igen og slette den ældste post, hvis den er vokset ud over den maksimale størrelse (MAX_MRU_COUNT). Det sidste trin er sandsynligvis det mindst kendte for Access-udviklere: Rullemenuen på båndet skal opdateres, og det opnås ved at kalde InvalidateControl. Dette er et signal til båndet om at køre initialiseringsprocessen igen.
3. Kode til opdatering af mru-rullemenuen på båndet.
På starttidspunktet, og efter InvalidateControl kaldes, udføres der et komplekst sæt funktioner for at udfylde båndet. Disse procedurer kaldes af bånd-XML i tabel uSysRibbons , som delvis 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 dette er meget den samme idé som beskrevet heri for standard comboboxes.
Hvis du fjerner dekommenteringslinjerne Debug.Print i modRibbonCallback og genstarter programmet, viser Vinduet Brugerudtryk 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
Her kan vi se, at Access først kalder en procedure, der returnerer det antal elementer, der skal indlæses, i ByRef-argumentet for ddMRU_GetItemCount. Dette 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 gentagne gange to procedurer for at hente id- og etiketværdierne for rullemenuen med to kolonner.
Endelig kræves der en procedure for fjernelse af det element, der skal udvælges. (I vores tilfælde er det den første.)
4. Kode for indlæsning af et element, når MRU-elementet vælges fra båndet.
Som med alle andre elementer på båndet angiver egenskaben VedHandling i XML-båndet en tilbagekaldsfunktion, der skal bruges til at udføre handlingen:
onAction="ddMRU_OnAction"
Denne fremgangsmåde er implementeret i modRibbonCallback. Den genbruger det allerede åbne postsæt til at finde posten med det valgte element, og derefter åbner den tilsvarende formular afhængigt af det påkrævede Tabelnavn den tilsvarende formular, der videregiver den PK-værdi, der skal indlæses.
-
Northwind 2.0 Developer Edition: Skabelon-selvstudium
-
Northwind 2.0 Developer Edition: Alle emner
