Tudnivalók a Northwind 2.0-ról

A VBA (Visual Basic for Applications) az összes Office-termékben használt programozási nyelv. A VBA elsajátítása lehetővé teszi, hogy az összes Office-termékkel (nem csak az Accessrel) dolgozzon.
Az "útmutató" kifejezés keresésekor mindenképpen keressen access-specifikus példákat, és a keresésbe foglalja bele a Microsoft Accesst. A többi Office-termékhez gyakran fognak működni a megoldások , de erre nincs garancia. A Microsoft Access egy érett termék; ez azt jelenti, hogy sok példa létezik; ami nagyszerű az Ön számára! 

Ez azt is jelenti, hogy az Access programozóiról szóló régebbi könyvek továbbra is működőképesek. Sok a régebbi könyvek még mindig elérhető a használt könyv oldalak töredékét az eredeti költség. Tekintse meg a Microsoft webhelyét, és állapítsa meg, hogy az Access mely verzióit továbbra is támogatják, és folytassa azokkal.

Az Office támogatási forrásainak megszűnése – Az Office telepítése | Microsoft Learn  

Az alábbiakban néhány hivatkozás található a Microsoft Access-dokumentációra.

• Az Access Visual Basic for Applications (VBA) referenciája | Microsoft Learn

• VBA-szószedet | Microsoft Learn

• Visual Basic fogalmi témakörök | Microsoft Learn

• Visual Basic for Applications – Wikipédia

• VBA-Docs/API a fő · MicrosoftDocs/VBA-Docs · Github

A Microsoft Access-fájlok Office-fájlok. Az Office-fájloknak megbízható helyen kell lenniük, vagy engedélyezve kell lenniük a tartalomnak. Ezek az elemek azért tekinthetők "biztonságosnak", mert Ön hozta létre őket, vagy megbízható forrásból származnak. Minden office-fájl megnyitásakor ellenőrizze, hogy vannak-e megbízható helyek. Ezt innen megbízhatóként/engedélyezveként fogjuk hivatkozni. MEGJEGYZÉS: Ha az alkalmazás új verzióját adják ki és nyitják meg egy nem megbízható helyről, a tartalom engedélyezésének folyamata megismétlődött.

További információ a megbízható helyekről: 

• Office-fájlok megbízható helyei – Az Office telepítése | Microsoft Learn

• Döntse el, hogy megbízik-e egy adatbázisban (Microsoft ügyfélszolgálata)

• Megbízható hely hozzáadása, eltávolítása vagy módosítása (Microsoft ügyfélszolgálata)

A makrók, függvények és alalkalmazások segítségével valósíthat meg üzleti logikát az Access-adatbázisban. Fontos, hogy a kezdés előtt megértse a hatókört és a láthatóságot .

• RunCode makróművelet | Microsoft Learn

• Bevezetés a makrók használatába | Microsoft ügyfélszolgálata

• Függvényutasítás (VBA) | Microsoft Learn

• Alutasítás (VBA) | Microsoft Learn

Az űrlap vezérlőinek (például gombok, szövegdobozok, címkék stb.) eseményei (például egy vezérlőelemre kattintás) más folyamatokat is elindítanak, például rekordok hozzáadását, törlését vagy űrlapok megnyitását. Ezek a folyamatok makrók vagy VBA használatával valósíthatók meg. A Northwind Starter Edition többnyire makrókat használ, és néhány VBA-t, ahol a makrók nem tudják végrehajtani a szükséges funkciókat. A Northwind Developer Edition elsősorban VBA-t használ. 

Egyes vezérlőtípusok beépített varázslókkal rendelkeznek, amelyek automatikusan létrehoznak egy makrót. Ha például parancsgombot ad hozzá egy űrlaphoz, megnyílik egy varázsló, amely számos funkciót kínál a gombhoz. Kombinált lista hozzáadásakor megnyílik egy varázsló, amely konfigurálható egy adott rekord megkeresésére az űrlapon. 

A navigációs ablak az összes adatbázis-objektum megtekintésének és elérésének fő módja, és alapértelmezés szerint az Access ablak bal oldalán jelenik meg. 
A Northwind navigációs ablaka testre lett szabva. Létrehoztunk egy Northwind Starter 2.0 nevű egyéni kategóriát. Ez lehetővé teszi, hogy funkcionális terület szerint rendszerezzük az objektumokat.

• A navigációs ablak használata | Microsoft ügyfélszolgálata

• A navigációs ablak testreszabása | Microsoft ügyfélszolgálata

Fontos, hogy megismerje a hatókört és a láthatóságot az Accessben/Office-on belül. Itt kezdheti el: 

• A hatókör és a láthatóság (VBA) ismertetése | Microsoft Learn

• Nyilvános nyilatkozat (VBA) | Microsoft Learn

