Northwind 2.0 saker du bör känna till

VBA (Visual Basic for Applications) är programmeringsspråket som används i alla Office-produkter. Med Learning VBA kan du arbeta med alla Office-produkter (inte bara Access).
När du söker efter "instruktioner" ska du söka efter Access-specifika exempel och inkludera Microsoft Access i sökningen. Ofta fungerar lösningar för de andra Office-produkterna – men det finns ingen garanti. Microsoft Access är en mogen produkt. det innebär att det finns många exempel där ute; vilket är bra för dig! 

Det innebär också att äldre böcker om Access-programmering fortfarande är bra att titta på. Många av de äldre böckerna är fortfarande tillgängliga på begagnade bokwebbplatser till en bråkdel av deras ursprungliga kostnad. Gå till Microsofts webbplats för att se vilka versioner av Access som fortfarande stöds och följer med dem.

Upphörande av supportresurser för Office – Distribuera Office | Microsoft Learn  

Nedan finns några länkar till Access-dokumentationen på Microsoft.

• Referens för Access Visual Basic for Applications (VBA) | Microsoft Learn

• VBA-ordlista | Microsoft Learn

• Visual Basic konceptuella ämnen | Microsoft Learn

• Visual Basic for Applications – Wikipedia

• VBA-Docs/API på huvud - · MicrosoftDocs/VBA-Docs · Github

Microsoft Access-filer är Office-filer. Office-filer måste finnas på en "betrodd plats" eller ha deras "innehåll aktiverat". Dessa objekt anses vara "säkra" eftersom du har skapat dem, eller så har de kommit från en pålitlig källa. Sök efter betrodda platser varje gång du öppnar en office-fil. Vi kommer att referera till detta som Betrodd/Aktiverad härifrån. Obs! Om en ny version av programmet släpps och öppnas från en icke-betrodd plats kommer processen att aktivera innehållet att upprepas.

Läs mer om betrodda platser.: 

• Betrodda platser för Office-filer – Distribuera Office | Microsoft Learn

• Avgöra om en databas ska vara betrodd (Microsoft Support)

• Lägga till, ta bort eller ändra en betrodd plats (Microsoft Support)

Makron, funktioner och underobjekt är hur du implementerar affärslogik i Access-databasen. Det är viktigt för dig att förstå omfattning och synlighet innan du börjar.

• Makroåtgärden KörKod | Microsoft Learn

• Introduktion till makron | Microsoft Support

• Funktionssats (VBA) | Microsoft Learn

• Underordnat uttryck (VBA) | Microsoft Learn

Händelser (som att klicka på en kontroll) i kontroller i ett formulär (t.ex. knappar, textrutor, etiketter osv.) utlöser andra processer, till exempel att lägga till, ta bort poster eller öppna formulär. De här processerna kan implementeras med antingen makron eller VBA. Northwind Starter Edition använder främst makron och vissa VBA där makron inte kan utföra nödvändiga funktioner. Northwind Developer Edition använder främst VBA. 

Vissa kontrolltyper har inbyggda guider för att automatiskt skapa ett makro. Om du till exempel lägger till en kommandoknapp i ett formulär öppnas en guide med flera olika funktioner för knappen. När du lägger till en kombinationsruta öppnas en guide som kan konfigureras för att hitta en viss post i formuläret. 

Navigeringsfönstret är det huvudsakliga sättet att visa och komma åt alla databasobjekt och visas som standard till vänster i Access-fönstret. 
Navigeringsfönstret Northwind har anpassats. Vi har skapat en anpassad kategori med namnet Northwind Starter 2.0. Då kan vi ordna objekten efter funktionsområde.

• Använda navigeringsfönstret | Microsoft Support

• Anpassa navigeringsfönstret | Microsoft Support

Det är viktigt att lära sig mer om omfattning och synlighet i Access/Office. Du kan börja här: 

• Förstå omfattning och synlighet (VBA) | Microsoft Learn

• Offentligt uttalande (VBA) | Microsoft Learn

• Privat policy (VBA) | Microsoft Learn

