Innholdet her kan gjelde for Northwind 2.0 Developer Edition og Starter Edition.
VBA (Visual Basic for Applications) er programmeringsspråket som brukes i alle Office-produkter. Ved å lære VBA kan du arbeide med alle Office-produkter (ikke bare Access).
Når du søker etter «fremgangsmåte», må du passe på å se etter bestemte eksempler i Access og inkludere Microsoft Access i søket. Ofte vil løsninger for de andre Office-produktene fungere – men det finnes ingen garanti. Microsoft Access er et modent produkt. det betyr at det finnes mange eksempler der ute; som er flott for deg!
Det betyr også at eldre bøker om Access-programmering fremdeles er levedyktige for deg å se på. Mange av de eldre bøkene er fortsatt tilgjengelige på brukte boknettsteder til en brøkdel av den opprinnelige kostnaden. Sjekk Microsoft-nettstedet for å finne ut hvilke versjoner av Access som fremdeles støttes, og gå til disse.
Slutt på støtteressurser for Office - Distribuer Office | Microsoft Learn
Nedenfor finner du noen koblinger til Access-dokumentasjon hos Microsoft.
Microsoft Access-filer er Office-filer. Office-filer må være i en klarert plassering eller ha innholdet aktivert. Disse elementene anses som "trygge" fordi du opprettet dem, eller de har kommet fra en pålitelig kilde. Se etter klarerte plasseringer forekommer hver gang du åpner en Office-fil. Vi vil referere til dette som klarert/aktivert herfra. OBS! Hvis en ny versjon av programmet utgis og åpnes fra en ikke-klarert plassering, gjentas prosessen med å aktivere innholdet.
Mer informasjon om klarerte plasseringer.:
Makroer, funksjoner og subs er måten du implementerer forretningslogikk i Access-databasen på. Det er viktig for deg å forstå omfang og synlighet før du begynner.
Hendelser (som å klikke på en kontroll) på kontroller i et skjema (for eksempel knapper, tekstbokser, etiketter osv.) utløser andre prosesser, for eksempel å legge til, slette poster eller åpne skjemaer. Disse prosessene kan implementeres ved hjelp av makroer eller VBA. Northwind Starter Edition bruker for det meste makroer, og noen VBA der makroer ikke kan utføre nødvendige funksjoner. Northwind Developer Edition bruker hovedsakelig VBA.
Noen kontrolltyper har innebygde veivisere for automatisk oppretting av en makro. Hvis du for eksempel legger til en kommandoknapp i et skjema, åpnes en veiviser som tilbyr flere valg av funksjonalitet for knappen. Når du legger til en kombinasjonsboks, åpnes en veiviser som kan konfigureres til å finne en bestemt post i skjemaet.
Navigasjonsruten er hovedmåten for visning og tilgang til alle databaseobjektene, og den vises på venstre side av Access-vinduet som standard.
Northwind-navigasjonsruten er tilpasset. Vi opprettet en egendefinert kategori kalt Northwind Starter 2.0. Dette gjør at vi kan organisere objektene etter funksjonsområde.
Det er viktig å lære om omfang og synlighet i Access/Office. Du kan starte her:
Noen ganger trenger du at det finnes en variabel etter objektet som ble opprettet. Se omfang og synlighet ovenfor. Det finnes tre primære måter å gjøre dette på: Offentlige variabler, TempVars og lagring av verdiene i en lokal tabell. Mange utviklere bruker en blanding av disse. Hver har sine fordeler og ulemper. Mer om hver av dem her:
Offentlig VBA-modulvariabel:
TempVars:
Lagre verdiene i lokal tabell
-
Offentlige variabler og TempVars finnes for gjeldende økt og går ut av omfanget når programmet lukkes. Men hva om du vil beholde brukerspesifikke variabler på tvers av økter? Du kan lagre disse verditypene i en lokal tabell. I Northwind lagres én slik variabel i en tabell som kalles SystemSettings. Verdien i tabellen er ShowWelcome. Denne verdien forteller Access om du vil se velkomstskjermen hver gang du logger på eller ikke.
Utviklere må ofte sende parametere fra ett skjema til et annet, eller fra et skjema til en rapport. Disse parameterne formidler viktig informasjon, som den kalte funksjonen deretter vil bruke til å konfigurere seg selv. Det finnes flere måter for det andre skjemaet eller den andre rapporten å få informasjon fra det første skjemaet på. Her er et par av disse måtene:
-
Det andre skjemaet kan "se tilbake" til det første skjemaet for å plukke opp noen verdier, muligens i enten synlig eller usynlig kontroll. Eksempel:
lngCustomerID = Forms!FirstForm!cboCustomerID -
Det første skjemaet kan lagre verdier i globale variabler eller i TempVars. Eksempel:
g_lngUserID = Me.cboUserID
TempVars.Add "UserID", Me.cboUserID
Metoden som ofte brukes i Northwind Developer Edition så vel som i våre profesjonelle liv, bruker OpenArgs-argumentet i DoCmd.OpenForm eller OpenReport. Eksempel:
DoCmd.OpenForm "frmCompanyDetail", OpenArgs:=StringFormat("CompanyID={0} &CompanyTypeID={1}", Me.VendorID, ctVendor)
Vi kombinerer to teknikker her: (1) bruken av OpenArgs til å sende inn VendorID og VendorType, og (2) bruken av StringFormat() -funksjonen til å opprette, for eksempel denne strengen:
CompanyID=5&CompanyTypeID=2
Denne strengen ligner veldig mye på en spørringsstreng som brukes i en nettleser. Den inneholder ett eller flere navn/verdipar atskilt med ampersandtegnet:
name1=value1&name2=value2
Fordelen med en slik streng er at hver verdi har et navn. Sammenlign dette med en enklere fremgangsmåte der du bare setter OpenArgs til «5,2». I et slikt tilfelle vil det kreve innsats for å finne ut hva hver verdi betyr. Hvis du navngir hver verdi, blir spørringsstrengen "selvbeskrivende" som er en god programmeringspraksis.
På mottakersiden av DoCmd.OpenForm er vi vanligvis i Form_Open - eller Form_Load-hendelsen og vil analysere OpenArgs-strengen i komponentene.
I Northwind kan du gjøre dette med StringToDictionary-funksjonen . Den tar en spørrestrenglignende funksjon og analyserer den i komponentene. Disse komponentene lagres deretter i et Scripting.Dictionary-objekt . Vær oppmerksom på at hvis du gjør dette, må du bruke Verktøy >-referanser og angi en referanse til Microsoft Scripting Runtime (scrrun.dll).
Funksjonene og fordelene med ordlisteobjektet omfatter følgende:
-
Rekkefølgen på elementene er ikke viktig
-
Enkle funksjoner for å legge til og fjerne elementer i samlingen
-
Funksjoner som skal gjentas over samlingen, slik at du kan vite hva som er i den
-
En Exists-funksjon , slik at du kan teste om et bestemt element er tilgjengelig
Bruk av ordlisteobjektet vises i hele Northwind. For eksempel Form_Load-hendelsen i frmGenericDialog.
Makroer som er opprettet med kontrollveivisere i Access, inkluderer sjelden feilbehandling i det hele tatt. VBA opprettet med kontrollveivisere kan være begrenset til en generisk MsgBox Err.Description.
I Northwind 2.0 viser vi deg hvordan du gjør det bedre når du bruker VBA-kode. Vi har implementert det som kalles en global feilbehandling. Feil som oppstår i en hvilken som helst prosedyre, kaller en funksjon på globalt nivå for å vise feilen. Den store fordelen her er at feilbehandling er konsekvent. Og hvis meldingen må endres (for eksempel hvis du vil vise feilnummeret eller logge feilen til en fil), må den bare gjøres på ett sted.
clsErrorHandler er klassemodulen som implementerer feilbehandlingskoden. En klassemodul holder alle hovedfunksjonene og hjelpefunksjonene samlet i én enhet, og dermed innkapsler koden.
AutoExec-makroen kaller oppstartsfunksjonen i modStartup. I Starter Edition oppretter funksjonen en forekomst av clsErrorHandler og lagrer den som en global variabel som er tilgjengelig for bruk i hele programmet. I Utvikling-utgaven brukes en statisk klasse – se kommentarene øverst i klassemodulen.
Faktisk er feilbehandlingskoden i prosedyrer så konsekvent at vi kunne opprette alt på mindre enn fem minutter ved hjelp av spesifikk VBA-kode som utstyrte hver prosedyre med riktig feilbehandling. (Koden er ikke inkludert i malen). Både Northwind 2.0 Starter- og Developer-malutgaver ble opprinnelig utstyrt med denne feilhåndteringstilnærmingen.
'
FORBEDRET FEILBEHANDLING
Fra og med versjon 2.2 av Northwind Developer Edition er feilbehandlingen forbedret, takket være tilbakemeldinger fra Access-fellesskapet. Startutgaven er uendret.
I hovedsak er feilbehandlingen i den forrige versjonen (2.0 - utgitt i april 2023):
Public Sub HandleError(…)
MsgBox Err.Description
End Sub
I versjon 2.2 oppgraderes 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
For å forstå hvorfor denne endringen ble gjort, la oss først forstå hva som får koden til å kjøre:
-
AutoExec-makroen kaller oppstartsprosedyren, som utfører noen initialiseringer før du åpner det første skjemaet.
-
Brukeren samhandler med programmet, for eksempel å åpne et skjema eller klikke på en knapp, noe som fører til at hendelsesprosedyrer utløses, for eksempel Form_Load og cmdPrintInvoice_Click.
'
I tillegg til hendelsesprosedyrer har programmer underrutiner og funksjoner – for det meste i moduler – og denne koden kalles fra hendelsesprosedyrene. Disse kalles «standard»-prosedyrer.
I versjon 2.0 av Northwind vil standardprosedyrene håndtere sine egne feil med meldinger, men de ville på en eller annen måte ikke varsle hendelsesprosedyren for anrop om at det hadde oppstått en feil. Dette kan være dårlig hvis hendelsesprosedyren har etterfølgende kode som skal kjøre uavhengig av den forrige feilen som ble håndtert av den kalte prosedyren. Jada, vi kan erstatte delrutinen med en funksjon som returnerer vellykket eller mislykket, og kode hendelsesprosedyren tilsvarende, men det er ikke alltid et alternativ.
I Northwind versjon 2.2 håndterer ikke standardprosedyrene feilmeldinger, men heller ved hjelp av Err.Raise, rapporterer du dem tilbake til prosedyren for anropshendelsen. Prosedyren for anropshendelsen viser deretter den opphøyde feilen og CV-ene på Exit_Handler. Dette er bedre, fordi det gjør at anropsprosedyren kan konkludere grasiøst.
Hvis du vil bruke Northwind versjon 2.2-koden, må hendelsesprosedyrene sende til HandleError et tredje argument som angir at anroperen er en hendelsesprosedyre. Northwind Dev Edition er oppdatert for å gjøre dette.
En enda kraftigere modul for feilbehandling ville ha støtte for «skyve- og popping»-prosedyrer på en «stabel» (matrise). Det første elementet vil alltid være hendelsesprosedyren, så det ekstra argumentet er ikke nødvendig. Denne implementeringen er utenfor målene til Northwind Dev Edition.
MRU eller Sist brukt er en liste over nylig brukte ordrer og innkjøpsordrer. Du kan gå tilbake til disse ofte for å plassere dem i neste status. MRU-lister vises ofte i Office-produkter som en liste over nylig brukte filer som du kanskje vil åpne på nytt.
I Northwind Dev-utgaven må du først etablere følgende elementer for å implementere MRU-funksjonen (som ikke finnes i Starter-utgaven):
-
En tabell for lagring av MRU-informasjon.
-
Kode for å oppdatere tabellen når en bestilling eller innkjøpsordre (PO) åpnes.
-
Kode for å oppdatere rullegardinlisten for MRU på båndet.
-
Kode for å laste inn elementet når et MRU-element er valgt fra båndet.
La oss se nærmere på hver av disse.
1. Tabell for lagring av MRU-informasjon.
Utformingen av tabellen MRU er verdt gjennomgang, spesielt dens indekser. Vær oppmerksom på at det finnes en duplisert indeks-SortIdx for å hjelpe med rask sortering av MRU-elementene i rullegardinlisten på båndet, samt en unik indeks for å fremtvinge forretningsregelen som for hver bruker kan forekomme bare én gang. Hvis du for eksempel åpner den samme rekkefølgen to ganger, opprettes det ikke to poster i MRU-tabellen.
Tabellen drar nytte av det faktum at alle MRU-relaterte PK-felt (primærnøkkel) i databasen er Autonummer, slik at datatypen Langt heltall kan brukes for PKValue.
2. Kode for å oppdatere tabellen når en ordre eller P.O. åpnes.
I NW2 valgte vi å legge til i MRU-listen bare når en ny post ble opprettet, ikke når en eksisterende ble oppdatert på nytt. Vi kan absolutt flytte AddToMRU-kallet fra Form_AfterInsert til Form_AfterUpdate for å støtte det.
Prosedyrene AddToMRU og DeleteFromMRU implementeres i modGlobal, som er en standardmodul der offentlige prosedyrer er synlige fra alle skjemaer.
AddToMRU (som navnet antyder) legger til det nye elementet i MRU-tabellen, og trimmer det eventuelt tilbake og sletter den eldste posten hvis det har vokst utover den maksimale størrelsen (MAX_MRU_COUNT). Det siste trinnet er sannsynligvis det minst kjente for Access-utviklere: Rullegardinlisten på båndet må oppdateres, og dette gjøres ved å kalle InvalidateControl. Dette er et signal til båndet for å kjøre initialiseringsprosessen på nytt.
3. Kode for å oppdatere rullegardinlisten FOR MRU på båndet.
Ved oppstart, og etter at InvalidateControl kalles, utføres et komplekst sett med funksjoner for å fylle ut båndet. Disse prosedyrene kalles av XML-filen på båndet i tabellen uSysRibbons , som delvis sier:
<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 tilbakeringingsfunksjonene fyller rullegardinlisten. Vær oppmerksom på at dette er veldig mye den samme ideen som beskrevet her for standard kombinasjonsbokser.
Hvis du opphever debug.Print-linjene i modRibbonCallback og starter programmet på nytt, vil øyeblikksvinduet presentere en sekvens som dette:
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 kaller en prosedyre som returnerer antall elementer som skal lastes inn i ByRef-argumentet i ddMRU_GetItemCount. Dette er også tidspunktet da vi åpner spørringen på MRU-tabellen og bufrer den fordi den er i ferd med å bli brukt flere ganger.
Båndet kaller deretter gjentatte ganger to prosedyrer for å hente ID- og etikettverdiene for rullegardinlisten med to kolonner.
Til slutt kaller den opp en prosedyre for å disovere hvilket element som skal velges. (I vårt tilfelle er det den første.)
4. Kode for innlasting av et element når MRU-elementet er valgt fra båndet.
Som med alle andre båndelementer angir OnAction-egenskapen i XML-båndet en tilbakeringingsfunksjon som skal brukes til å utføre handlingen:
onAction="ddMRU_OnAction"
Denne prosedyren er implementert i modRibbonCallback. Den bruker det allerede åpne postsettet på nytt til å finne posten med det valgte elementet, og åpner deretter det tilsvarende skjemaet, som sender inn PK-verdien som skal lastes inn, avhengig av tabellnavnet som kreves.
-
Northwind 2.0 Developer Edition: Template-Tutorial
-
Northwind 2.0 Developer Edition: Alle emner