• Private statement (VBA) | Microsoft Learn

• Static statement (VBA) | Microsoft Learn

• Változók élettartamának megismerése (VBA) | Microsoft Learn

Néha szükség van egy változóra, miután az azt létrehozó objektum kikerül a hatókörből. Lásd fent a Hatókör és láthatóság szakaszt . Ennek három elsődleges módja van: nyilvános változók, ideiglenes változók és az értékek tárolása egy helyi táblában. Sok fejlesztő használja ezeket vegyesen. Mindegyiknek megvannak az előnyei és hátrányai.  További információ ezekről itt: 

VBA-modul nyilvános változója: 

• Változók deklarálása (VBA) | Microsoft Learn

Ideiglenes változók: 

• TempVars objektum (Access) | Microsoft Learn

• Power Tip: A tempVars használatának maximalizálása az Access 2007-ben és 2010-ben | Microsoft 365 Blog

Az értékek tárolása a helyi táblázatban

• Az aktuális munkamenethez nyilvános változók és tempVarok tartoznak, és az alkalmazás bezárásakor kikerülnek a hatókörből. De mi a teendő, ha meg szeretné tartani a felhasználóspecifikus változókat a munkamenetek között? Ezeket az értéktípusokat egy helyi táblában tárolhatja. A Northwind 2.0-ban egy ilyen változót egy SystemSettings nevű táblába ment a rendszer. A tábla értéke ShowWelcome. Ez az érték jelzi az Accessnek, ha minden bejelentkezéskor látni szeretné az üdvözlőképernyőt.

A fejlesztőknek gyakran kell paramétereket átadniuk egyik űrlapról a másikra, vagy egy űrlapról egy jelentésbe. Ezek a paraméterek fontos információkat hordoznak, amelyeket a meghívott függvény használ majd a konfiguráláshoz. A második űrlap vagy jelentés többféleképpen is lekérhet információkat az első űrlapról. Íme néhány ilyen módszer: 

1. A második űrlap "visszanézhet" az első űrlapra, hogy bizonyos értékeket felvegyen, akár látható, akár láthatatlan vezérlőelemben.  Például:
   lngCustomerID = Forms!FirstForm!cboCustomerID 

2. Az első űrlap az értékeket globális változókba vagy tempVarsba mentheti. Például:
   g_lngUserID = Me.cboUserID 
   TempVars.Add "UserID", Me.cboUserID 

A Northwind Developer Editionben és a szakmai életünkben gyakran használt metódus a DoCmd.OpenForm vagy az OpenReport OpenArgs argumentumát használja. Például:

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

Itt két technikát egyesítünk: (1) az OpenArgs használata a VendorID és a VendorType átadásához, és (2) a StringFormat() függvény használata például a sztring létrehozásához: 

CompanyID=5&CompanyTypeID=2 

Ez a sztring a böngészőben használt lekérdezési sztringhez hasonlóan néz ki. Egy vagy több "név/érték pár" karaktert tartalmaz, és az és az karakter elválasztja egymástól: 

name1=value1&name2=value2

Az ilyen sztringek előnye, hogy minden értéknek van neve. Hasonlítsa össze ezt egy egyszerűbb megközelítéssel, ahol az OpenArgs értékét csak az "5,2" értékre kellene állítania.  Ilyen esetben erőfeszítést igényelne annak kiderítésére, hogy az egyes értékek mit jelentenek. Az egyes értékek elnevezése a lekérdezési sztringet "önleíróvá" teszi, ami jó programozási gyakorlat.

A DoCmd.OpenForm fogadási végén általában az Form_Open vagyaz F orm_Load eseményben vagyunk, és az OpenArgs sztringet az összetevőiben szeretnénk elemezni.

A Northwindben ezt a StringToDictionary függvénnyel teheti meg. Lekérdezési sztringszerű függvényt vesz fel, és elemzi annak összetevőiben. Ezek az összetevők ezután egy Scripting.Dictionary objektumban lesznek tárolva. Vegye figyelembe, hogy ehhez az Eszközök >-referenciákat kell használnia, és be kell állítania a Microsoft Scripting Runtime (scrrun.dll) referenciáját.

A Dictionary objektum funkciói és előnyei a következők:  

• Az elemek sorrendje nem fontos

• Egyszerű függvények a gyűjtemény elemeinek hozzáadásához és eltávolításához

• Függvények a gyűjtemény ismétléséhez, hogy megtudja, mi van benne

• Egy Exists függvény, amely azt teszteli, hogy elérhető-e egy bizonyos elem

A szótárobjektum használata a Northwindben jelenik meg. Például az frmGenericDialogForm_Load eseményét.