• Statiskt uttryck (VBA) | Microsoft Learn

• Förstå livslängden för variabler (VBA) | Microsoft Learn

Ibland behöver du en variabel som finns efter att objektet som skapades går utanför omfånget. Se Omfattning och synlighet ovan. Det finns tre huvudsakliga sätt att göra detta: Offentliga variabler, TempVars och Lagring av värden i en lokal tabell. Många utvecklare använder en blandning av dessa. Var och en har sina för- och nackdelar.  Mer om var och en här: 

Offentlig variabel för VBA-modul: 

• Deklarera variabler (VBA) | Microsoft Learn

TempVars: 

• TempVars-objekt (Access) | Microsoft Learn

• Power Tips: Maximera användningen av TempVars i Access 2007 och 2010 | Microsoft 365-blogg

Lagra värdena i lokal tabell

• Offentliga variabler och TempVars finns för den aktuella sessionen och går utanför omfattningen när programmet stängs. Men vad händer om du vill behålla användarspecifika variabler över sessioner? Du kan lagra dessa typer av värden i en lokal tabell. I Northwind 2.0 sparas en sådan variabel i en tabell som kallas SystemSettings. Värdet i tabellen är VisaVälkommen. Det här värdet anger för Access om du vill se välkomstskärmen varje gång du loggar in eller inte.

Utvecklare behöver ofta överföra parametrar från ett formulär till ett annat, eller från ett formulär till en rapport. Dessa parametrar förmedlar viktig information som den anropade funktionen sedan använder för att konfigurera sig själv. Det finns flera sätt för det andra formuläret eller den andra rapporten att hämta information från det första formuläret. Här är några av dessa sätt: 

1. Det andra formuläret kan "titta tillbaka" på det första formuläret för att hämta vissa värden, eventuellt i antingen synlig eller osynlig kontroll.  Till exempel:
   lngCustomerID = Forms!FirstForm!cboCustomerID 

2. Det första formuläret kan spara värden till globala variabler eller till TempVars. Till exempel:
   g_lngUserID = Me.cboUserID 
   TempVars.Add "UserID", Me.cboUserID 

Den metod som ofta används i Northwind Developer Edition och i våra yrkesliv är att använda argumentet OpenArgs i DoCmd.OpenForm eller OpenReport. Till exempel:

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

Vi kombinerar två tekniker här: (1) användningen av OpenArgs för att passera i VendorID och VendorType, och (2) användningen av funktionen StringFormat() för att skapa till exempel den här strängen: 

CompanyID=5&CompanyTypeID=2 

Den här strängen ser mycket ut som en frågesträng som används i en webbläsare. Den innehåller ett eller flera "namn-/värdepar" avgränsade med et-tecken: 

name1=value1&name2=value2

Fördelen med en sådan sträng är att varje värde har ett namn. Jämför detta med en enklare metod där du endast anger OpenArgs till "5,2".  I ett sådant fall skulle det vara lämpligt att ta reda på vad varje värde betecknar. Om du namnger varje värde blir frågesträngen "självbeskriver" vilket är en bra programmeringspraxis.

I den mottagande änden av DoCmd.OpenForm är vi vanligtvis i händelsen Form_Open eller Form_Load och vill parsa OpenArgs-strängen i dess komponenter.

I Northwind kan du göra detta med funktionen StringToDictionary . Den tar en frågesträngsliknande funktion och tolkar den i dess komponenter. Dessa komponenter lagras sedan i ett Scripting.Dictionary-objekt . Observera att du måste använda Verktyg > Referenser och ange en referens till Microsoft Scripting Runtime (scrrun.dll).

Funktionerna och fördelarna med ordlisteobjektet omfattar följande:  

• Ordningen på elementen är inte viktig

• Enkla funktioner för att lägga till och ta bort element i samlingen

• Funktioner för att loopa över samlingen så att du vet vad som finns i den

• Funktionen Finns så att du kan testa om ett visst element är tillgängligt

Ordlisteobjektet används i hela Northwind. Till exempel Form_Load händelsen i frmGenericDialog.

