Northwind 2.0 Tudnivalók

Hatókör
Microsoft 365-höz készült Access Access 2021 Access 2019

Az itt található tartalom a Northwind 2.0 Developer Edition és Starter Edition kiadásra vonatkozhat. 

Az Access VBA-referenciája

A VBA (Visual Basic for Applications) az összes Office-termékben használt programnyelv. A VBA elsajátítása lehetővé teszi, hogy az összes Office-termékkel dolgozzon (nem csak az Access-szel).
Amikor a "hogyan" szóra keres, mindenképpen keressen az Accessre vonatkozó példák között, és vegye fel a Microsoft Accesst is a keresésbe. Gyakran a többi Office-termék megoldása működik - de erre nincs garancia. A Microsoft Access egy felnőtt termék; Ez azt jelenti, hogy sok példa van; ami nagyszerű az Ön számára! 

Ez azt is jelenti, hogy az Access programozásáról szóló régebbi könyveket még mindig életképes lehet megnézni. A régebbi könyvek közül sok még mindig elérhető a használt könyvek oldalain, az eredeti áruk töredékéért. A Microsoft webhelyén tájékozódjon arról, hogy az Access mely verziói támogatottak még.

Az Office támogatásának megszűnése – Az Office telepítése | Microsoft Learn

Az alábbiakban néhány hivatkozást talál a Microsoft Access dokumentációjára.

Megbízható helyek és engedélyezett tartalom

A Microsoft Access-fájlok Office-fájlok. Az Office-fájloknak "megbízható helyen" kell lenniük, vagy engedélyezni kell a tartalmukat. Ezek az elemek "biztonságosnak" minősülnek, mivel Ön hozta létre őket, vagy megbízható forrásból származnak. A megbízható helyek ellenőrzése minden alkalommal megtörténik, amikor megnyit egy Office-fájlt. Erre innentől kezdve Megbízható/Engedélyezve néven fogunk hivatkozni. MEGJEGYZÉS: Ha az alkalmazás új verzióját bocsátják ki, és azt nem megbízható helyről nyitják meg, a tartalom engedélyezésének folyamata megismétlődik.

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

Makrók, függvények és részek

Makrók, függvények és részkarakterek használatával valósíthatja meg az üzleti logikát az Access-adatbázisban. Fontos, hogy megismerje a hatókört és a láthatóságot , mielőtt elkezdené.

Az űrlap vezérlőin elhelyezett események (például egy vezérlőre kattintás) (például gombok, szövegmezők, címkék stb.) más folyamatokat indítanak el, például a rekordok hozzáadását, törlését vagy űrlapok megnyitását. Ezek a folyamatok makrók vagy VBA-kód használatával is megvalósíthatók. A Northwind Starter Edition főleg makrókat használ, valamint néhány VBA-t is, ahol a makrók nem tudják elvégezni a szükséges funkciókat. A Northwind Developer Edition elsősorban VBA-t használ. 

Bizonyos típusú vezérlőelemekhez beépített varázslók tartoznak a makrók automatikus létrehozásához. Ha például parancsgombot vesz fel egy űrlapra, egy varázsló nyílik meg, amelyben számos funkciólehetőség közül választhat a gombhoz. Kombinált lista hozzáadása egy varázslót nyit meg, amely beállítható úgy, hogy megkeressen egy adott rekordot az űrlapon. 

A navigációs ablak az adatbázis-objektumok megjeleníté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 egyéni kategóriát Northwind Starter 2.0 néven. Ez lehetővé teszi számunkra, hogy funkcionális terület szerint rendezzük az objektumokat.

A változók hatóköre és láthatósága a VBA-ban

Fontos megismernie a hatókört és a láthatóságot az Access/Office-on belül. Itt kezdheti:

Persisting Variables

Előfordulhat, hogy egy változónak léteznie kell, miután az azt létrehozó objektum hatókörén kívülre kerül. A hatókör és láthatóság című részt lásd fentebb. Ennek három fő módja van: a nyilvános változók, az ideiglenesváltozók és az értékek helyi táblában történő tárolása. Sok fejlesztő ezek kombinációját használja. Mindegyiknek megvannak az előnyei és hátrányai.  Ezekről itt olvashat bővebben:

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

Ideiglenesváltozók:

Az értékek tárolása helyi táblában

  • A nyilvános változók és a TempVars változók az aktuális munkamenetben léteznek, és az alkalmazás bezárásakor a hatókörén kívül esnek. De mi a teendő, ha felhasználóspecifikus változókat szeretne megtartani a munkamenetek között? Az ilyen típusú értékeket helyi táblában tárolhatja. A Northwind 2.0-ban az egyik ilyen változó a SystemSettings nevű táblába van mentve. A táblázatban szereplő érték a következő: ShowWelcome. Ez az érték mondja meg az Accessnek, hogy látni szeretné-e az üdvözlőképernyőt minden bejelentkezéskor.

OpenArgs és StringFormat()

A fejlesztőknek gyakran kell paramétereket továbbítaniuk egyik űrlapról a másikra, vagy egy űrlapról egy jelentésre. Ezek a paraméterek fontos információkat közvetítenek, amelyeket a hívott függvény a konfiguráláshoz használ. A második űrlap vagy jelentés többféleképpen is kinyerheti az adatokat az első űrlapról. Íme néhány ilyen módszer:

  1. A második űrlap képes "visszanézni" az első űrlapra, hogy kigyűjtsön néhány értéket, akár látható, akár láthatatlan vezérlőelemből.  Például:
    lngCustomerID = Forms!FirstForm!cboCustomerID 
  2. Az első űrlap globális változókba vagy ideiglenesVáltozókba menthet értékeket. Például:
    g_lngUserID = Me.cboUserID 
    TempVars.Add "UserID", Me.cboUserID

A Northwind Developer Editionben és a szakmai életünkben gyakran használt módszer a DoCmd.OpenForm vagy OpenReport OpenArgs argumentumának használata. Például:

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

Itt két technikát ötvözünk: (1) az OpenArgs használata a VendorID és a VendorType paraméterek átadására, és (2) a StringFormat() függvény használata például a következő karakterlánc létrehozásához:

CompanyID=5&CompanyTypeID=2 

Ez a karakterlánc nagyon hasonlít a böngészőben használt lekérdezési karakterláncra. Egy vagy több, és karakterrel elválasztott név-érték párt tartalmaz:

name1=value1&name2=value2

Az ilyen karakterláncok előnye, hogy minden értéknek van egy neve. Hasonlítsa ezt össze egy egyszerűbb megközelítéssel, ahol az OpenArgs értékét csak "5,2"-re kell állítani.  Ilyen esetben erőfeszítést igényel az egyes értékek jelentésének meghatározása. Az egyes értékek elnevezése "önleíróvá" teszi a lekérdezési karakterláncot, ami jól ismert programozási gyakorlat.

A DoCmd.OpenForm fogadó végén általában a Form_Open vagy Form_Load eseményben vagyunk, és az OpenArgs karakterláncot az összetevőire szeretnénk elemezni.

A Northwind függvényben ezt a StringToDictionary függvénnyel teheti meg. Vesz egy lekérdezési sztring-szerű függvényt, és elemzi az összetevőibe. Ezeket az összetevőket ezután egy Scripting.Dictionary objektum tárolja. Ne feledje, hogy ehhez eszközhivatkozásokat > kell használnia, valamint a Microsoft parancsfájlok futtatókörnyezetének (scrrun.dll) hivatkozását kell beállítania.

A Dictionary objektum szolgáltatásai és előnyei a következők:

  • Az elemek sorrendje nem lényeges
  • Egyszerű függvények a gyűjtemény elemeinek hozzáadásához és eltávolításához
  • A gyűjteményen átívelő függvényekkel megtudhatja, hogy mi van benne
  • Létező függvény, amellyel tesztelheti, hogy egy bizonyos elem elérhető-e

A szótárobjektum használata a teljes Northwindben megjelenik. Például az frmGenericDialogForm_Load eseménye.

Hibakezelés

Az Access vezérlőelem varázslóival létrehozott makrók ritkán tartalmaznak hibakezelést; A vezérlőelem varázslókkal létrehozott VBA egy általános MsgBox Err.Description elemre korlátozódhat.

