Northwind 2.0 Неща, които трябва да знаете

VBA (Visual Basic for Applications) е езикът за програмиране, използван във всички продукти на Office. Vba за обучение ви позволява да работите с всички продукти на Office (а не само с Access).
Когато търсите "как да", не забравяйте да потърсите конкретни примери за Access и да включите Microsoft Access в търсенето. Често ще работят решения за другите продукти на Office, но няма гаранция. Microsoft Access е продукт за възрастни; това означава, че има много примери там; което е чудесно за вас! 

Това означава също, че по-старите книги в програмирането на Access все още са жизнеспособни, за да ги преглеждате. Много от по-старите книги все още са налични в сайтове за използвани книги на част от първоначалните им разходи. Проверете уеб сайта на Microsoft, за да определите кои версии на Access все още се поддържат и да продължите с тези версии.

Край на ресурсите за поддръжка за Office – Разполагане на Office | Microsoft Learn  

По-долу са дадени някои връзки към документацията на Access в Microsoft.

• Справочни материали за Access Visual Basic for Applications (VBA) | Microsoft Learn

• Речник на VBA | Microsoft Learn

• Концептуални теми на Visual Basic | Microsoft Learn

• Visual Basic for Applications – Уикипедия

• VBA-Docs/API в основния · MicrosoftDocs/VBA-Docs · Github

Файловете на Microsoft Access са файлове на Office. Файловете на Office трябва да са в "Надеждно местоположение" или да имат разрешено "съдържание". Тези елементи се считат за "безопасни", защото сте ги създали или са дошли от надежден източник. Проверката за надеждни местоположения се извършва всеки път, когато отворите файл на Office. Оттук нататък ще наричаме това "надеждно/разрешено". ЗАБЕЛЕЖКА: Ако бъде издадена и отворена нова версия на приложението от ненаверено място, процесът на разрешаване на съдържанието ще се повтори.

Научете повече за надеждните местоположения.: 

• Надеждни местоположения за файлове на Office – Разполагане на Office | Microsoft Learn

• Решете дали да се доверите на база данни (поддръжка от Microsoft)

• Добавяне, премахване или промяна на надеждно местоположение (поддръжка от Microsoft)

Макросите, функциите и подсайтовете са начинът, по който реализирате бизнес логика във вашата база данни на Access. Важно е да разберете обхвата и видимостта преди да започнете.

• Макродействие RunCode | Microsoft Learn

• Въведение в макросите | Поддръжка от Microsoft

• Команда за функция (VBA) | Microsoft Learn

• Sub statement (VBA) | Microsoft Learn

Събития (като щракване върху контрола) в контроли във формуляр (например бутони, текстови полета, етикети и т.н.) задействат други процеси, като например добавяне, изтриване на записи или отваряне на формуляри. Тези процеси могат да бъдат внедрени с помощта на макроси или VBA. Northwind Starter Edition използва предимно макроси, а някои VBA, където макросите не могат да изпълняват необходимите функции. Northwind Developer Edition използва предимно VBA. 

Някои типове контроли имат вградени съветници за автоматично създаване на макрос. Например добавянето на команден бутон към формуляр отваря съветник, който предлага няколко възможности за избор на функционалност за бутона. Добавянето на разгъващ се списък отваря съветник, който може да бъде конфигуриран да намери конкретен запис във формуляра. 

Навигационният екран е основният начин, по който преглеждате и отваряте всички обекти на базата данни, и по подразбиране той се показва от лявата страна на прозореца на Access. 
Навигационният екран на Northwind е персонализиран. Създадохме потребителска категория, наречена Northwind Starter 2.0. Това ни позволява да организираме обектите по функционална област.

• Използване на навигационния екран | Поддръжка от Microsoft

• Персонализиране на навигационния екран | Поддръжка от Microsoft

Важно е да научите за обхвата и видимостта в Access/Office. Можете да започнете оттук: 

• Разбиране на обхвата и видимостта (VBA) | Microsoft Learn

• Публична декларация (VBA) | Microsoft Learn