Makron som skapats med Kontrollguider i Access innehåller sällan felhantering alls. VBA som skapats med Kontrollguider kan vara begränsat till en allmän MsgBox Err.Description.

I Northwind 2.0 visar vi dig hur du gör det bättre när du använder VBA-kod. Vi har implementerat vad som kallas global felhanterare. Fel som inträffar i en procedur anropar en funktion på global nivå för att visa felet. Den stora fördelen här är att felhantering är konsekvent. Och om meddelandet behöver ändras (t.ex. för att visa felnumret eller logga felet i en fil) måste det endast göras på ett ställe. 

clsErrorHandler är klassmodulen som implementerar felhanteringskoden. En klassmodul håller ihop alla sina huvud- och hjälpfunktioner i en enhet och kapslar därmed in koden.

AutoExec-makrot anropar startfunktionen i modStartup. I Starter Edition skapar funktionen en instans av clsErrorHandler och sparar den som en global variabel som är tillgänglig för användning i hela programmet. I Dev-utgåvan används en statisk klass – se kommentarerna högst upp i klassmodulen.

Faktum är att felhanteringskoden i procedurer är så konsekvent att vi kunde skapa allt på mindre än fem minuter med hjälp av specifik VBA-kod som utrustade varje procedur med rätt felhanterare. (Koden ingår inte i mallen). Mallutgåvorna Northwind 2.0 Starter och Developer har ursprungligen utrustats med den här metoden för felhantering. 
'

FÖRBÄTTRAD FELHANTERING

Från och med version 2.2 av Northwind Developer Edition har felhanteraren förbättrats tack vare feedback från Access-communityn. Startversionen ändras inte. 

I grund och botten är felhanteraren i den tidigare versionen (2.0 - släppt i april 2023):

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

I version 2.2 uppgraderas den till:

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

För att förstå varför den här ändringen gjordes ska vi först förstå vad som gör att kod körs:

• AutoExec-makrot anropar startproceduren, som utför vissa initieringar innan du öppnar det första formuläret.

• Användaren interagerar med programmet, som att öppna ett formulär eller klicka på en knapp, vilket gör att händelseprocedurer utlöses, till exempel Form_Load och cmdPrintInvoice_Click.
  '

Förutom händelseprocedurer har program subrutiner och funktioner – oftast i moduler – och den koden anropas från händelseprocedurerna. Dessa kallas "standardprocedurer".

I version 2.0 av Northwind skulle standardprocedurerna hantera sina egna fel med meddelanden, men de meddelade inte på något sätt proceduren för den anropande händelsen att ett fel hade inträffat. Det kan vara fel om händelseproceduren har efterföljande kod som ska köras oavsett vilket fel som tidigare hanterades av den anropade proceduren. Visst, vi kan ersätta subrutinen med en funktion som returnerar framgång eller fel och koda händelseproceduren i enlighet med detta, men det är inte alltid ett alternativ.

I Northwind version 2.2 hanterar standardprocedurerna inte felmeddelanden, utan rapporterar dem i stället tillbaka till anropshändelseproceduren med Err.Raise. I proceduren för den anropande händelsen visas sedan det upplyfta felet och återupptas vid Exit_Handler. Det här är bättre eftersom samtalsproceduren kan avslutas på ett smidigt sätt.

Om du vill använda Northwind version 2.2-koden måste händelseprocedurerna överföras till HandleError som ett tredje argument som anger att uppringaren är en händelseprocedur. Northwind Dev Edition har uppdaterats för att göra det.

En ännu kraftfullare felhanterare modul skulle ha stöd för "pushing och popping" procedurer på en "stack" (matris). Det första elementet skulle alltid vara händelseproceduren, så det extra argumentet behövs inte. Den här implementeringen är bortom målen för Northwind Dev Edition.

MRU eller Senast använda är en lista över senast använda order och inköpsorder. Du kanske vill gå tillbaka till dessa ofta för att placera dem i nästa status. MRU-listor visas ofta i Office-produkter som en lista över nyligen använda filer som du kanske vill öppna igen.

