Northwind 2.0 lucruri pe care ar trebui să le știți

VBA (Visual Basic for Applications) este limbajul de programare utilizat în toate produsele Office. VBA pentru învățare vă permite să lucrați cu toate produsele Office (nu doar cu Access).
Atunci când căutați "instrucțiuni", nu uitați să căutați exemple specifice Access și să includeți Microsoft Access în căutare. Adesea, soluțiile pentru alte produse Office vor funcționa - dar nu există nicio garanție. Microsoft Access este un produs pentru adulți; asta înseamnă că există o mulțime de exemple acolo; ceea ce este grozav pentru tine! 

De asemenea, înseamnă că cărțile mai vechi despre programarea Access sunt încă viabile pentru a fi analizate. Multe dintre cărțile mai vechi sunt încă disponibile pe site-urile de carte utilizate la o fractiune din costul lor original. Consultați site-ul web Microsoft pentru a determina ce versiuni de Access sunt încă acceptate și mergeți cu acestea.

Data de sfârșit al perioadei de asistență pentru Office - Implementarea Office | Microsoft Learn  

Mai jos sunt câteva linkuri către documentația Access de la Microsoft.

• Referință Access Visual Basic for Applications (VBA) | Microsoft Learn

• Glosar VBA | Microsoft Learn

• Subiecte conceptuale Visual Basic | Microsoft Learn

• Visual Basic for Applications - Wikipedia

• VBA-Docs/API în partea principală · MicrosoftDocs/VBA-Docs · Github

Fișierele Microsoft Access sunt fișiere Office. Fișierele Office trebuie să fie într-o "Locație de încredere" sau să aibă "conținutul activat". Aceste elemente sunt considerate "sigure", deoarece le-ați creat sau provin dintr-o sursă de încredere. Verificarea locațiilor de încredere are loc de fiecare dată când deschideți orice fișier Office. De aici înainte, vom face referire la acest lucru ca Fiind de încredere/activat. NOTĂ: Dacă o nouă versiune a aplicației este lansată și deschisă dintr-o locație care nu este de încredere, procesul de activare a conținutului se va repeta.

Aflați mai multe despre Locații de încredere: 

• Locații de încredere pentru fișiere Office - Implementarea Office | Microsoft Learn

• Decideți dacă să acordați încredere unei baze de date (Asistență Microsoft)

• Adăugarea, eliminarea sau modificarea unei locații de încredere (Asistență Microsoft)

Macrocomenzile, funcțiile și sub-urile sunt modul în care implementați business logic în baza de date Access. Este important să înțelegeți Domeniul de aplicare și vizibilitatea înainte de a începe.

• Acțiunea de macrocomandă RunCode | Microsoft Learn

• Introducere în macrocomenzile | Asistență Microsoft

• Instrucțiunea funcției (VBA) | Microsoft Learn

• Substrucțiune (VBA) | Microsoft Learn

Evenimentele (cum ar fi clicul pe un control) dintr-un formular (de exemplu, butoanele, casetele text, etichetele etc.) declanșează alte procese, cum ar fi adăugarea, ștergerea înregistrărilor sau deschiderea formularelor. Aceste procese pot fi implementate utilizând macrocomenzi sau VBA. Northwind Starter Edition utilizează în cea mai mare parte macrocomenzi și unele VBA, unde macrocomenzile nu pot efectua funcțiile necesare. Northwind Developer Edition utilizează în principal VBA. 

Unele tipuri de controale au experți încorporați pentru a crea automat o macrocomandă. De exemplu, adăugarea unui buton de comandă la un formular deschide un expert care oferă mai multe opțiuni de funcționalitate pentru buton. Adăugarea unei casete combo deschide un expert care poate fi configurat pentru a găsi o anumită înregistrare în formular. 

Panoul de navigare este modul principal în care vizualizați și accesați toate obiectele bazei de date și se afișează implicit în partea stângă a ferestrei Access. 
Panoul de navigare Northwind a fost particularizat. Am creat o categorie particularizată denumită Northwind Starter 2.0. Acest lucru ne permite să organizăm obiectele după zona funcțională.

• Utilizarea Panoului de navigare | Asistență Microsoft

• Particularizarea Panoului de navigare | Asistență Microsoft

Este important să aflați despre Domeniul de aplicare și vizibilitatea din Access/Office. Puteți începe de aici: 

• Înțelegerea domeniului de aplicare și a vizibilității (VBA) | Microsoft Learn

• Instrucțiune publică (VBA) | Microsoft Learn