• Частна декларация (VBA) | Microsoft Learn

• Статична команда (VBA) | Microsoft Learn

• Разбиране на времето на живот на променливите (VBA) | Microsoft Learn

Понякога ви трябва променлива, която да съществува, след като обектът, който го е създал, излезе от обхвата. Вижте Обхват и видимост по-горе. Има три основни начина да направите това: Публични променливи, TempVars и Съхраняване на стойностите в локална таблица. Много разработчици използват комбинация от тези. Всяка от тях има своите предимства и недостатъци.  Повече информация за всеки от тях тук: 

Публична променлива на модул на VBA: 

• Деклариране на променливи (VBA) | Microsoft Learn

TempVars: 

• Обект TempVars (Access) | Microsoft Learn

• Съвет за захранване: Увеличаване на използването на TempVars в Access 2007 и 2010 | Блог на Microsoft 365

Съхраняване на стойностите в локална таблица

• Публичните променливи и TempVars съществуват за текущата сесия и излизат от обхвата, когато приложението се затвори. Но какво да направите, ако искате да запазите конкретните за потребителя променливи за сесиите? Можете да съхранявате тези типове стойности в локална таблица. В Northwind 2.0 една такава променлива се записва в таблица, която се нарича SystemSettings. Стойността в таблицата е ShowWelcome. Тази стойност показва на Access, ако искате да виждате приветстващия екран всеки път, когато влизате или не.

Разработчиците често трябва да предават параметри от един формуляр в друг или от формуляр към отчет. Тези параметри предават важна информация, която след това извиканата функция ще използва, за да се конфигурира. Има няколко начина вторият формуляр или отчет да получи информация от първия формуляр. Ето няколко от тези начини: 

1. Вторият формуляр може да "търси назад" в първия формуляр, за да вземе някои стойности, вероятно във видима или невидима контрола.  Например:
   lngCustomerID = Forms!FirstForm!cboCustomerID 

2. Първият формуляр може да записва стойности в глобални променливи или в TempVars. Например:
   g_lngUserID = Me.cboUserID 
   TempVars.Add "UserID", Me.cboUserID 

Методът, който често се използва в Northwind Developer Edition, както и в професионалния ни живот, използва аргумента OpenArgs на DoCmd.OpenForm или OpenReport. Например:

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

Тук комбинираме две техники: (1) използването на OpenArgs за преминаване в VendorID и VendorType и (2) използването на функцията StringFormat() за създаване например на този низ: 

CompanyID=5&CompanyTypeID=2 

Този низ прилича много на низ за заявка, както се използва в браузър. Тя съдържа една или повече двойки име/стойност, разделени със знака амперсанд: 

name1=value1&name2=value2

Предимството на този низ е, че всяка стойност има име. Сравнете това с по-прост подход, при който OpenArgs трябва да е "5,2".  В такъв случай би било необходимо да се разбере каква е всяка стойност. Наименуването на всяка стойност прави низа на заявката "самоописащ се", което е добра практика за програмиране.

В края на получаването на DoCmd.OpenForm обикновено сме в събитието Form_Open или Form_Load и искаме да анализираме низа OpenArgs в неговите компоненти.

В Northwind можете да направите това с функцията StringToDictionary . Тя взема функция, подобна на низа на заявката, и я анализира в компонентите й. След това тези компоненти се съхраняват в обект Scripting.Dictionary . Имайте предвид, че това изисква да използвате Инструменти > Препратки и да зададете препратка към Microsoft Scripting Runtime (scrrun.dll).

Функциите и предимствата на обекта Dictionary включват следните:  

• Редът на елементите не е важен

• Прости функции за добавяне и премахване на елементи от колекцията

• Функции, които да ви пренасят в колекцията, така че да знаете какво има в нея

• Функция Exists, така че да можете да проверите дали има наличен определен елемент

Използването на обекта речник се появява навсякъде в Northwind. Например събитието Form_Load в frmGenericDialog.

Макросите, създадени със съветници за контроли в Access, рядко включват изобщо обработване на грешки; VBA, създаден със съветници за контроли, може да бъде ограничен до общо MsgBox Err.Description.