Az Access vezérlővarázslóival létrehozott makrók egyáltalán nem tartalmazzák a hibakezelést; A vezérlővarázslókkal létrehozott VBA általános MsgBox Err.Description értékre korlátozható.

A Northwind 2.0-ban bemutatjuk, hogyan teheti ezt jobban VBA-kód használata esetén. Implementáltuk az úgynevezett globális hibakezelőt. Minden eljárásban előforduló hibák meghívnak egy globális szintű függvényt a hiba megjelenítéséhez. A nagy előnye, hogy a hibakezelés konzisztens. Ha az üzenetet módosítani kell (például a hibaszám megjelenítéséhez vagy a hiba fájlba való naplózásához), akkor csak egy helyen kell elvégeznie. 

A clsErrorHandler a hibakezelési kódot megvalósító osztálymodul. Az osztálymodulok egyetlen egységben tartják össze az összes fő és segédfüggvényt, így beágyazva a kódot.

Az AutoExec makró meghívja az Indítás függvényt a modStartup függvényben. A Starter Editionben a függvény létrehozza a clsErrorHandler egy példányát, és globális változóként menti, amely az alkalmazás egészében használható. A Dev kiadásban statikus osztályt használunk – tekintse meg az osztálymodul tetején található megjegyzéseket.

Valójában az eljárásokban a hibakezelési kód annyira konzisztens, hogy kevesebb mint öt perc alatt létrehozhattuk az összeset egy adott VBA-kóddal, amely az egyes eljárásokat a megfelelő hibakezelővel felszerelte. (A sablonban nem szereplő kód). A Northwind 2.0 Starter és a Developer sablonkiadások kezdetben ezzel a hibakezelési megközelítéssel lettek beszerelve. 
'

TOVÁBBFEJLESZTETT HIBAKEZELÉS

A Northwind Developer Edition 2.2-es verziójától kezdődően a hibakezelő az Access-közösség visszajelzéseinek köszönhetően javult. A Starter kiadás változatlan. 

Lényegében a hibakezelő az előző verzióban (2.0 - 2023 áprilisában jelent meg) a következő:

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

A 2.2-es verzió a következőre frissül:

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

Annak megértéséhez, hogy miért történt ez a módosítás, először is nézzük meg, mitől fut a kód:

• Az AutoExec makró meghívja az Indítás eljárást, amely inicializálást hajt végre az első űrlap megnyitása előtt.

• A felhasználó interakcióba lép az alkalmazással, például megnyit egy űrlapot, vagy egy gombra kattint, és olyan eseményeljárásokat aktivál, mint például a Form_Load és a cmdPrintInvoice_Click.
  '

Az eseményvezérelt eljárások mellett az alkalmazások alrutinokkal és függvényekkel is rendelkeznek – főként modulokban –, és ezt a kódot az eseményeljárások hívják meg. Ezeket "standard" eljárásoknak nevezzük.

A Northwind 2.0-s verziójában a szabványos eljárások a saját üzenetekkel kapcsolatos hibáikat kezelik, de valahogy nem értesítenék a hívóesemény-eljárást arról, hogy hiba történt. Ez akkor lehet rossz, ha az eseményeljárás további kóddal rendelkezik, amelynek futnia kell, függetlenül a meghívott eljárás által kezelt korábbi hibától. Természetesen lecserélhetjük az alrutint egy olyan függvényre, amely sikert vagy hibát ad vissza, és ennek megfelelően kódolva az eseményeljárást, de ez nem mindig megoldás.

A Northwind 2.2-es verziójában a szabványos eljárások nem kezelik a hibaüzeneteket, hanem az Err.Raise használatával jelentik vissza őket a hívóesemény-eljárásnak. A hívási esemény eljárása ezután megjeleníti a felmerült hibát, és folytatódik a Exit_Handler. Ez jobb, mert lehetővé teszi, hogy a hívási eljárás szabályosan befejeződjön.

A Northwind 2.2-es verziójának kódjának használatához az eseményeljárásokat egy harmadik argumentumnak kell átadnia a HandleError számára, amely azt jelzi, hogy a hívó egy eseményeljárás. A Northwind Dev Edition erre frissült.

Egy még hatékonyabb hibakezelő modul támogatja a "verem" (tömb) "leküldéses és felbukkanó" eljárásait. Az első elem mindig az eseményeljárás, ezért nincs szükség további argumentumra. Ez a megvalósítás túlmutat a Northwind Dev Edition céljain.

Az MRU vagy a Legutóbb használt a legutóbb használt rendelések és beszerzési rendelések listája. Érdemes lehet gyakran visszatérni ezekhez, hogy a következő állapotba helyezze őket. Az MRU-listák gyakran az Office-termékekben azoknak a legutóbb használt fájloknak a listájaként jelennek meg, amelyeket esetleg újra meg szeretne nyitni.