i Northwind Dev-utgåvan, för att implementera MRU-funktionen (som inte finns i Starter-utgåvan) måste du först ange följande objekt: 

1. En tabell för att lagra MRU-information.

2. Kod för att uppdatera tabellen när en order eller inköpsorder öppnas.

3. Kod för att uppdatera listrutan MRU i menyfliksområdet.

4. Kod för att läsa in objektet när ett MRU-objekt är markerat i menyfliksområdet.

Låt oss titta närmare på vart och ett av dessa. 

1. Tabell för att lagra MRU-information.

Utformningen av tabell MRU är värt att granska, särskilt dess index. Observera att det finns ett duplicerat index SortIdx som underlättar snabb sortering av MRU-objekten i menyfliksområdets listruta, samt ett unikt index för att tillämpa affärsregeln att ett objekt för varje användare bara kan ske en gång. Om du till exempel öppnar samma ordning två gånger skapas inte två poster i MRU-tabellen.

Tabellen drar nytta av att alla MRU-relaterade PK-fält (primärnyckel) i databasen är Räknare, så datatypen Långt heltal kan användas för PKValue.

2. Kod för att uppdatera tabellen när en order eller ett postnummer öppnas.

I NW2 valde vi att lägga till i MRU-listan endast när en ny post skapades, inte när en befintlig uppdaterades igen. Vi skulle verkligen kunna flytta AddToMRU-samtalet från Form_AfterInsert till Form_AfterUpdate för att stödja det.

Procedurerna AddToMRU och DeleteFromMRU genomförs i modGlobal, som är en standardmodul vars offentliga förfaranden är synliga från alla former.

AddToMRU (som namnet antyder) lägger till det nya objektet i MRU-tabellen och kan sedan trimma tillbaka det och ta bort den äldsta posten, om den har vuxit utöver maxstorleken (MAX_MRU_COUNT). Det sista steget är förmodligen det minst kända för Access-utvecklare: listrutan i menyfliksområdet måste uppdateras och det sker genom att anropa InvalidateControl. Det här är en signal till menyfliksområdet för att köra initieringsprocessen igen. 

3. Kod för uppdatering av listrutan MRU i menyfliksområdet. 

Vid start, och efter att InvalidateControl anropats, körs en komplex uppsättning funktioner för att fylla menyfliksområdet.  Dessa procedurer anropas av XML i menyfliksområdet i tabellen uSysRibbons som delvis säger:

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

De här fyra återanropsfunktionerna fyller i listrutan. Observera att detta i stort är samma idé som beskrivs häri för standard kombinationsrutor.

Om du tar bort kommenderingen av linjerna Debug.Print i modRibbonCallback och startar om programmet visas en sekvens som den här: 

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

Här kan vi se att Access först anropar en procedur som returnerar antalet objekt som ska läsas in i ByRef-argumentet för ddMRU_GetItemCount. Det här är också den tid då vi öppnar frågan i MRU-tabellen och cachelagrade den eftersom den är på väg att användas flera gånger. 

I menyfliksområdet anropas sedan två procedurer upprepade gånger för att hämta ID- och etikettvärdena för listrutan med två kolumner. 

Slutligen anropas en procedur för att ta bort vilket objekt som ska väljas. (I vårt fall är det den första.) 

4. Kod för inläsning av ett objekt när mru-objektet är markerat i menyfliksområdet.

Som med andra menyfliksobjekt anger egenskapen VidÅtgärd i menyfliksområdet XML en återanropsfunktion som ska användas för att utföra åtgärden:

onAction="ddMRU_OnAction"

Den här proceduren implementeras i modRibbonCallback. Den återanvänder den redan öppna postuppsättningen för att hitta posten med det markerade objektet och öppnar sedan, beroende på vilket TableName som krävs, motsvarande formulär och skickar in det PK-värde som ska läsas in.

• Northwind 2.0 Developer Edition: Mallhandledning

• Northwind 2.0 Developer Edition: Alla ämnen