A Northwind 2.0-s verziójában megmutatjuk, hogyan használhatja hatékonyabban a VBA-kódot. Bevezettünk egy úgynevezett globális hibakezelőt. Bármely eljárás során előforduló hiba globális szintű függvényt hív meg a hiba megjelenítéséhez. A nagy előnye itt az, hogy a hibakezelés következetes. Ha pedig az üzenetet módosítani kell (például a hibaszám megjelenítéséhez vagy a hiba naplózásához egy fájlba), azt csak egy helyen kell megtennie. 

A clsErrorHandler az az osztálymodul, amely a hibakezelő kódot alkalmazza. Az osztálymodul az összes fő és segítő funkcióját egy egységben tárolja, így magába foglalja a kódot.

Az AutoExec makró meghívja a Startup függvényt a modStartupban. A Starter Editionben a függvény létrehozza a clsErrorHandler egy példányát, és globális változóként menti azt, amely a teljes alkalmazásban használható. A fejlesztői kiadásban statikus osztály használatos – lásd az osztálymodul tetején található megjegyzéseket.

Az eljárások hibakezelő kódja annyira konzisztens, hogy kevesebb, mint öt perc alatt létre tudtuk hozni az összeset egy VBA-kód használatával, amely minden eljáráshoz biztosította a megfelelő hibakezelőt. (A kód nem szerepel a sablonban.) Kezdetben a Northwind 2.0 Starter és a Developer sablonkiadás is fel volt szerelve ezzel a hibakezelési megközelítéssel. 
'

TOVÁBBFEJLESZTETT HIBAKEZELÉS

A Northwind Developer Edition 2.2-es verziójával kezdődően az Access-közösség visszajelzéseinek köszönhetően továbbfejlesztettük a hibakezelőt. 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óban a következőre frissült:

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

A változás okának megértéséhez először is vizsgáljuk meg, mitől fut a kód:

  • Az AutoExec makró meghívja az Indítás eljárást, amely néhány inicializálást végez az első űrlap megnyitása előtt.
  • A felhasználó interakcióba lép az alkalmazással, például megnyit egy űrlapot vagy kattint egy gombra, aminek hatására eseményvezérelt eljárások (például Form_Load és cmdPrintInvoice_Click) indulnak el.
    '

Az eseményeljárások mellett az alkalmazásoknak vannak alrutinjai és funkciói is - többnyire modulokban -, és ezt a kódot az eseményvezérelt eljárásokból 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 üzenetekkel kezelték a saját hibáikat, de nem értesítették a hívó eseményvezérelt eljárást a hibáról. Ez akkor lehet rossz, ha az eseményvezérelt eljáráshoz olyan kód tartozik, amelynek a hívott eljárás által kezelt előző hibától függetlenül futnia kell. Persze, a szubrutint le lehetne cserélni egy olyan függvényre, amely visszaadja a sikert vagy a hibát, és ennek megfelelően kódolhatjuk az eseményvezérelt eljárást, de ez nem mindig lehetséges.

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 őket a hívó eseményvezérelt eljárásnak. A hívó eseményvezérelt eljárás ezután megjeleníti a kiváltott hibát, és a Exit_Handler időpontban folytatódik. Ez jobb, mert lehetővé teszi, hogy a hívási eljárás elegánsan véget érjen.

A Northwind 2.2-es verziójának kódjának használatához az eseményvezérelt eljárásoknak át kell adniuk a HandleError paraméternek, amely egy harmadik argumentum, amely azt jelzi, hogy a hívó egy eseményvezérelt eljárás. A Northwind Dev Edition frissült ehhez.

Egy még erősebb hibakezelő modul támogatná a "leküldési és popping" eljárásokat egy "veregen" (tömbön). Az első elem mindig az eseményvezérelt eljárás lesz, ezért nincs szükség további argumentumra. Ez a megvalósítás túlmutat a Northwind Dev Edition céljain.

Legutóbbi lista:

Az MRU, vagy a legutóbb használt a legutóbb használt megrendelések és beszerzési rendelések listája. Ezekhez érdemes gyakran visszatérni, hogy a következő állapotba helyezhesse őket. A legutóbb használt dokumentumok listája gyakran úgy jelenik meg az Office-termékekben, mint a legutóbb használt fájlok listáját, amelyet érdemes lehet újra megnyitni.