A Northwind Dev kiadásban az MRU funkció implementálásához (amely nem létezik a Starter kiadásban) először létre kell hoznia a következő elemeket: 

1. Az MRU-információk tárolására alkalmas táblázat.

2. Kód a tábla frissítéséhez rendelés vagy beszerzési rendelés (PO) megnyitásakor.

3. Kód a menüszalag MRU legördülő menüjének frissítéséhez.

4. Kód az elem betöltéséhez, ha egy MRU-elem van kijelölve a menüszalagon.

Vizsgáljuk meg ezeket részletesebben. 

1. Az MRU-információk tárolására alkalmas táblázat.

A táblázat MRU-jának kialakítását érdemes áttekinteni, különösen az indexeit. Vegye figyelembe, hogy van egy duplikált SortIdx index, amely segít a menüszalag legördülő listájában található MRU-elemek gyors rendezésében, valamint egy egyedi indexet, amely kikényszeríti azt az üzleti szabályt, hogy minden felhasználó esetében egy elem csak egyszer fordul elő. Ha például ugyanazt a sorrendet kétszer nyitja meg, az nem hoz létre két rekordot az MRU táblában.

A tábla kihasználja azt a tényt, hogy az adatbázis összes, MRU-val kapcsolatos PK (elsődleges kulcs) mezője Számláló, így a Hosszú egész adattípus használható a PKValue értékhez.

2. Kód a tábla frissítéséhez rendelés vagy P.O. megnyitásakor.

Az NW2-ben úgy döntöttünk, hogy csak akkor adjuk hozzá az MRU-listához, ha új rekordot hoztunk létre, nem pedig akkor, amikor egy meglévőt újra frissítettek. Az AddToMRU hívását minden bizonnyal áthelyezhetjük Form_AfterInsert-ről Form_AfterUpdate-ra, hogy ezt támogatjuk.

Az AddToMRU és a DeleteFromMRU eljárások a modGlobalban vannak implementálva, amely egy standard modul, amelynek nyilvános eljárásai bármilyen formában láthatók.

Az AddToMRU (ahogy a neve is sugallja) hozzáadja az új elemet az MRU-táblához, majd igény szerint visszavágja, és törli a legrégebbi rekordot, ha az meghaladja a maximális méretet (MAX_MRU_COUNT). Az utolsó lépés valószínűleg a legkevésbé ismert az Access-fejlesztők számára: a menüszalag legördülő menüjét frissíteni kell, és ezt az InvalidateControl meghívásával lehet elvégezni. Ez jelzi a menüszalagnak az inicializálási folyamat újrafuttatását. 

3. Kód az MRU legördülő menü frissítéséhez a menüszalagon. 

Indításkor és az InvalidateControl meghívása után a rendszer összetett függvénykészletet hajt végre a menüszalag feltöltéséhez.  Ezeket az eljárásokat a menüszalag XML-fájlja hívja meg az uSysRibbons táblázatban, amely részben az alábbiakat tartalmazza:

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

Ez a négy visszahívási függvény tölti ki a legördülő listát. Vegye figyelembe, hogy ez nagyon sok ugyanaz az ötlet, mint ahogy az itt leírt standard kombinált listák.

Ha megszünteti a Debug.Print sorainak megjegyzését a modRibbonCallbackben , és újraindítja az alkalmazást, az Azonnali ablak az alábbihoz hasonló sorozatot jelenít meg: 

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

Itt láthatjuk, hogy az Access először meghív egy eljárást, amely visszaadja a betöltendő elemek számát a ddMRU_GetItemCount ByRef argumentumában. Ez az az idő, amikor megnyitjuk a lekérdezést az MRU-táblán, és gyorsítótárazzuk, mert hamarosan többször is használni fogjuk. 

A menüszalag ezután ismételten meghív két eljárást a kétoszlopos legördülő lista Azonosító és Címke értékeinek lekéréséhez. 

Végül meghív egy eljárást, amellyel megszüntetheti, hogy melyik elemet kell kijelölni. (Esetünkben ez az első.) 

4. Kód egy elem betöltéséhez, amikor az MRU-elem ki van jelölve a menüszalagon.

A menüszalag bármely más eleméhez hasonlóan a menüszalag XML-fájljának OnAction tulajdonsága is megad egy visszahívási függvényt a művelet végrehajtásához:

onAction="ddMRU_OnAction"

Ez az eljárás a modRibbonCallbackben van implementálva. Újra felhasználja a már megnyitott rekordhalmazt a kijelölt elem rekordjának megkereséséhez, majd a táblanévtől függően megnyitja a megfelelő űrlapot, és átadja a betöltendő PK-értéket.

• Northwind 2.0 Developer Edition: Template-Tutorial

• Northwind 2.0 Developer Edition: Minden témakör