В Northwind 2.0 ви показваме как да го направите по-добре, когато използвате код на VBA. Внедрихме така наречения глобален манипулатор на грешки. Грешките, които възникват във всяка процедура, извикват функция на глобално ниво, за да покажат грешката. Голямото предимство тук е, че обработката на грешки е съгласувана. А ако съобщението трябва да се промени (например за да се покаже допълнително номерът на грешката или да се регистрира грешката във файл), то трябва да се направи само на едно място. 

clsErrorHandler е модулът на класа, който реализира кода за обработване на грешки. Модулът на класа запазва всичките си основни и помощни функции заедно в един урок, като по този начин капсулира кода.

Макросът AutoExec извиква функцията Startup в modStartup. В Starter Edition функцията създава екземпляр на clsErrorHandler и я записва като глобална променлива, която е налична за използване в цялото приложение. В изданието Dev се използва статичен клас – вижте коментарите в горната част на модула на класа.

Всъщност кодът за обработване на грешки в процедурите е толкова съгласуван, че успяхме да създадем всичко това за по-малко от пет минути с помощта на конкретен VBA код, който включва всяка процедура с правилния манипулатор на грешки. (Кодът не е включен в шаблона). Както изданията Northwind 2.0 Starter, така и developer template бяха първоначално екипирани с този подход за обработване на грешки. 
'

ПОДОБРЕНО ОБРАБОТВАНЕ НА ГРЕШКИ

Започвайки с версия 2.2 на Northwind Developer Edition, манипулаторът на грешки е подобрен благодарение на обратна връзка от общността на Access. Изданието Starter не е променено. 

По същество манипулаторът на грешки в предишната версия (2.0 – издаден през април 2023 г.) е:

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

Във версия 2.2 тя се надстройва до:

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

За да разберем защо е направена тази промяна, нека първо разберем какво кара кода да се изпълнява:

• Макросът AutoExec извиква процедурата за стартиране, която извършва някои инициализации, преди да отвори първия формуляр.

• Потребителят взаимодейства с приложението, като например отваряне на формуляр или щракване върху бутон, което кара процедурите за обработка на събития да се задействат, като например Form_Load и cmdPrintInvoice_Click.
  '

В допълнение към процедурите за обработка на събития, приложенията имат подпрограма и функции, предимно в модули, и този код се извиква от процедурите за обработка на събития. Те се наричат "стандартни" процедури.

Във версия 2.0 на Northwind стандартните процедури ще обработват своите собствени грешки със съобщения, но те няма някак да уведомят процедурата за извикване на събитие, че е възникнала грешка. Това може да е лошо, ако процедурата за събитие има последващ код, който трябва да се изпълни независимо от предишната грешка, обработена от извиканата процедура. Разбира се, можем да заменим подпрограмата с функция, която връща успех или неуспех, и да кодираме процедурата за събитието съответно, но това не винаги е опция.

В Northwind версия 2.2 стандартните процедури не обработват съобщенията за грешка, а вместо това, използвайки Err.Raise, ги докладват обратно в процедурата за извикване на събитие. Процедурата за извикване на събитие след това показва повдигнатата грешка и се възобновява на Exit_Handler. Това е по-добре, защото позволява процедурата за извикване да приключи елегантно.

За да използвате кода на Northwind версия 2.2, процедурите за събития трябва да преминат в HandleError трети аргумент, указващ, че повикващият е процедура за обработка на събитие. Northwind Dev Edition е актуализирано да прави това.

Още по-мощен модул за манипулатор на грешки ще има поддръжка за процедури за "избутване и изскачане" на "стек" (масив). Първият елемент винаги ще бъде процедурата на събитието, така че допълнителният аргумент не е необходим. Тази реализация е извън целите на изданието Northwind Dev.

Последно използвани поръчки или последно използвани е списък на последно използваните поръчки и поръчки за покупка. Може да искате да се върнете към тези често, за да ги поставите в следващото състояние. Списъците с последно използвани файлове често се виждат в продуктите на Office като списък на последно използваните файлове, които може да поискате да отворите отново.