a Northwind Dev Editionben a legutóbb használt dokumentumok (amely a Starter kiadásban nem található) bevezetéséhez először be kell állítania a következő elemeket:

  1. Egy tábla a legutóbb használt dokumentumok adatainak tárolására.
  2. Kód, amely frissíti a táblát egy megrendelés vagy beszerzési rendelés megnyitásakor.
  3. Kód a legutóbb használt dokumentumok listájának legördülő listájának frissítéséhez a menüszalagon.
  4. Kód, amely betölti az elemet, amikor egy legutóbb használt elem van kijelölve a menüszalagról.

Nézzük meg ezeket részletesebben. 

1. A legutóbb használt dokumentumadatok tárolására szolgáló tábla.

Érdemes áttekinteni a legutóbb használt tábla kialakítását, különösen az indexeit. Felhívjuk a figyelmét arra, hogy létezik egy duplikált SortIdx index, amely segít a legutóbb használt dokumentumok elemeinek gyors rendezésében a menüszalag legördülő listájában, valamint egy egyedi index, amely arra kényszeríti az üzleti szabályt, hogy egy elem minden felhasználónál csak egyszer fordulhat elő. Ha például kétszer nyitja meg ugyanazt a rendelést, azzal nem hoz létre két rekordot a legutóbb használt dokumentumok táblájában.

A tábla kihasználja, hogy az adatbázisban minden, a főkulcshoz kapcsolódó PK (PK) mező számláló, így a Hosszú egész adattípus használható a PKValue adattípushoz.

2. Kód, amely frissíti a táblát egy megbízás vagy postaszámla megnyitásakor.

Az NW2-ben úgy döntöttünk, hogy csak akkor bővítjük a legutóbb használt dokumentumok listáját, amikor új rekordot hoztunk létre, nem pedig a meglévők ismételt frissítésekor. Ennek támogatása érdekében minden bizonnyal áthelyezhetnénk az AddToMRU hívást Form_AfterInsert-rólForm_AfterUpdate-re .

Az AddToMRU és a DeleteFromMRU eljárások a modGlobalban valósulnak meg, amely egy szabványos 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 a legutóbb használt listához, majd szükség esetén visszavágja, törölve a legrégebbi rekordot, amennyiben az meghaladta 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: frissíteni kell a menüszalag legördülő menüjét, amelyet az InvalidateControl hívással érhet el. Ez egy üzenet a menüszalagnak, hogy futtassa újra az inicializálási folyamatot. 

3. Kód a legutóbb használt dokumentumok listája legördülő menüjének frissítéséhez.

Indításkor és az InvalidateControl meghívása után a program függvények egy komplex készletét hajtja végre a menüszalag feltöltéséhez.  Ezeket az eljárásokat az uSysRibbons táblázat menüszalagjának XML-fájlja nevezi meg, amely részben a következőt mondja:


<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 fel a legördülő listát. Vegye figyelembe, hogy ez nagyjából megegyezik a normál kombinált listák esetében leírtakkal.

Ha visszavonja a Debug.Print sorok megjegyzéseit a modRibbonCallbackben , és újraindítja az alkalmazást, az Immediate window 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átható, hogy az Access először egy olyan eljárást hív meg, amely a betöltendő elemek számát adja vissza a ddMRU_GetItemCount ByRef argumentumában. Ekkor nyitjuk meg a lekérdezést a legutóbb használt tábla tartalmában, és gyorsítótárazzuk, mivel hamarosan többször is használni fogjuk. 

A menüszalag ezután többször hív meg két eljárást a kétoszlopos legördülő lista azonosítójának és címkeértékének lekéréséhez. 

Végül meghív egy eljárást, amellyel meghatározható, hogy melyik elemet kell kiválasztani. (A mi esetünkben ez az első.)

4. Kód egy elem betöltéséhez, amikor a legutóbb használt dokumentumok eleme ki van választva a menüszalagról.

Mint minden más menüszalagelemnél, a menüszalag XML-fájljainak Műveletre tulajdonsága is megad egy visszahívási függvényt, amelyet a művelet végrehajtásához kell használni:


onAction="ddMRU_OnAction"

Ez az eljárás a modRibbonCallbackben van implementálva. A már megnyitott rekordhalmaz használatával megkeresi a kijelölt elemet tartalmazó rekordot, majd a szükséges Táblanév függvényétől függően megnyitja a megfelelő űrlapot a betöltendő PK értékkel.

További információ