• Instrucțiune privată (VBA) | Microsoft Learn

• Instrucțiune statică (VBA) | Microsoft Learn

• Înțelegerea duratei de viață a variabilelor (VBA) | Microsoft Learn

Uneori, aveți nevoie ca o variabilă să existe după ce obiectul care a creat-o iese din domeniu. Consultați Domeniul de aplicare și vizibilitatea de mai sus. Există trei modalități principale de a face acest lucru: Variabile publice, TempVar și Stocarea valorilor dintr-un tabel local. Mulți dezvoltatori folosesc o combinație între acestea. Fiecare are avantajele și dezavantajele sale.  Mai multe despre fiecare aici: 

Variabilă publică modul VBA: 

• Declarare variabile (VBA) | Microsoft Learn

Vare tempvare: 

• Obiectul TempVars (Access) | Microsoft Learn

• Sfat despre alimentare: Maximizarea utilizării TempVar în Access 2007 și 2010 | Microsoft 365 Blog

Stocarea valorilor în tabelul local

• Variabilele publice și TempVar există pentru sesiunea curentă și ies din domeniu atunci când aplicația este închisă. Dar ce se întâmplă dacă doriți să păstrați variabilele specifice utilizatorului în sesiuni? Puteți stoca aceste tipuri de valori într-un tabel local. În Northwind 2.0, o astfel de variabilă este salvată într-un tabel numit SystemSettings. Valoarea din tabel este ShowWelcome. Această valoare informează Access dacă doriți să vedeți ecranul Bun venit de fiecare dată când vă conectați sau nu.

Dezvoltatorii trebuie adesea să treacă parametrii de la un formular la altul sau de la un formular la un raport. Acești parametri transmit informații importante, pe care funcția apelată le va utiliza apoi pentru a se configura pe sine însăși. Există mai multe modalități pentru ca al doilea formular sau raport să obțină informații din primul formular. Iată câteva dintre aceste moduri: 

1. Al doilea formular poate "privi înapoi" la primul formular pentru a prelua unele valori, posibil în control vizibil sau invizibil.  De exemplu:
   lngCustomerID = Forms!FirstForm!cboCustomerID 

2. Primul formular poate salva valorile în variabile globale sau în TempVars. De exemplu:
   g_lngUserID = Me.cboUserID 
   TempVars.Add "UserID", Me.cboUserID 

Metoda utilizată adesea în Northwind Developer Edition, precum și în viața noastră profesională, este utilizarea argumentului OpenArgs din DoCmd.OpenForm sau OpenReport. De exemplu:

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

Combinăm două tehnici aici: (1) utilizarea OpenArgs pentru a trece în VendorID și VendorType și (2) utilizarea funcției StringFormat() pentru a crea, de exemplu, acest șir: 

CompanyID=5&CompanyTypeID=2 

Acest șir seamănă foarte mult cu un șir de interogare, așa cum este utilizat într-un browser. Conține una sau mai multe "perechi nume/valori" separate prin caracterul ampersand: 

name1=value1&name2=value2

Avantajul unui astfel de șir este că fiecare valoare are un nume. Comparați această abordare cu o abordare mai simplă, în care ați seta OpenArgs doar la "5,2".  Într-un astfel de caz, ar fi nevoie de efort pentru a afla ce înseamnă fiecare valoare. Denumirea fiecărei valori face șirul de interogare "auto-descriere", care este o bună practică de programare.

La sfârșitul doCmd.OpenForm de primire, ne aflăm de obicei în evenimentul Form_Open sau Form_Load și dorim să analizăm șirul OpenArgs în componentele sale.

În Northwind puteți face acest lucru cu funcția StringToDictionary . Preia o funcție similară unui șir de interogare și o analizează în componentele sale. Aceste componente sunt stocate apoi într-un obiect Scripting.Dictionary . Rețineți că acest lucru vă solicită să utilizați Instrumente > Referințe și să setați o referință la Microsoft Scripting Runtime (scrrun.dll).

Printre caracteristicile și avantajele obiectului Dictionary se numără următoarele:  

• Ordinea elementelor nu este importantă

• Funcții simple pentru adăugarea și eliminarea elementelor colecției

• Funcții pentru executarea în buclă a colecției, astfel încât să puteți ști ce conține

• O funcție Exists , astfel încât să puteți testa dacă un anumit element este disponibil

Utilizarea obiectului dicționar apare în Northwind. De exemplu, evenimentul Form_Load în frmGenericDialog.