в изданието Northwind Dev, за внедряване на функцията MRU (която не съществува в изданието Starter), трябва първо да установите следните елементи: 

1. Таблица за съхраняване на информация за последно използвани.

2. Код за актуализиране на таблицата при отваряне на поръчка или поръчка за покупка.

3. Код за актуализиране на падащото меню за последно използвани файлове в лентата.

4. Код за зареждане на елемента, когато е избран MRU елемент от лентата.

Нека разгледаме по-подробно всяко от тези неща. 

1. Таблица за съхраняване на информация за последно използвани.

Проектът на последно използваните таблици си струва да бъде прегледан, особено неговите индекси. Обърнете внимание, че има дублиран Индекс SortIdx , който да помогне за бързото сортиране на последно използваните елементи в падащия списък на лентата, както и уникален индекс за прилагане на бизнес правилото, което за всеки потребител може да възникне само веднъж. Например отварянето на една и съща последователност два пъти не създава два записа в таблицата MRU.

Таблицата се възползва от факта, че всички свързани с MRU PK (първичен ключ) полета в базата данни са с автоматично номериране, така че типът данни Long Integer може да се използва за PKValue.

2. Код за актуализиране на таблицата при отваряне на поръчка или поръчка.

В NW2 избрахме да добавим към списъка с последно използвани файлове само когато е създаден нов запис, а не когато съществуващ е отново актуализиран. Със сигурност можем да преместим повикването на AddToMRU от Form_AfterInsert към Form_AfterUpdate , за да го поддържаме.

Процедурите AddToMRU и DeleteFromMRU се прилагат в modGlobal, който е стандартен модул, чиито публични процедури са видими от произволен формуляр.

AddToMRU (както подсказва името) добавя новия елемент към таблицата за последно използвани и след това по желание го изрязва обратно, като изтрива най-стария запис, ако е нараснал над максималния размер (MAX_MRU_COUNT). Последната стъпка е може би най-малко известна на разработчиците на Access: падащото меню на лентата трябва да се обнови и това се извършва чрез извикване на InvalidateControl. Това е сигнал към лентата, за да изпълните повторно процеса на инициализиране. 

3. Код за актуализиране на падащото меню за последно използвани файлове в лентата. 

По време на стартиране и след като е извикан InvalidateControl , се изпълнява сложен набор от функции, за да се попълни лентата.  Тези процедури се извикват от XML на лентата в таблица uSysRibbons , която казва отчасти:

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

Тези четири функции за обратно повикване попълват падащото меню. Имайте предвид, че това до голяма степен е същата идея, както е описано тук за стандартните разгъващи се списъки.

Ако премахнете коментара от редовете Debug.Print в modRibbonCallback и рестартирате приложението, екранът за незабавни съобщения ще покаже поредица като тази: 

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

Тук можем да видим, че Access първо извиква процедура, която връща броя на елементите, които да зареди в аргумента ByRef на ddMRU_GetItemCount. Това е и моментът, когато отваряме заявката в MRU таблица и я кешираме, защото предстои да се използва няколко пъти. 

След това лентата многократно извиква две процедури, за да получи стойностите за "ИД" и "Етикет" за падащото меню с две колони. 

Накрая, той изисква процедура, за да се дезактивира елементът, който трябва да бъде избран. (В нашия случай това е първият.) 

4. Код за зареждане на елемент, когато последно използваният елемент е избран от лентата.

Както при всеки друг елемент на лентата, свойството OnAction в XML на лентата задава функция за обратно повикване, която да се използва за извършване на действието:

onAction="ddMRU_OnAction"

Тази процедура е реализирана в modRibbonCallback. Той използва повторно вече отворения набор записи, за да намери записа с избрания елемент, след което, в зависимост от изискваното Име на таблица, отваря съответния формуляр, подавайки стойността на PK, за да бъде зареден.

• Издание на Northwind 2.0 за разработчици: Шаблон-урок

• Northwind 2.0 Developer Edition: Всички теми