Macrocomenzile create cu Experți control în Access rareori includ gestionarea erorilor; VBA creat cu Experți control poate fi limitată la o eroare de casetă MsgBox generică.

În Northwind 2.0, vă vom arăta cum să o faceți mai bine atunci când utilizați cod VBA. Am implementat ceea ce se numește rutină de tratare a erorilor globale. Erorile care apar în orice procedură apelează o funcție la nivel global pentru a afișa eroarea. Marele avantaj aici este că gestionarea erorilor este consistentă. Iar dacă mesajul trebuie să se modifice (de exemplu, pentru a afișa în plus numărul erorii sau pentru a înregistra eroarea într-un fișier), aceasta trebuie efectuată într-un singur loc. 

clsErrorHandler este modulul de clasă care implementează codul de tratare a erorilor. Un modul de clasă își păstrează toate funcțiile principale și de ajutor împreună într-o singură unitate, încapsulând astfel codul.

Macrocomanda AutoExec apelează funcția Startup în modStartup. În Starter Edition, funcția creează o instanță de clsErrorHandler și o salvează ca variabilă globală care este disponibilă pentru utilizare în întreaga aplicație. În ediția Dev este utilizată o clasă statică - vedeți comentariile din partea de sus a modulului de clasă.

De fapt, codul de tratare a erorilor în proceduri este atât de consistent, încât am putut să-l creăm pe toate în mai puțin de cinci minute, utilizând cod VBA specific, care a echipat fiecare procedură cu rutina corectă de tratare a erorilor. (Codul nu este inclus în șablon). Atât edițiile de șabloane Northwind 2.0 Starter, cât și cele pentru dezvoltatori au fost inițial echipate cu această abordare de tratare a erorilor. 
'

GESTIONARE ÎMBUNĂTĂȚITĂ A ERORILOR

Începând cu versiunea 2.2 a Northwind Developer Edition, rutina de tratare a erorilor a fost îmbunătățită, datorită feedbackului de la comunitatea Access. Ediția Starter este neschimbată. 

În esență, rutina de tratare a erorilor din versiunea anterioară (2.0 - lansată în aprilie 2023) este:

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

În versiunea 2.2, se face upgrade la:

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

Pentru a înțelege de ce s-a efectuat această modificare, să înțelegem mai întâi ce face codul să ruleze:

• Macrocomanda AutoExec apelează procedura de pornire, care efectuează unele inițializări înainte de a deschide primul formular.

• Utilizatorul interacționează cu aplicația, cum ar fi deschiderea unui formular sau clicul pe un buton, determinând declanșirea procedurilor evenimentului, cum ar fi Form_Load și cmdPrintInvoice_Click.
  '

În plus față de procedurile de eveniment, aplicațiile au subrutine și funcții - mai ales în module - și acel cod este apelat din procedurile evenimentului. Acestea se numesc proceduri "standard".

În versiunea 2.0 de Northwind, procedurile standard ar trata propriile erori cu mesajele, dar nu ar notifica într-un fel procedura eveniment de apelare că s-a produs o eroare. Acest lucru poate fi rău dacă procedura eveniment are cod ulterior care ar trebui să ruleze indiferent de eroarea anterioară gestionată de procedura apelată. Sigur, am putea înlocui subrutina cu o funcție care returnează succes sau eșec și codăm procedura eveniment în consecință, dar aceasta nu este întotdeauna o opțiune.

În Northwind versiunea 2.2, procedurile standard nu gestionează mesajele de eroare, ci, mai degrabă, folosind Err.Raise, raportează-le înapoi la procedura evenimentului de apelare. Procedura evenimentului de apelare afișează apoi eroarea ridicată și revine la Exit_Handler. Acest lucru este mai bine, deoarece permite procedurii de apelare să se încheie cu grație.

Pentru a utiliza codul Northwind versiunea 2.2, procedurile evenimentului trebuie să treacă în HandleError un al treilea argument care indică faptul că apelantul este o procedură eveniment. Northwind Dev Edition a fost actualizat pentru a face acest lucru.

Un modul de rutină de tratare a erorilor și mai puternic ar avea suport pentru procedurile de "împingere și de mac" pe o "stivă" (matrice). Primul element ar fi întotdeauna procedura eveniment, prin urmare, argumentul suplimentar nu este necesar. Această implementare depășește obiectivele Northwind Dev Edition.

MRU sau Recent utilizate este o listă de comenzi și comenzi de cumpărare utilizate recent. Se recomandă să reveniți frecvent la acestea pentru a le amplasa în următoarea Stare. Listele MRU sunt văzute adesea în produsele Office ca listă de fișiere utilizate recent pe care poate doriți să le redeschideți.

în ediția Northwind Dev, pentru a implementa caracteristica MRU (care nu există în ediția Starter), trebuie să stabiliți mai întâi următoarele elemente: 

1. Un tabel pentru stocarea informațiilor MRU.

2. Cod pentru actualizarea tabelului atunci când se deschide o comandă de comandă sau o comandă de cumpărare.

3. Cod pentru actualizarea listei verticale MRU din panglică.

4. Cod pentru a încărca elementul atunci când este selectat un element MRU din panglică.

Să ne uităm la fiecare dintre acestea în mai multe detalii. 

1. Tabel pentru stocarea informațiilor MRU.

Proiectarea tabelului MRU merită revizuită, în special indexurile sale. Rețineți că există un index SortIdx dublat pentru a ajuta la sortarea rapidă a elementelor MRU în lista verticală din panglică, precum și un index unic pentru a impune regula de afaceri care, pentru fiecare utilizator, un element poate apărea o singură dată. De exemplu, deschiderea aceleiași comenzi de două ori nu creează două înregistrări în tabelul MRU.

Tabelul profită de faptul că toate câmpurile PK legate de MRU (cheia primară) din baza de date sunt Numerotare automată, astfel încât tipul de date Întreg lung poate fi utilizat pentru PKValue.

2. Cod pentru actualizarea tabelului atunci când se deschide o comandă sau un P.O.

În NW2, am ales să adăugăm la lista MRU doar atunci când s-a creat o înregistrare nouă, nu și atunci când una existentă a fost actualizată din nou. Cu siguranță am putea muta apelul AddToMRU de la Form_AfterInsert la Form_AfterUpdate pentru a susține acest lucru.

Procedurile AddToMRU și DeleteFromMRU sunt implementate în modGlobal, care este un modul standard ale cărui proceduri publice sunt vizibile din orice formular.

AddToMRU (așa cum sugerează și numele) adaugă elementul nou la tabelul MRU, apoi, opțional, îl ajustează înapoi, ștergând cea mai veche înregistrare, dacă a crescut dincolo de dimensiunea maximă (MAX_MRU_COUNT). Ultimul pas este probabil cel mai puțin cunoscut dezvoltatorilor Access: lista verticală din panglică trebuie să fie reîmprospătată și aceasta se realizează apelând InvalidateControl. Acesta este un semnal către panglică pentru a rula din nou procesul de inițializare. 

3. Cod pentru actualizarea listei verticale MRU din panglică. 

La momentul pornirii și după ce se apelează InvalidateControl , se execută un set complex de funcții pentru a popula panglica.  Aceste proceduri sunt apelate de către XML-ul panglicii din tabelul uSysRibbons , care spune în parte:

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

Aceste patru funcții de apelare inversă populează lista verticală. Rețineți că această idee este similară cu cea descrisă aici pentru casetele combo standard.

Dacă decommentați liniile Debug.Print în modRibbonCallback și reporniți aplicația, Fereastra imediată va prezenta o secvență ca aceasta: 

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

Putem vedea aici că Access apelează mai întâi o procedură care returnează numărul de elemente de încărcat în argumentul ByRef al ddMRU_GetItemCount. De asemenea, acesta este momentul când deschidem interogarea în tabelul MRU și o memorăm în cache, deoarece este pe punctul de a fi utilizată de mai multe ori. 

Panglica apelează apoi în mod repetat două proceduri pentru a obține valorile ID și Label pentru lista verticală cu două coloane. 

În sfârșit, acesta apelează o procedură pentru a dezactiva elementul care ar trebui selectat. (În cazul nostru, este primul.) 

4. Cod pentru încărcarea unui element atunci când elementul MRU este selectat din panglică.

La fel ca în cazul oricărui alt element din panglică, proprietatea OnAction din XML-ul panglicii specifică o funcție de apelare inversă de utilizat pentru a efectua acțiunea:

onAction="ddMRU_OnAction"

Această procedură este implementată în modRibbonCallback. Acesta utilizează din nou setul de înregistrări deja deschis pentru a găsi înregistrarea cu elementul selectat, apoi, în funcție de TableName necesar, deschide formularul corespunzător, trecând prin valoarea PK pentru a fi încărcat.

• Northwind 2.0 Developer Edition: Template-Tutorial

• Northwind 2.0 Developer Edition: Toate subiectele