Visual Basic

A korábbi fejlesztőprogramokhoz képest korszakos újítás volt annak a fejlesztési támogatásnak a kialakítása, amelynek a „vizuális” előnevet köszönheti. A Windowsban lényegében az összes program kezelőfelülete szabványos alapelemekből tevődik össze: ablak, nyomógomb, gördítősáv, szövegbeviteli sor, lista stb.; ez az a felszín, amelyet a felhasználó lát, kezel, és a program ezek mögött, a felületi elemek összefüggéseit is megtartva végzi el a feladatát. A Visual nyelvek újítása az volt, hogy a készülő programnak először ezt a felszínét kell megtervezni, legalább nagy vonalakban, és a program lényegi tevékenységét, a háttérben végzendő műveletek, számítások, adatfeldolgozások utasításait ezután kell a kezelőfelület elemeihez kapcsolva megírni. A szemlélet úgyszólván megfordította a program tervezésének irányát, de ez csak az első lépések során kötelező, utána a programrészek fejlesztésének menete szabadon választható.

A Visual Basic olyan programok megépítésére szolgál, amelyeket a felhasználó tevékenysége, választása irányít. Az olyan program, amely egy hosszú adatfeldolgozási munkamenetben önállóan dolgozik, a felhasználó beavatkozását nem igényelve, bármilyen hagyományos programnyelven megírható. Ezek között számos olyan található, amelyekkel elkészítve a program a számításokat gyorsabban végzi el, mint amit a Visual Basic fordítóprogramjától megkapott végső változat elérni tud. Ellenben egy adatbázis-kezelő (pl. nyilvántartó, számlázó, könyvelő, adóelszámoló, készletező stb.) vagy egy irodai alkalmazás, internetes alkalmazás használatakor a felhasználó számos lehetőségből választja ki a végzendő feladatot, számos képernyőelemet aktivizál, különösen az egérrel való kezelés során. Fontos észrevenni azt, hogy az ilyen programoknál többnyire nem számít a program sebessége, mert az általában a felhasználó beavatkozásaira, billentyűzésére, kattintásaira vár.^{[mj 1]} A hagyományos szemléletű, algoritmusközpontú programfejlesztő rendszerekben az ilyen sok választási lehetőség állandó figyelemmel kísérését és a kezelői mozzanatok észlelését nagyon munkaigényes feladat megvalósítani. Lassítja a munkát az is, hogy a Windows alatt működő programoktól a felhasználó a szokásos windowsos, grafikus kezelőelemeket várja, ezeknek a programkódból történő létrehozása pedig a forráskódot terjedelmessé teheti, és szintén munkaigényes. Tovább nehezíti a helyzetet az, amikor az elkészült program módosításakor új elemekkel kell a kezelői felületet bővíteni, vagy meg kell változtatni azok helyét vagy tulajdonságait.

Sokkal hatékonyabb a programok megírása, ha ilyen típusú feladatoknál a kezelőelemekhez rendelt önálló programrészletekkel írhatjuk elő a szorosan azokhoz tartozó műveleteket, és ezekből a programrészletekből áll össze a teljes program. Ezért a Visual fejlesztőprogramok fő célja a felhasználót kiszolgáló felület gyors előállítása és javíthatósága, így a Windows alatti programok látható építőköveire koncentrál, két új fogalom bevezetésével: a vezérlésekkel és az ezeken bekövetkező eseményekkel.^[1]

1. ↑ Az egyszerűbb programok időnkénti megtorpanását, lelassulását sajnos nemigen lehet az alkalmazás felgyorsításával megszüntetni, mert azt általában a túlburjánzott, elnehezült operációs rendszer háttérműveletei okozzák, de a kényszerűségből állandóan működtetett víruspajzs ellenőrző tevékenysége is további lassulást eredményez.

A Visual Basic 1.0 verziója 1991-ben jelent meg. A drag-and-drop elvű felhasználói felület az Alan Cooper és társai által tervezett, Tripod nevű ablaktervező kódgenerátor programból származik. A Microsoft szerződést kötött Cooperrel és társaival a Tripod programozhatóvá fejlesztésére a Windows 3.0 rendszerhez, Ruby néven. (Nincs köze az azonos nevű programnyelvhez.) A Tripod semmilyen programozási nyelvet nem tartalmazott, ezért a Microsoft úgy döntött, hogy a Ruby és a BASIC nyelv ötvözésével hozza létre a Visual Basicet.

A Ruby kezelőfelület-generátor adta az új rendszer „vizuális” részét, és ezt építették egybe az Embedded BASIC fejlesztőeszközzel, amelyet a Microsoft korábban Omega nevű adatbázis-kezelő rendszeréhez akart felhasználni. A Ruby lehetővé tette további vezérléseket (ahogy akkor hívták: „gizmókat”) tartalmazó DLL könyvtárak csatolását is, ami később a VBX elemek rendszerévé fejlődött.^[2]

• 1990-ben elkezdődött a Thunder („vihar”) projekt.
• 1991. május – a Visual Basic 1.0 for Windows megjelent a Comdex/Windows világkereskedelmi kiállításon, Atlantában (USA).^[3]

• 1992. szeptember – kiadták a Visual Basic 1.0 DOS alatt működő változatát. A nyelv nem volt teljesen kompatibilis a windowsos Visual Basic nyelvével, mivel valójában a Microsoft DOS-alapú fordítóinak, a QuickBASIC-nek és a BASIC PDS-nek egy újabb verziója volt. A kezelői felület karakteres megjelenítésben az ANSI-karakterkészlet grafikus elemeivel utánozta a Windows grafikus felületét, persze sok engedményre kényszerülve, mégis hatásos összképet elérve. A felület kezelésének technikája pedig már nem sokban különbözik a későbbi Windows 98, Windows XP kezelésétől sem.^[4]
• 1992. november – Visual Basic 2.0 for Windows. A programfejlesztő környezet könnyebben kezelhetővé vált, és a sebessége is megnőtt. Megemlítendő, hogy az ablakok (formok) példányosítható objektumokká váltak, lefektetve a VB4-ben bemutatott osztálymodulok elvi alapjait.
• 1993 nyara – kiadták a 3.0 verziót, immár külön Standard és Professional változatban (az utóbbi több eszközt és lehetőséget tartalmaz, magasabb árért). A VB3 tartalmazta a Microsoft Jet Database Engine nevű adatbázis-kezelő rendszerkomponenst, amely olvasni és írni tudta a Jet (vagy Access) 1.x szabványú adatbázisokat. Ez már lehetővé tette a komolyabb, „üzemi” nyilvántartó programok megírását, megszabadulva az Access adatbázis-építő program szoros korlátaitól.
• 1995. augusztus – megjelent a 4.0 verzió, az első, amely 16 bites és 32 bites programok előállítására is képes lett. Három változata volt: Standard, Professional és Enterprise. Bemutatkozott a nem vezérléseket képviselő objektumok definiálásának lehetősége. A VB4 változatai közötti inkompatibilitás viszont telepítési és működési hibákat okozott. A korábbi verziók VBX vezérlések beillesztésére voltak képesek, helyettük a VB4 már OLE vezérléseket használt (OCX kiterjesztésű fájlokban). Ezeket később ActiveX vezérléseknek kezdték hívni. A 3.0 verzió alatt írt programok forráskódja még nem nyílt szöveg volt, hanem kódolt, ezért ezek áthozatala a 4.0 verzióba csak a 3.0 verzió felhasználásával volt lehetséges, ez sok utólagos problémát okozott az új rendszerre való átállás után.
• 1997. február – a Microsoft az 5.0 verzióval már csak a 32 bites programok írását támogatta. A programozók, akik előnyben részesítették a – régebbi Windows rendszerben futtatható – 16 bites programokat, a forráskódjaikat átvihették az 5.0 rendszerbe, majd az ott kidolgozott kódot a 4.0 verzió alatt is lefordíthatták. Az 5.0 bevezette az egyéni vezérlések tervezését, mint ahogy a natív kódba való fordítás opcióját is, megnövelve a számításigényes programok sebességét. Letölthető volt az ingyenes Control Creation Edition (vezérlésszerkesztő kiadás), lehetővé téve az ActiveX vezérlések egyedi tervezését. Ez arra is alkalmas volt, hogy a szerkesztés alatt álló programon már lefordítás nélküli tesztfuttatásokat lehetett végezni a szerkesztőkörnyezeten belül.
• 1998 közepe – megjelent a Visual Basic 6.0, amely számos területen fejlődött,^[5] ideértve az internetre épülő alkalmazások készítésének képességét is.
• 2005. március 31. – A fejlesztőrendszer támogatásának fő irányai lezárultak, további frissítések nem készültek. A Visual Basic használóinak közössége ezt felzúdulással fogadta, és petícióval követelték a termék életben tartását.^[6] A Microsoft kitartott korábbi álláspontja mellett. (De lásd:^[7]) Ironikus módon a Microsoft az általa ekkoriban kiadott új kémprogram-védelmét – Microsoft AntiSpyware, a GIANT Company Software termékének része – Visual Basic 6.0-ban írta meg.^[8] Az ezt felváltó Windows Defendert C++ kódban újraírták.^[9]
• 2008. március – a Microsoft hivatalosan, végleg befejezte a VB6 fejlesztői támogatását. Ugyan a fejlesztőrendszer támogatása megszűnt, a futásidejű könyvtár elkészült a Windows Vista, Windows Server 2008 és Windows 7 rendszerekhez is.^[10]

A Visual fejlesztőprogramok elindításakor, igazodva az új szemlélethez, a felhasználói felület megtervezésére való helyzetbe érkezünk. Minden alkalmazás alapja az ablak, angol szóval form (helyenként űrlap néven említik). A kész program egy form-ablak megnyitásával fog indulni, ahogy az a windowsos alkalmazásoknál megszokott. Gyakorlatilag tetszés szerinti új formot vehetünk fel a programunkba, amelyeket a program szükség szerint nyithat meg és zárhat be. Baloldalt látható az az eszköztár, amely az ablakokban elhelyezhető kezelő- és képernyőelemek fajtáit sorolja fel. Ebből az eszköztárból válogatva lehet az ablak tartalmát összeállítani. A képen látható (egyelőre Form1 nevű), szürke alaphátterű programablak nyers összeállításának elkészítése valóban csak néhány mozdulatot igényel. Ezekből az elemekből csoportok is készíthetők, amelyek más csoportokat is tartalmazhatnak.

A készülő program ablakaiban elhelyezhető kezelő- és képernyőelemeket összefoglaló néven vezérléseknek (control) hívják.

Minden vezérlésnek vannak tulajdonságai (property). Jobboldalt lent van egy kis ablak (Properties), amelyben az éppen megjelölt vezérlésnek azok a tulajdonságai vannak felsorolva, amelyeket a tervezési fázisban állíthatunk be. A rendszer a képen látható módon minden vezérlésnek automatikusan ad egy olyan egyedi nevet, amely alapján azokra a programkódban hivatkozni tudunk, és amely a vezérlés típusára is utal (form, commandbutton, scrollbar, checkbox stb.); ezek a nevek megváltoztathatók. Beállítható minden vezérlés betűtípusa, színei, háttérképe, elhelyezkedése, mérete, valamint olyan paraméterek, amelyek a programban mutatott viselkedését szabályozzák, például hogy induláskor az adott elem látható-e, kattintásra reagáljon-e, melyik gyorsbillentyűvel legyen elérhető, milyen legyen az egérmutató alakja és így tovább. Ezek a tulajdonságok nemcsak a tervezéskor, hanem később a futtatott programban is átállíthatóak, tehát minden elem megjelenthető vagy eltüntethető, átméretezhető, áthelyezhető, megadhatók a színei, a rajta levő szöveg tartalma, betűmérete, attól függően, hogy a vezérlés miként használható. Készen megadható olyan jellemző is, mint például az eszközleírás vagy buborék (tooltip) szövege, a Tab billentyűvel való léptetés sorrendje, a listatartalom ábécérendbe való állításának igénye, ezeket a funkciókat elegendő csak beállítani. A listán vannak nem látható jellemzőre vonatkozó tulajdonságok is, mint például az, hogy a vezérlés egy megnyitott adatbázis melyik mezőjének tartalmát tükrözze és tegye közvetlenül szerkeszthetővé.

Számos vezérlésnek vannak olyan tulajdonságai is, amelyek csak futás közben, a programkódból olvashatók és módosíthatók, pl. egy lista vagy combo box aktív sorának száma, a vezérlést tartalmazó szülőobjektum neve, vagy információ arról, hogy a felhasználó éppen hová helyezi át az adott elemet a képernyőn.

Az alaphelyzetben használatba vehető vezérlések típusnevei a következők (a képen balról jobbra és lefelé): (eszközválasztó mutató, nem vezérlés), PictureBox, Label, TextBox, Frame, CommandButton, CheckBox, OptionButton, ComboBox, ListBox, HScrollBar, VScrollBar, Timer, DriveListBox, DirListBox, FileListBox, Shape, Line, Image, Data, OLE. A Form nem vezérlés, hanem a program egy modulja, ezért máshogyan kell új ablakot felvenni, mint ahogy szintén máshol lehet a programablakok menüszerkezetét megtervezni, viszont a formon is keletkeznek a többi vezérléshez hasonló események.

A Windows saját beépített vezérléseinek használata egy különleges előnnyel is jár az egyéb módon előállított képernyőelemekkel szemben: a megjelenésük színben, egyebekben automatikusan igazodik a felhasználó által kiválasztott képernyő-témához. Ha a felhasználó másik témát választ, a program képernyőelemeinek a külleme is megváltozik, anélkül, hogy a programon változtatni kellene. Ennek megvan a maga árnyoldala is azzal, hogy a programozó által megtervezett összkép a téma vagy a betűméret megváltoztatásával esetleg elromlik, ezért a fejlesztőrendszer lehetőséget ad a programozónak saját képi stílus összeállítására, a fent elmondottak szerint.

A Visual programok megengedik számos további vezérléstípus felvételét is, maga a Microsoft is kínál ilyeneket kiegészítő fájlokban (pl. TabStrip, ToolBar, ProgressBar, TreeView, ImageCombo, Animation, MonthView, MaskEdBox, FlexGrid), de más gyártók is ingyenesen vagy megvásárolhatóan elérhetővé tettek egyedi, általuk tervezett vezérléseket. A program tervezésekor az operációs rendszer hatáskörében levő összes kiegészítő vezérlésfájl felsoroltatható, és ki lehet választani azokat, amelyeket a vezérlések készletébe felvenni akarunk, hogy onnan a leendő kezelőfelületekre tegyük példányaikat. A nem beépített, hanem külön, OCX vagy DLL fájlban elhelyezett ActiveX programkomponensek a kész program telepítőcsomagjába is belekerülnek, gondoskodva arról, hogy a felhasználó rendszerében is jelen legyenek.

A programfejlesztők saját egyedi vezérléseket is készíthetnek a Visual rendszerekben, amelyeket azután más programokban rendszeresen felhasználhatnak, esetleg közzétehetnek.

Az objektum a programozásban egy olyan logikai egység, amely az egy-egy adatot tartalmazó változókat egy közös csoportba tudja foglalni, a változókat ekkor tulajdonságoknak (property) hívjuk. Minden objektumhoz definiálható számos különféle célú, jelentésű és adattípusú tulajdonság, majd amikor ezt az egységet mintaként használjuk fel további ugyanilyen objektumok létrehozására, akkor az eredeti objektum osztállyá (class) változik. Ez a megoldás csak a gyakorlati szemléletmódban különbözik a régebbi programfejlesztési módszerekben megszokott összetett változótípusok definiálásától, és az e típusokkal létrehozott absztrakt változók használatától. Különbség viszont, hogy az objektumoknak megadhatjuk a „viselkedését”, pontosabban minden objektum magába foglalhatja a vele kapcsolatos műveletek során végzendő feladatok programkódját. Ennek az egész felállásnak akkor látható a jelentősége, amikor újabb objektumokat hozunk létre egy adott osztályból, és az azonnal felveszi az osztály tulajdonságaiként definiált jellemzőket, valamint átveszi a rá vonatkozó programkódot is.

A Microsoft a Visual rendszerekben támogatni kívánta az objektumorientált programozás metódusának követőit, ezért programozási szempontból objektumként használhatóvá tette az összes vezérlést. Formailag a vezérlés csak egy összetett adattípus, amely új változók definiálásához használható, és minden felvett vezérlés a tulajdonságaival együtt valóban ott található a forráskód szövegének egy elkülönített részében. Ám a vezérlések mindegyikének beépített típusa van, tehát a vezérlések típusai mögött egy-egy osztály áll, és a vezérlésekhez így nemcsak formai jegyek, hanem programkódok is kapcsolódnak. Ennek köszönhetően a vezérlések mindegyike egy-egy objektum, amely a készülő alkalmazás szintje alatt saját, „gyárilag” készült programkód szerint működik, és az alkalmazás számára a vezérléssel végzett felhasználói műveletek esemény (event) alakjában jelennek meg. Ezzel lekerül a programozó válláról annak a megtervezése és előírása, hogy miként reagáljon, sőt, hogy egyáltalán észrevegye egy nyomógomb, amikor a felhasználó kattint rá; hogy hogyan kell szabályozni a begépelt szöveg tördelését és megjelenítését a beviteli sorban; vagy miképp kell megvalósítani egy combo box legördítését és a listában való gyorskeresést. Ezek a képességek automatikusan öröklődnek az őspéldányról az összes példányosított utódra, a forráskódban nem megjelenő módon. Ha a programozó igényli, definiálhat saját adattípusokat, saját osztályokat is, de a leginkább használt osztályokat beépített vezérlés alakjában már készen megkapja. Kijelenthető, hogy enélkül is valóban megírható minden program, de az általános célú, alkalmazásszintű programok Windows-stílusú elkészítését ez a rendszer sokszorosára gyorsítja.

Azokban az alkalmazásokban, amelyek a felhasználó igénye szerint, a kezelőfelület elemei által irányítva működnek, a legfontosabb annak a figyelemmel kísérése, hogy a felhasználó melyik felületelemmel mikor milyen műveletet végez. A programozó megtehetné, hogy egy billentyű lenyomásakor vagy egy kattintáskor a programban végigvizsgálja a felület elemeinek helyét és státuszát, kiderítendő, hogy az adott mozzanat melyikre vonatkozott. A Visual fejlesztőrendszerekben írt programokban ez nem szükséges, mert a Windows saját maga megteszi ugyanezt a háttérben, és a programban már csak az egyik vezérlésen bekövetkezett eseményként ad jelzést arról, hogy a kezelői művelet melyik elemre vonatkozik és milyen természetű. A programozónak elegendő azt megterveznie, hogy melyik vezérlés melyik eseményére a program mit tegyen.

Itt kerül előtérbe az eseményvezérelt működési modell. A hagyományos programozási metódusban a forrásprogram első utasítása akkor hajtódik végre, amikor a program elindul, ezután pedig önállóan, beavatkozás nélkül végrehajtja a teljes leírt utasítássorozatot. Egyes esetekben a program látszólag megáll, várakozik például egy billentyűleütésre, de a program a valóságban a várakozás során is folyamatosan vizsgálja, ugyanazt a néhány utasítást ismételgetve, hogy megtörtént-e már a továbblépés feltételeként megszabott mozzanat. Ezt a várakozást és vizsgálatot is a programozónak kell teljes részletességgel előírnia a forrásprogramban. A klasszikus, algoritmusközpontú program futása egyetlen folytonos vonallal követhető, egyszerre mindig egyetlen ágon zajlik.

A Visual Basicben megírt program sajátos módon azzal kezdi a tevékenységét, hogy a képernyőn megjeleníti a program ablakát a tartalmával együtt, majd nem csinál semmit. Tulajdonképpen egy szövegszerkesztő programnak is főleg ebben merül ki a tevékenysége, hiszen gépi mértékkel nézve hihetetlen időket tölt a gép azzal, hogy várakozik a következő betű leütésére, vagy hogy a felhasználó kiválasszon egy menüpontot. A „semmit sem csinálás” közben valójában folyamatosan elemzi a billentyűzet és az egér irányából érkező jeleket, hogy megfelelő jelzés esetén a működést egy annak megfelelő műveletsorral folytassa. Csakhogy ezt a várakozást már nem a programozónak kell lépésenként leírnia, hanem az a Visual rendszerű programnyelvbe beépített alapszolgáltatás, amely egy rejtett, alsóbb programszinten van megoldva. A program, ha teljes részletességgel, akár a gépi kód szintjén vizsgáljuk meg, lényegében azonos szerkezetű a két esetben, a különbség az, hogy ebből kevesebbet kell a programozónak a forráskódba foglalnia, vagyis kevesebb munkával jut el ugyanahhoz az eredményhez.

A működésének zömét várakozással töltő program tehát nem extrém jelenség, hanem csak a klasszikus célprogramokhoz képest megváltozott működési elv. Ennek a szemléletváltozásnak az oka az volt, hogy régebben a programok egy-egy szorosan meghatározott célra készültek, és nem is egy felhasználó kezelése alatt, hanem felhasználó nélkül, egy külön szobába telepített számítógépen futottak.^{[mj 1]} A program a leírt feladathoz, amely gyakorlatilag mindig valamilyen számítási vagy adatrendezési tevékenységre vezethető vissza, azonnal hozzákezdett, és az volt a cél, hogy a lehető legrövidebb idő alatt fejezze be az elvégzendő munkát. Ma is nagyon sok ilyen program készül. De a személyi számítógépek megszületésével létrejött az igény az interaktív programok iránt is, amelyek a felhasználóval közölnek valamit, megvárják a „válaszát”, attól függően folytatják a munkát, amelynek közlik az eredményét, megvárják a felhasználó következő válaszát és így tovább. A szokásos felhasználói alkalmazások az utóbbi csoportba tartoznak, ezért el lehet térni az „elejétől végéig” alapelvű (olykor tévesen monolitikusnak nevezett), egyszálú (single-threaded) programkonstrukciótól.

1. ↑ A programozó ekkor még nem is volt közvetlen kapcsolatban a számítógéppel, a programot például lyukkártyán tárolva juttatta el az operátorokhoz, akár egy másik épületbe. Az operátor, amikor a program sorra került, betöltötte azt a számítógépbe, futtatta, és a program által papírra nyomtatott eredményt a lyukkártyaköteggel együtt visszaküldte a programozónak. Ha a program valamiért megakadt, akkor az operátor félbeszakította, hogy ne foglalja le a program a számítógép drága munkaidejét. Felhasználóhoz intézett kérdések ekkor még nem léteztek, sőt, tulajdonképpen felhasználó sem.

A felhasználó beavatkozásai a program számára események alakjában jelennek meg. Minden eseményhez önálló programszál tartozhat, minden esemény egy objektumhoz tartozik, minden vezérlés egyben objektum is, és minden vezérlésen bekövetkezhet legalább egyféle esemény. A Timer típusú vezérlésnek egyetlen lehetséges eseménye van, az, amikor a beállított visszaszámlálás véget ér. Egy Form típusú objektumon a következő események következhetnek be: Activate, Click, DblClick, Deactivate, DragDrop, DragOver, GotFocus, Initialize, KeyDown, KeyPress, KeyUp, LinkClose, LinkError, LinkExecute, LinkOpen, Load, LostFocus, MouseDown, MouseMove, MouseUp, Paint, QueryUnload, Resize, Terminate, Unload; ezek között vannak a felhasználó tevékenysége által kiváltott és a program más részei által megindított események is. Az eseményvezérelt programokban tehát nem egy központi folyamatot kell megtervezni, hanem hogy az adott vezérlésen létrejövő lehetséges események közül melyikre reagáljon a program és mi legyen az akkor végzendő műveletsorozat.

A többszálúság lényege az, hogy az eseményekhez tartozó műveletsorok egymással egyidejűleg futhatnak.

Minden esemény egy-egy eljárás (procedure) a programon belül, és bármelyikbe megírható olyan programrész, amely az adott esemény bekövetkezésekor végrehajtandó. (Lásd az illusztrációkat.) A végrehajtás az esemény bekövetkezésekor azonnal megkezdődik, akkor is, ha egy másik esemény nyomán éppen végrehajtás alatt van egy másik programrész.

Ennek következményeként kialakulhat például egy ilyen helyzet: a program éppen fő szálnak tekinthető része egy adatfeldolgozási vagy számítási feladaton dolgozik, eközben kiír valami részeredményt, ami a képernyőn a kiírás helyének frissítését váltja ki. Ez a frissítés beindít egy eseményt, amely hatására lezajlik egy másik képernyőelem módosítása is, miközben a számítás tovább zajlik. Ezalatt a felhasználó lenyom egy billentyűt, amellyel jelzi, hogy a számítás tartson szünetet, ez a mozzanat elindítja a lenyomott billentyű vizsgálatát elvégző programrészt; egy Timer vezérlés pedig mindeközben észleli, hogy a korábban valamilyen célból beállított időtartam lejárt, és elvégzi az ilyenkorra előírt lépéseket egy üzenet megjelenítésre. Mindezt egymással párhuzamos szálakon, egyidejűleg teszi.

Az eseményvezérelt, többszálú programkonstrukció nagyon kényelmessé tudja tenni a program építésekor a tennivalók szétbontását részprogramokra, de azoknak, akik az egyszálú programok írásához szoktak, eleinte nagyon bonyolultnak látszik. Van hátránya is a megoldásnak, amelynek a kiküszöbölését meg kell tanulni: a több programszálról nem lehet tudni, hogy egymáshoz képest mikor és milyen sorrendben érnek véget. Ha a részfeladatokat követő tevékenységet valamiért egymáshoz kell igazítani, arra több megoldás is létezik, de a Visual Basic tartalmaz egy utasítást (DoEvents), amely a programot a háttérből irányító rendszernek előírja, hogy a továbblépés előtt meg kell várni minden megkezdett eseményszál befejeződését.

A párhuzamos szálak futása nem jelenti azt, hogy a processzor egyszerre több dolgot csinál, ez a személyi számítógépek architektúráján nem lehetséges. Valójában a processzor ilyenkor minden tennivalóból elvégez egy szakaszt, majd ugyanezt teszi a következő szállal, a rákövetkezővel is, aztán újrakezdi az első szállal és így tovább. Ez tulajdonképpen megegyezik a nagyszámítógépes rendszereken régóta, ma is alkalmazott időosztásos működési elvvel. Maga a Windows operációs rendszer is így működik, így futhat egyidejűleg több program is. A megoldásnak korlátot szab az erőforrások végessége, vagyis a túl sok megnyitott program, illetve esetünkben a túl sok egyidejűleg működésbe lépett, huzamosabban működő programszál lassíthatja a végrehajtásukat, hiszen a számítógép megosztja közöttük a munkaidejét.

Az eseményvezérelt programműködtetési metódus nincs elvi, logikai ellentétben a klasszikus, egyszálas, strukturált programozási paradigmával. A program valójában úgy működik, hogy a számítógép felváltva, de igen nagy sebességgel végigvizsgálja a beérkező kezelői eseményeket és programozott tennivalókat, és egy hagyományos, szabályos többszörös elágazás (switch) révén felváltva irányítja a működési irányt a több programszálnak mindig valamelyikére. A váltás olyan nagy sebességgel és gyakorisággal történik, köszönhetően a mai számítógépek gyorsaságának, hogy a felhasználó nem vesz észre semmi fennakadást egyik programszálban sem. Amikor a programozó a több esemény önálló szálain végrehajtandó utasításokat megtervezi, akkor valójában a többszörös elágazás különféle szálait tervezi meg, ami maradéktalanul igazodik a hagyományos strukturált programszerkezethez. A különbség annyi, hogy az elágazás olyan alárendelt programrétegben történik meg, amelyet a programozó nem lát, ismernie sem kell, ő csak az elágazások folytatásával találkozik, látszólag önálló programszálak alakjában.

A készülő program leendő kezelőfelületének összeállítása, a vezérlések elhelyezése és beállítása csak az egyik része a program megírásának. A Visual programok nem adnak készen olyan működési paneleket, sablonokat, amelyeknek elegendő csak az összeszerkesztése, és a program alapvetően máris működőképes; ilyen szolgáltatást tudunk igénybe venni például a Clarion alkalmazásépítő fejlesztőrendszerben. Az kifejezetten adatbázis-kezelő alkalmazások gyors összeállítására szolgál, a Basic, C++ stb. viszont általános célra kifejlesztett programnyelvek, amelyekben nincsenek tipikus feladatok. Így tehát ezekben a Visual fejlesztőrendszerekben a programozó egy önmagában még működésképtelen, csak félig felépített programot kap a felület megtervezése után, a program összes teendőjét a megszokott módon, programutasításokkal kell előírnia. Ehhez szükség van a program forráskódjának szerkesztésére, a működés tesztelésére, végül pedig a kész, átadható program előállítására szolgáló eszközökre is.

A Visual Basic fejlesztőrendszer teljes egészében átvette az MS-DOS operációs rendszer alatt futó QuickBASIC utolsó, PDS 7.1 verziójának összes szerkesztő- és tesztelőeszközét, valamint a nyelv összes olyan elemét, amelyek Windows alatt értelmezhetőek. Így tehát továbbra is a fejlesztő rendelkezésére áll az azonnali szintaxisellenőrzés, a lépésenkénti futtatás, a változóérték-ellenőrzés, a lépések közötti szerkesztési lehetőség, a közvetlen parancsablak, a töréspontok definiálása. Ezekkel a szolgáltatásokkal a QuickBASIC is egy kiemelkedően kényelmes és gyorsan használható általános célú fejlesztőrendszer volt.

A kódszerkesztő felület tulajdonképpen teljesen azonos a tervezőfelülettel, csak a formok képe helyett a formok forráskódjainak és a kódmoduloknak (lásd később) az ablakait helyezzük az előtérbe. Így azonnal áttekinthetőek a használt vezérlések és a hozzájuk tartozó kódrészletek. Sőt, ha a vezérlések közül kijelölünk egyet az egyik tervezőablakban, akkor rögtön kérhető, hogy a hozzá tartozó első megírt eseménykód jelenjen meg az egyik kódszerkesztő ablakban. Minden formhoz tartozó kódablakban a form eljárásai és függvényei között lehet lapozni, valamint új eljárásokat, függvényeket felvenni. Az ezekben megírt kód már természetesen az adott programnyelvhez igazodó, tehát Basic, C# stb. nyelvű.

A jobboldalt felül látható kis ablakban (Project) a program moduljai vannak felsorolva, előbb a formok, alattuk a kódmodulok. Éppen az fmMain form kódablaka az aktív, alatta egy külön kódmodul ablaka van, legalul pedig az fmMain form képének tervezőablaka. A forráskódban a nyelvi elemek (kódszó, változó, konstans, komment) egyedi színben jelennek meg, segítve a gyors áttekintést, valamint annak ellenőrzését, hogy a beírt eljárásnév már felvett, létező eljárást nevez-e meg.

A kódszerkesztő egyik szolgáltatása a program hivatkozásainak bizonyos mértékű automatikus ellenőrzése. A Basic nyelvek, ellentétben például a Java és C++ nyelvekkel, nem tesznek különbséget a kis- és nagybetűkkel megadott kódelemek között, ez a gyors kódfejlesztéshez nagyon kényelmes és hasznos vonás. Ugyanakkor viszont megőrzi a kis- és nagybetűknek a programozó által megadott alakját, ezért ha például egy TextBox típusú vezérlésnek nem „txlocator”, hanem „txLocator” nevet adunk, akkor a rendszer ezt mindenhol így fogja feltüntetni. Ám ha az első alakot írjuk be, akkor a rendszer megkeresi egy másik előfordulását, és automatikusan átjavítja a beírt szót arra az alakra, megszabadítva minket az ezzel való törődéstől. Ennek pedig az az eredménye, hogy ha a kódszövegbe véletlenül a „tlocator” nevet írjuk be, akkor mivel ilyen nevű vezérlés – tegyük fel – nem létezik, a nevet nem alakítja át kis- és nagybetűs alakra, ebből azonnal észrevehető a tévedés. Hasonlóan jár el a rendszer az itt kékkel megjelenő kódszavakkal és az események neveivel is, amelyek használatánál szükségtelen vesződség a nagybetűk megfelelő használatára ügyelni, azokat a kódszó beírásakor automatikusan a jobban olvasható, vegyes betűkészletű alakra javítja. Annak, aki a betűkészlet szigorú követéséhez szokott egy másik nyelvben, talán fölöslegesnek tűnik ez a háttértámogatás, de belátható, hogy a gyorsaság és a hibaészlelés biztonsága megnövekedik ezek révén. Megjegyzést érdemel, hogy ha később a változó deklarációjában megváltoztatjuk az írásmódot, akkor a rendszer mindenhol lecseréli a régi változatot az újra.

A beírás után – az utasítássor szerkesztésének befejezését azzal jelezzük, hogy egy másik sorra lépünk – a fejlesztőrendszer egy szintaxisellenőrzést is elvégez, és a hibát azonnal jelzi, ez esetben piros színű sorral, ahogy az alábbi képen látható. Ott a sor végén helyesen a „Then” szónak kellene állnia.

A használni kívánt betűtípus és a színek tetszés szerint állíthatók be, sajnos csak 16 alapszínből lehet válogatni.

A Visual programfejlesztő rendszerek egyik nagyon fontos képessége az, hogy a készülő programot a szerkesztési helyzetből való kilépés nélkül, a programkód lefordítása nélkül (lásd később) is ki tudjuk próbálni. Ez lehetőséget nyújt arra, hogy a programnak csak egy bizonyos részét teszteljük, akár utasításonként megállva, a tesztelés közben ellenőrizhetünk és megváltoztathatunk részleteket a forráskódban, és hiba esetén a rendszer azonnal azt is megmutatja, hogy az melyik utasításnál jelentkezett.

A képen sárga színnel van megjelölve egy sor, a rendszer a program tesztfuttatását annak a sornak az elérésekor felfüggeszti. Tetszés szerinti ilyen töréspont vagy megszakítási pont vehető fel a programba. A felfüggesztés után alkalmunk van változóértékek ellenőrzésére, tesztelési parancsok kiadására, töréspontok kikapcsolására vagy újak felvételére, vagy éppen a forráskód javítására is, majd a futás folytatható.

A zöld sor azt az utasítást mutatja, ahol a program futása éppen tart, egész pontosan amelynek a végrehajtása következik, ha a futást folytatjuk.^{[mj 1]} Ilyen akkor látható, ha a programot egy törésponttal vagy egy billentyűleütéssel (Ctrl-Break) megállítjuk, innen lépésenként is folytatható a futás, minden lépés után lehetőséget adva az előbb felsorolt módosító műveletekre. Fontos szolgáltatás, hogy a folytatás helye bizonyos megkötöttségekkel áthelyezhető, arra az esetre, ha kihagyni vagy újra végrehajtatni akarunk utasításokat.

A megállított állapotban egy változó vagy függvény pillanatnyi értékét egy billentyűkombinációval vagy közvetlen paranccsal lekérdezhetjük, de a fent látható kis ablakba (Watches) folyamatos figyelésre kijelölt változók és kifejezések vehetők fel. Ezek értéke a lépésenként vagy szakaszonkénti futtatás során folyamatosan változhat, ami azonnal látható a listán, de megadható az is, hogy a program automatikusan megálljon akkor, ha valamelyikre egy megadott feltétel teljesül, például ha egy bizonyos értéket vesz fel. A listába nem csak egyetlen eljárás változói vehetők fel, a rendszer jelzi, ha egy változó az érvényességi körén kívülre kerül.

Az alul látható kis ablak (Immediate) a közvetlen parancsok kiadására szolgál, a program felfüggesztett és leállított állapotában is. Itt egysoros, összetett Basic parancsok adhatók ki, egymás alatt, akár ciklusok is, szabadon szerkeszthetően. A parancsokban a felfüggesztett program változóinak más értékeket is adhatunk, és a futtatás azokkal folytatható.

Az alsó ablak másik funkciója egy kiírási felület biztosítása a program részére. A Visual nyelveknek ugyanis, ellentétben a hagyományos fejlesztőprogramokkal, nincs ún. konzol-képernyőfelülete, amelyre a PRINT utasítással írni lehet, hiszen a készülő alkalmazás ablakok alakjában jelenik meg. Az ablakokon belül természetesen nyithatók olyan vezérlések, amelyekben szöveg vagy grafika állítható elő, maga a form is használható egyszerű kiírások felületeként, de ezek tartalma a tesztfuttatás befejezése után elvész, mivel a vezérléseknek a tervező állapotába kerülünk vissza, így a kiírt üzenetek a program befejeződése után nem nézhetők át. De a közvetlen parancsablak a programok számára egy Debug nevű objektumként létezik, amelyre egy PRINT metódussal szöveg írható ki, a BASIC nyelvek PRINT parancsainak megszokott tördelési konvenciói szerint, ezek a kiírások nem vesznek el. A kész, lefordított programba a Debug.Print utasítások nem kerülnek be, ezért a tesztelés után a törlésük nem kötelező. A képen levő programban egy másik eljárásban levő utasítások már kiírtak előírt információkat. Erre a görgethető ablakra összesen 32 kibyte terjedelmű szöveg fér el, ennek túllépésekor mindig az első sorok törlődnek.

A fejlesztést és tesztelést egy nagyon részletes, helyzet- és kontextusérzékeny súgó segíti. Az MSDN98 vagy MSDN Visual Studio 6 nevű önálló csomag pedig a teljes Visual Studio összetett súgóját tartalmazza, külön fejezetekkel az adatbázis-kezelési, ODBC és egyéb kiegészítések elemeiről.

1. ↑ A képen látható helyzet valójában nem jöhet létre, mert a rendszer nem enged elindítani olyan programot, amelyben szintaxishibát észlelt, ami itt pirossal van megjelölve.

A program a forráskódja alakjában készül, például BASIC nyelvű utasításokat tartalmazva. Ebben a formában továbbadva a program csak akkor tudna működni másik gépen, ha oda is telepítve lenne a Visual Basic rendszer megfelelő változata, és a felhasználó abban nyitná meg és indítaná el a programot. Természetesen nem ez a követendő út.

A processzor csakis a gépi kódban leírt utasítássorozatot képes végrehajtani, ezért a BASIC (Pascal, C++, Java stb.) nyelvű változatból elő kell állítani a program gépi kódú hasonmását. Erre a célra van minden Visual fejlesztőrendszerbe építve az adott programnyelvhez illeszkedő fordítóprogram. A Windows (és DOS) operációs rendszerekben a futtatásra kész, gépi kódban leírt program egy EXE (ritka esetben COM) kiterjesztésű fájlban van tárolva, ennek a megnyitása jelenti a program elindítását. Az ilyen állapotú fájlt nevezik futtatható kódnak, ez az állapot minden program végállapota. Az ilyen programnak az elindításához már nincs szükség a Visual fejlesztőrendszer feltelepítésére, mert a futtatható változat a program minden utasítását közvetlenül a processzornak szóló alakban tartalmazza.

Nem szabad elfeledkeznünk arról, hogy a program a futtatható kódban is hivatkozik a további vezérlések felvételének érdekében a fejlesztéskor a projekthez csatolt DLL fájlok és ActiveX komponensek eljárásaira. Emiatt ha a program továbbadásakor csak az EXE fájlt másolnánk le, és a felhasználó gépén nincsenek ott a szükséges kiegészítők, akkor a program nem fog működni. Ezért alapszabály, hogy kész programról egy telepítőcsomagot kell készíteni, a Visual rendszerekhez mellékelték az ehhez szükséges eszközt, és a csomag már tartalmazni fog minden szükséges elemet, azokat a telepítés során a felhasználó operációs rendszerébe fogja építeni.

Hadd hívjuk fel az Olvasó figyelmét arra, hogy az előző fejezetekben sehol sem esett szó a Visual Basic rendszer saját BASIC nyelvéről. A fenti szolgáltatások és képességek függetlenek a nyelvtől, és más Visual fejlesztőrendszerekben is megtalálhatók ezeknek a megfelelői.

Az alábbiakban nem a teljes Visual Basic nyelv ismertetése olvasható, csak a nyelv jellegzetes vonásainak kivonatos bemutatása, elhagyva számos kisebb részletet.

Programnyelvek bemutatásakor elvárás, hogy a fenti üzenet kiíratásához szükséges kód megtekinthető legyen, abban a reményben, hogy az érzékeltet valamit az adott nyelv jellegéből. A Visual Basic esetében a megoldás nem magától értetődő. Annyi biztos, hogy utasításkód csak eljárás belsejében lehet, bármelyik modulban, eseménykódban is. Nincs konzol-képernyő, így vagy az adott formba, vagy egy létrehozott vezérlésbe (Label, TextBox, PictureBox) írhatunk, illetve üzenetként megjelenhet egy ideiglenes Windows-üzenetablakban is. Ezek a cél szempontjából sem teljesen egyenértékű, megjelenésükben pedig lényegesen különböző megoldások, ezért választanunk kell. A létező legegyszerűbb, egy új projekt megkezdése után azonnal megtehető lépés a formba való írás, anélkül, hogy a form nevét tudnunk kellene, a felületére kiírt szövegként:

Private Sub Form_Load()
   Me.Print "Helló, világ!"
End Sub

Az üzenet a program indításakor azonnal megjelenik. Az első és harmadik sort a rendszer már előkészítette, az F7 billentyűvel azonnal ide kerülünk. Az említett fogalmak megértéséhez szükséges magyarázatok az alábbi fejezetekben olvashatók.

A BASIC nyelvek mindegyikében alapszabály, hogy a program egymást követő utasításokból áll. Egy utasítás csak egy sorba írható; a strukturáltsághoz használt alapelemek külön utasításokból szerveződnek. A forráskód egy programsorában több utasítás is állhat, ezeket egymástól kettősponttal kell elválasztani.

Egy utasítás felépítése kétféle lehet. A klasszikus típus mindig

<utasításszó>[ <paraméter>[,<paraméter>...]][mj 1]

szerkezetű. Csak kevés kivétel van, amely ettől eltér (pl. LET, PRINT, LINE). A paraméterek helyén többnyire az utasítás által előírt adattípusú kifejezések állnak. Néhány utasításban az utasításszó után újabb kódszó is áll, ilyen az IF, a FOR vagy a LINE utasításszó. A deklaratív utasítások – amelyek a fordítóprogram számára definiálnak változókat, konstansokat és eljárásokat – szerkezete ettől eltérő.

Az utasítás és a sor végét nem jelezzük mással, mint az új sor kezdésével, néhány más nyelvben láthatóhoz hasonló lezáró karakter (";", "}" stb.) nincs.^{[mj 2]}

A másik szerkezeti séma az objektumorientált programozási szemlélet beillesztésével került be a Visual Basic nyelvi rendszerébe, amivel jelentősen eltávolodott a BASIC nyelv klasszikus stílusától.

<objektum>.metódus[ <paraméter>[,<paraméter>...]]
<változó> = <objektum>.metódus[ (<paraméter>[,<paraméter>...])]

Az első megoldás utasításszerűen, a második függvényszerűen ír elő egy műveletet valamelyik objektumon, illetve – akár ezzel egyidejűleg – ad vissza egy megnevezett értéket.

1. ↑ A BNF jelölésrendszerben a csúcsos zárójelekkel önálló elemeket határolunk, a szögletes zárójel pedig opcionális, elhagyható elemeket határol.
2. ↑ Mivel ilyen nincs, ezért a kitételét sem felejthetjük el, ami a C vagy Pascal nyelvű programoknál gyakori, kényelmetlenséget okozó hiba.

A Visual Basic összes kódszava, változó- és eljárásneve betűkészlet-érzéketlen, vagyis a

Dim kt, AX$
if KT>0 tHen print#3,ax$(4);sgn(VAL(mid$(Testmaker(1,a$),3,len(A$))))
If kt > 0 Then Print #3, AX$(4); Sgn(Val(Mid$(TestMaker(1, a$), 3, Len(a$))))

példa második és harmadik sora minden tekintetben egyenértékű. Ennek köszönhetően fölösleges azzal törődnünk, hogy a kódszavakat és neveket kis- és nagybetűhelyesen írjuk be, a fejlesztőrendszer azokat a sorból való továbblépéskor automatikusan a helyesre állítja be, ez esetben a rendszer a begépelt második sort a harmadikban látható alakra hozta. Hogy mi számít helyesnek egy változónév esetében, azt explicit deklarációjuk során (lásd a példa első sora) vagy legutóbbi beírásuk módjával mi határozzuk meg, de az írásmód a változó semmilyen tulajdonságára nincs hatással.

A későbbi példákban gyakran látható, ahogy egy változóban egy kifejezés értékét elhelyezzük. A BASIC nyelvek legelső változata óta kétféle lehetőségünk van erre, amelyek egyenértékűek:

LET a = 1
a = 1

Vagyis a LET értékadó utasításszó az egyetlen, amely az utasítás elejéről elhagyható. Az interpreterek és fordítóprogramok ilyen esetben úgy reagálnak, hogy ha az utasítás elején beépített kódszó (utasításszó) található, akkor aszerint folytatják az utasítás elemzését és végrehajtását, ha pedig nincs ilyen, akkor értékadó utasításként értelmezik, ha annak szabályosan értelmezhető.

A nyelv kódszavai között található az összes beépített adattípus megnevezése, amelyekkel a változókban tárolható adatok, a függvények által visszaadott értékek típusa deklarálható. A változónevek betűvel kezdődnek, a hosszuk legfeljebb 255 karakter. Az adattípusok fő csoportjának elemei a következők: Integer (%), Long (&), Single (!), Double (#), Currency (@), Decimal, Boolean, Byte, String ($), Date, valamint Variant. A Currency típus 28 jegyű szám tárolását teszi lehetővé, a fix hosszúságú String változó legfeljebb 63 KiB, a dinamikus pedig 2 GiB hosszú karakterláncot tárolhat. A Variant típus a nevéhez illően egy olyan változótípus, amely az értékadáskor kapja meg a típusát is, és ez minden értékadáskor megváltozhat.

A típusnevek mögött látható karakterek a BASIC nyelv egyik sajátosságához tartoznak, ami nagyban hozzájárult ahhoz, hogy a nyelv valóban követhetővé váljon a programozást tanulók részére is.

A nyelvek nagy részében a változók adattípusát az azokat használó eljárások elején explicit módon, vagyis az eljárások, a modul elején tételesen leírva deklarálni kell, a változó ennek hatására jön létre a program lefordításakor. A definiálatlan változóra való hivatkozás az ilyen rendszerben hibát eredményez. A változó típusa a deklarációs utasításon kívül máshol nem lesz a forráskódban látható, ezért arra való emlékeztetőül találták ki a magyar jelölés elnevezésű névadási konvenciót; ez jelzi azt is, hogy a változók típusára való emlékeztető jelzésre igény van.

A BASIC-ben és néhány másik nyelvben implicit változódeklaráció és implicit típusdeklaráció (is) van, vagyis a változó automatikusan jön létre az első használatakor, és a típusa ekkor dől el. Az egyik, régi módszer a típus meghatározására az volt, hogy azt a változó kezdőbetűje döntötte el egy rögzített rendszer szerint; egy másik módszer az, amit a Variant típus testesít meg. A harmadik lehetőség pedig az, hogy a változó nevéhez kell írni a fent felsorolt típusdefiníciós karakterek valamelyikét, ez pedig meghatározza és jelzi a változó adattípusát. Így tehát egy K% nevű változó Integer (egész) típusú, az FH2# változó Double (duplapontosságú lebegőpontos) típusú, a SelectorChr$(8) pedig egy String (karakterlánc) típusú tömb 8-as indexű eleme. Külön meghatározható, hogy ha egy változónévhez nem illesztünk hozzá típusjelet és nem is deklaráljuk a típusát explicit módon sem, akkor alapértelmezés szerint milyen típusúak legyenek. (Ilyen direktíva például a modulok első soraként gyakran látott DEFINT A-Z is.) Alapértelmezés a Variant típus.

A Visual Basic mindegyik felsorolt módszert támogatja, és a programozó dönt, hogy melyik módszert akarja követni. (A modul elejére tett Option Explicit direktíva kötelezővé teszi az explicit deklarációt.) Egy változót modul- vagy programszinten globálissá tenni csak explicit deklarációval lehet, de a gyakorlat azt mutatja, hogy a jelentősebb, hosszabb életű változókkal is célszerű így eljárni, ekkor ugyanis a modul bevezető blokkjában mintegy összefoglalást látunk a fontos változókról. A rövid életű, helyi változókat, átmeneti munkaváltozókat pedig elég lehet implicit módon, azaz a használatba vétellel létrehozni, a típusjel megadásával. A függvények nevében a String típusú értéket visszaadókat a '$' jellel különböztetik meg a jel nélküli, jellemzően numerikus értékű függvényektől. (Pl. MID$(AE$, 10, 2) és ABS(R0).)

A Visual Basicre jellemző, hogy ha egy változó már létrejött, akkor a típusjel a neve mögül el is hagyható, ugyanis azonos névvel különböző típusú változók nem hozhatók létre. A típusjel nem lehet ellentmondó a változó már rögzített típusának.

A Date (dátum) adattípus valójában Double típusú numerikus adat, amelyet a megjelenítése, valamint rajta végezhető néhány művelet tesz sajátossá. A példa három utasítás kiírt eredményeit mutatja:

Debug.Print Cdate(39728.6512)
  2008.10.07. 15:37:44
Debug.Print #2006-6-9# + 100
  2006.09.17. 
Debug.Print #1969-7-19# - Cdate("1961 április 12")
  3020 

Amint látható, dátumokkal számítások is végezhetők, és ezek egymásba is alakíthatók. A dátumot a rendszer napokban számlálva, a szökőnapokra is figyelve tárolja, 1899. december 30. felel meg 0-nak, negatív számérték is használható. 2000. december 31. számértékben 36891. A napon belüli időpontot pedig törtszám fejezi ki az egész naphoz viszonyított arányszámként.

A Visual Basicben minden vezérléstípus adattípus is egyben, tehát a

Dim Esd1 As ListBox

utasítással létrehozott változó ListBox típusú objektum tárolására lesz képes, amelynek minden olyan tulajdonsága is elérhető, amely minden ListBox vezérlésnek van. Létezik általános célú, Object típusú változó, amely a Variant megfelelője objektumokra, elsősorban paraméterátadásokban lehet jó hasznát venni.

Egyéni, összetett változótípusok is tetszés szerint definiálhatók és használhatók, ahogy a példa mutatja:

Type Alkalmazott
   Tb As Long
   Név As String * 20
   Szülnap As Date
   Telefon As Long
End Type
Sub Kitölt()
   Dim dolg As Alkalmazott
    ...
   dolg.Név = "Karsai Ákos"
   dolg.Telefon = 0611871603
   tblAlk("azon") = dolg.Tb
End Sub

A skalár változók (dimenzió nélküli, pl. A, K1, Flags, teszt0$) mellett tömbök is használhatók, legfeljebb 60 dimenziósak, meghatározható alsó és felső határindexszel. Például a

Dim szamlalo&(2, 100, 10)

deklaráció Long típusú numerikus változókból hoz létre háromdimenziós, 3×101×11 elemű tömböt, amelynek az elemei ezután az indexek megadásával érhetők el, például egy

aa = szamlalo&(0, ix, 10) * Sgn(T%)

kifejezés részeként, a látható módon. A tömb indexei alapesetben 0-tól indulnak.

A példán látható a BASIC nyelvek egyik kifogásolt jellegzetessége, az automatikus típuskonverzió. Tegyük fel, hogy az aa változó egész (Integer) típusú, amelybe az utasítással éppen egy Long típusú változó értékét másoljuk. A két numerikus típus egymással nem ütközik, ezért mindaddig, amíg a tömb adott elemének értéke tárolható egy Integer típusú változóban, a szükséges konverzió és az értékadás hiba nélkül lezajlik. Ha a számérték kívül esik az Integer típus [-32768,32767] intervallumán, az értékadás hibát eredményez. A kifogások a régi nyelvek szigorúságát kérik számon, a módszer kedvelői a gyorsaságot tekintik előnyösnek.^{[mj 1]}

A tömbök dinamikusan deklarálhatók, vagyis a dimenziószámuk nem, de a dimenziókban vett elemszámuk utólagosan megváltoztatható, a megmaradt sorok tartalmának elveszítése nélkül.

1. ↑ Természetesen léteznek típuskonvertáló függvények, CInt, CLng, CSng stb., de egyszerű esetben ezekre nincs szükség.

A számértékek kifejezése szokványos. A tizedesjegyek elkülönítésére, az amerikai szabályt követve, a tizedespont való, de a számjegyek között ezres tagolás semmilyen jellel sem megengedett. Ha egy törtszám egész része 0, akkor a tizedespont előtt ez a nulla nem fog megjelenni, de a szám beírásakor a nulla odaírása nem okoz hibát. A negatív előjelként a szövegekben is használt kötőjel (elválasztójel) használandó.

helyes: 18721   0.3321   .3321   2.1   +17   -22
hibás: 18 721   18,721   18'721   0,3321   –22

Az utolsó példában a negatív előjel helyett gondolatjel áll.

A számoknak van normálalakja is (ezt helyenként „tudományos” alaknak hívják):

121E4   35E-4   -0.0552E+3   1E-1   1D-1   7.121344E-27
1210000   0.0035   -55.2   0.1   0.1   0.000000000000000000000000007121344

a példák alsó és felső alakjai egyenértékűek. Az ilyen típusú számábrázolást lebegőpontos ábrázolásnak is nevezik, azért, mert a tizedespont nem azon a helyen áll, ahol valójában kellene, hanem onnan elmozdul, és az elmozdulást az exponens értékével jelöli. Az 'E' betű az 'exponens' rövidítése, a 121E4 jelentése a hagyományos alakban írva 121·10⁴; a programokban csak az első írásmód használható. A rendszer a tudományos alakot egyszerű törtalakra alakítja, ha a szám hossza úgy nem lépi túl a megengedettet. A mantissza értékes jegyeinek száma összesen legfeljebb 7 lehet, és az érték Single típusú konstansként vesz részt a műveletekben. Az így ábrázolható számtartomány határai egész pontosan +/–1.401298E–45 és +/–3.402823E+38, a törtszámot a számok belső, bináris ábrázolási mód magyarázza.

Az egyik példán az E betű helyett D áll, ez is megengedett, ilyenkor a számérték Double (dupla pontosságú) konstans lesz, a mantissza összesen legfeljebb 15 értékes jegyet tartalmazhat, és az ábrázolható tartomány pontos határai +/–4.94065645841247D–324 és +/–1.79769313486232D+308.

A rendszer a megadott konstanst a beírásakor mindig a szabályos normálalakra rendezve tárolja, vagyis:

+453.32000E+31 –> 4.5332E+33

A normálalakban az első számjegy mindig 0-nál nagyobb szám, a tizedespont pedig az első jegy után áll. Ha a szám normálalak helyett közönséges alakban is megjeleníthető, akkor fixpontos^{[mj 1]} alakra formázza:

-0.00545564533E17 –> -545564533000000#         8873.125E-2 –> 88.73125

ügyelve a pontosság, az adattípus jelölésére is.

Numerikus konstans mögé típusjel is tehető, a

a# = 12.3 és a# = 12.3#

utasítás közötti különbség azt garantálja, hogy a 12,3 értéket a Double típusú változóban tárolva a szám pontosan, a sokadik tizedesjegyek helyén is nullákat tároljon, míg az első esetben az alsó tizedesjegyek értéke meghatározatlan. A számítások során a kerekítések eltüntethetik a nagyon kis eltérést, de kerekítésekre nem minden esetben kerül sor. Ha a típusjel szükségtelen, a beírás után a rendszer eltünteti.

A tízes számrendszeren kívül tizenhatos számrendszerben ábrázolt (hexadecimális) konstansok is megadhatók:

&h2e = 46   &h80 = 128

Szövegkonstansok, más néven karakterláncok vagy stringek idézőjelek^{[mj 2]} között adhatók meg. Ezt tudva nézzük meg a két példát:

"abcd0123"   ≠   abcd0123

itt az első példa valóban egy String típusú konstans, a második viszont egy változónév.

A dátumot vagy időt kifejező konstansok megadásának lehetőségei nem írhatók le röviden. A rendszer egyes esetekben „#” karakterek közé foglalva írja ki egy dátumművelet eredményét, máskor a Windows helyi beállításának megfelelő formátumban. Ha egy változóban dátumot akarunk tárolni, akkor a változónak Date vagy Variant típusúnak kell lennie, ekkor használhatók, többek között, az alábbi módszerek:

Dim a As Date
a = #1921-06-11#
a = #21-6-1921#
a = #21-június-1921#
a = CDate("1921 jún 11")
a = "1921 jún 11"

Látható, hogy a rendszer elég rugalmasan keresi egy beírt adatsor dátumként való értelmezésének lehetőségeit, a korlátokat az operációs rendszer is megszabhatja, így azokat nekünk kell felderítenünk.

1. ↑ A fixpontos ábrázolásban a tizedespont mindig a szám valódi egész és tört része között van, függetlenül az egész rész jegyeinek számától. Ha a szám egész, akkor nincs tizedespont.
2. ↑ Ha szövegszerkesztővel írt példát illesztünk egy programunkba, ügyelnünk kell arra, hogy a karakterláncokat közrefogó jelek a szövegben másféle nyomdai idézőjelek is lehetnek, de a Basic csak a közönséges írógép-idézőjelet fogadja el, amelynek az ASCII-kódja 34.

A Visual Basicben használható operátorok (műveleti jelek) között erősorrend, más néven prioritási vagy precedencia-sorrend érvényes. Csökkenő erősorrendben ez a következő:

aritmetikai operátorok: ^ » – » *,/ » \ » Mod » +,-
logikai operátorok: Not » And » Or » Xor » Eqv » Imp

A fenti jelek jelentése: hatványozás, negatív előjel (azonos a kivonás jelével), szorzás és osztás, egész osztás, maradék (modulus), összeadás és kivonás. Lent: nem, és, vagy, kizáró vagy, ekvivalencia, implikáció. A logikai műveletek az aritmetikai műveleteknél alacsonyabb prioritásúak, lásd még a későbbi példasort.

Relációs operátorok (összehasonlító műveleti jelek)

IF c > 10 Then k = 2

Ebben teljesen tipikus utasításban a k=2 értékadás akkor hajtódik végre, amikor a c nagyobb 10-nél. Az IF utasítás szintaxisának leírásaiban rendszerint az látható, hogy az utasításszó után egy „feltétel” áll, de ilyen adattípus nem létezik, az IF után a valóságban egy Boolean típusú értéknek kell állnia. Ez kétféle lehet: True és False. Ez a követelmény a fenti utasításban is teljesül, úgy, hogy a „>” jel egy művelet jele, azaz operátor.

A relációs műveletek jelei a következők:

=   >   <   >=   <=   <>

ezek erősorrendje azonos. Az utolsó operátor a 'nem egyenlő' kapcsolatot jelzi, az előző kettő pedig a 'nagyobb vagy egyenlő' és 'kisebb vagy egyenlő' kapcsolatnak felelnek meg. Mivel ezek műveletek, így eredményük is van, egy Boolean típusú érték: True (igaz) vagy False (hamis).

Nem csak számértékek, hanem karakterláncok között is végezhető összehasonlítás, ekkor azok lexikális sorrendjét vizsgálja a rendszer, tehát a "abc" < "abcd" és "pqrsgat2" < "pqrtac" értéke is True. Az ékezetes betűk okozhatnak problémát, mivel ezek a karakterkód-táblázatokban hátrébb vannak sorolva, emiatt az "aáb" < "abc" művelet értéke False.

Kevert típusú műveletek

Általánosságban a BASIC nyelvekben a numerikus, logikai és relációs műveletek egymással összhangba hozhatók, keverhetők, ami érdekes programozási lehetőségeket hordoz. Ennek egyik feltétele az, hogy a logikai (Boolean) értékek számmá alakíthatók: True = –1, False = 0. Az 'igaz' érték megfelelőjére az a magyarázat, hogy az egész számokat a nyelv kettes komplemens kódban tárolja, ebben pedig a –1 érték kifejezése csak '1'-es bitekből áll, míg a 0 csupa '0' bit alakjában van tárolva. A relációs műveletek eredménye így két ismert szám, bitsorozat.

A másik feltétel az, hogy a fent felsorolt hat logikai művelet eredménye is számmá alakítható. A műveletek nem korlátozódnak a kétféle Boolean típusra, hanem számok között is érvényesek, és a számok bináris alakjának bitjei között hajtódnak végre. Ennek kihasználásához ismerni kell azt, hogy az említett kettes komplemens kódolás a számokat hogyan fejezi ki: a pozitív számok bináris alakja értelemszerű, a negatív számok ábrázolása pedig úgy történik, hogy a szám abszolút értékének minden bitjét ellenkezőjére váltjuk, majd hozzáadunk 1-et. Mindezt az Integer típusban 15+1, a Long típusban 31+1 biten, a legnagyobb helyiértékű bit az előjelet tartalmazza. Példa: 1217 = 00000100 11000001, –79 = 11111111 10110001.^{[mj 1]}

Ezek ismeretében pontosan érthető a következő utasítás:

IF nt And 8 Then

ez a logikai kifejezés egy numerikus művelet, konkrétan az nt változó aktuális értékében a 3-as bit kivételével minden bitet 0-ra maszkol, és az IF utasításban az így kapott számértéket használja Boolean típusú értékként.^{[mj 2]} Ahol a program egy számértéket Boolean érték helyén használ, ott a szabály úgy szól, hogy a 0 érték felel meg a False (hamis) értéknek, minden más szám True (igaz) értékként lesz kezelve. A példában tehát ha a művelet eredménye 8, a Then utáni utasítások végrehajtódnak, ha pedig 0, akkor nem. (Ekkor kerülhet sor az Else ág végrehajtására, ha van olyan.) Ebből következően az

IF nt Then

utasítás értelmes, és a Then utáni utasításokra akkor kerül sor, amikor az nt változó értéke nem nulla. Ez tehát megegyezik az nt <> 0 feltétellel, de annál egy kicsivel gyorsabban hajtódik végre.

A Not operátorral nagyon kell vigyázni, mert a numerikusból Boolean típusra való konverzió szabályai csapdát rejtenek. Ha ugyanis a fenti elágazási feltételt ellentettjére akarjuk változtatni ezen a módon:

IF Not (nt And 8) Then

akkor az nt And 8 művelet eredménye vagy 0, vagy 8. A Not operátorral ezeket negálva vagy –1-et, vagy –9-et kapunk, a kettes komplemens elvű belső számábrázolás miatt. Viszont mind a két eredmény eltér nullától, vagyis a feltétel eredménye Boolean típusba konvertálva minden esetben True lesz, a feltétel utáni programág minden esetben végrehajtódik, a szándékunktól eltérően. Ha egy feltételben nem csak Boolean típusú elemeket használunk, akkor a Not helyett biztonságosabb megszokni az

IF (nt And 8) = 0 Then

kiértékelést, amely helyes eredményt ad.

Alapvető különbség van az értékadásra és a relációs műveletre használt egyenlőségjelek között. Az

a = b = c

utasítás helyes értelmezése az, hogy az a változóba a b = c relációs művelet numerikusan kifejezett értéke kerül (-1 vagy 0), b és c értéke nem változik.

A műveleteket a rendszer az erősorrend szerint haladva értékeli ki, azonos prioritású műveleteket balról jobbra. A kifejezések kiértékelési sorrendje zárójelezéssel tetszés szerint megváltoztatható. Csak kerek zárójelek használhatók, gyakorlatilag bármilyen mélységig egymásba ágyazva. A nyitó és záró zárójeleknek párban kell állniuk, értelemszerűen. Ha valahol bizonytalanok vagyunk a prioritási sorrendben, megerősítésül nyugodtan használhatunk „fölösleges” zárójeleket is, ha azok elhelyezése logikus. Az alábbi kifejezések a melléjük írt értékeket eredményezik:

3 + 4 * 5                                            = 23
(3 + 4) * 5                                          = 35
(3 + 4 *) 5                                          hibás
2 ^ 8 + 2                                            = 258
2 ^ (8 + 2)                                          = 1024
2 ^ 8 + 2 = ((((2) ^ 8)) + 2)                        = True
((((2) ^ 8)) + 2)                                    = 258
(((2) ^ 8)) + 2)                                     hibás
((((2) ^ 8))) + 2)                                   hibás
9 Or 5                                               = 13  (1001 Or 0101 = 1101)
9 Or 5 And 4                                         = 13  (1001 Or (0101 And 0100) = 1001 Or 0100 = 1101)
(9 Or 5) And 4                                       = 4
3 * 5 Xor 4                             = 15 Xor 4   = 11  (1111 Xor 0100 = 1011)
3 * (5 Xor 4)                           = 3 * 1      = 3   (0101 Xor 0100 = 0001)
2 * 7 > 2 + 20                          = 14 > 22    = False
2 * (7 > 2) + 20                     = 2 * –1 + 20   = 18
21 ^ 3 Or 10 > 7 + 2 * 3 Or 27 / 3                   = 9261
   = ((21 ^ 3) Or (10 > (7 + (2 * 3)))) Or (27 / 3)

Karakterlánc-operátorok

String típusú adatok között egyetlen művelet megengedett, a konkatenáció (összefűzés). Ennek jele az & karakter, de a hagyományos + operátor is használható. Például az

"abc123" & "KLMN"

művelet eredménye "abc123KLMN".

1. ↑ Az egyes komplemens kód az összes bit ellenkezőre váltása, de ezzel a 0 és a -0 is külön jelentést kap, ezért ezt ritkán alkalmazzák.
2. ↑ Ilyen műveletet olyankor szokás használni, amikor a programozó egy érték különböző bitjeihez különböző jelentéseket kapcsol.

A készülő program (project) forráskódja Form típusú objektummodulokból és további önálló kódmodulokból áll össze. Minden form modul elején van egy felső szintű, az eljárásokon kívül eső kódterület is, de ezeken csak direktívák, valamint változó- és konstansdeklarációk szerepelhetnek. Az itt deklarált konstansok és változók érvényességi köre (scope) az adott modul minden eljárására terjed ki. Értékadások és egyéb utasítások ide nem írhatók, minden modulban minden utasításkódnak egy eljáráson belülre kell kerülnie.

A form modulokban az eljárások (Sub) a formon levő vezérlésekhez tartozó eseményekhez illeszkednek, az eljárás neve mindig a vezérlés nevéből, az esemény típusnevéből és a paraméterátadásból áll (pl. Form_KeyUp(KeyCode As Integer, Shift As Integer)). Függvény (Function) ezek között nincs. Ezeket az eljárásokat nem csak az események bekövetkezése indíthatja el, szükség szerint más eljárásokból is meghívhatók. Ha a vezérlés nevét megváltoztatjuk, az eljárás eseményből közönséges eljárássá változik, ezért a névváltoztatást kerülni érdemes. Ha az eljárás nevét átjavítjuk a vezérlés új nevére, az visszaminősül esemény-eljárássá.

A modulba tetszés szerint vehetünk fel eseményektől független eljárásokat és függvényeket is, amelyek csak külön meghívásra indulnak.

Minden vezérlés tulajdonságai elérhetők a programkódból. Minden tulajdonság és sok objektum is eleme egy gyűjteménynek (Properties, illetve például Fields, Workspaces, Indexes), ezek elemei nem csak Name tulajdonságuk, hanem indexük (enumerator) megadásával is hivatkozhatóak. A gyűjtemények (collection) használata teszi lehetővé az objektumorientáltsághoz szükséges osztályok kezelését is. Ezek érvényességi területe a modulra korlátozódik.

A formokon kívül tetszés szerint önálló kódmodulok is felvehetők, amelyekhez nem tartozik sem form, sem bármilyen vezérlés, így ezeken események sem jelenhetnek meg. Egy ilyen modul nyitó, felső szintű kódterületén szintén csak deklarációk szerepelhetnek, de a modulba tetszés szerint vehetők fel eljárások és függvények. A megoldás egyik előnye, hogy az ide elhelyezett programrészek a többi modul számára állandóan elérhetők, míg a formokat ehhez a „be kell tölteni” a memóriába, aktivizálni kell őket (Hide vagy Show metódusokkal). Az utóbbi esetben a formban levő esetleg nagy számú vezérlés fölöslegesen köt le erőforrást. A kódmodulok másik előnye, hogy az itt deklarált változók a program összes moduljából láthatóvá, globális hatókörűvé válnak, így a form modulok között információt közvetíthetnek.

A modulokból való építkezés további előnye, hogy a programban zökkenő nélkül használhatók más programokhoz már megírt form- és kódmodulok is, és természetesen a különböző célú eljárásokból és függvényekből felépített saját rutinkönyvtárjaink is. Ehhez elég a kódszerkesztő felület Project ablakának fájába felvennünk a rájuk mutató hivatkozásokat.

Szükség esetén másik modulban létező adat is átvehető, ekkor a modul nevét (itt Névsor) felkiáltójellel zárva a hivatkozásba kell tenni:

Nevek(x).FontSize = Névsor!Lista(bázis + x).FontSize

Az eljárás (Sub) a forráskódon belül egy elkülönülő, zárt programegység, az elejét egy deklaratív utasítás jelöli, megadva az eljárás láthatósági körét és az átvett paraméterek típusát; az eljárás végét egy szabványos direktíva zárja. Például:

Private Sub Eljarasnev(parameter1, parameter2)
 ...
End Sub

A deklarált eljárást a program bármelyik eljárásából meg lehet hívni. (A Visual Basicben minden programsor valamelyik eljárás része.) Az eljárás meghívásának módja:

Call Eljarasnev(parameter1, parameter2)

A függvény (Function) az eljárás speciális fajtája, amikor az eljárás neve a meghívás helyén egy kifejezésben egy változóértéket képvisel, más szóval a függvény „értéket ad vissza”. A függvény programkódjában írható elő, hogy a visszaadott érték mi legyen. Például egy eljárás egyik sorában használjuk fel egy függvény értékét:

Sub Valami()
    k(u0) = hs * Ceil(tm * 100)
End Sub
Function Ceil(ByVal vv#) As Long
   Ceil = -Int(-vv#)
End Function

Itt a Valami eljárásban levő utasítás a k tömb egyik elemébe tesz egy számértéket, amely a hs változó és a Ceil függvény értékének szorzata. A Ceil ez esetben a benne leírt számítást (egy felkerekítést) a tm*100 értékéből végzi el, és a szorzásba ezt a Long (hosszú egész) típusú számértéket helyettesíti. A függvény által visszaadott érték adattípusát, mint látható, a függvény deklarációjában határoztuk meg.

Az eljárásokban és a modul bevezető szakaszában is deklarálhatók változók, alapesetben a Dim utasítással. A más nyelvekből ismert Declare kódszóra csak akkor van szükség, ha nem a program forráskódjában, hanem egy külső programkönyvtárban, például egy DLL-ben levő eljárás meghívási szerkezetét adjuk meg a fordítóprogram számára.

Az eljárás (vagy függvény) meghívásakor közölhető vele néhány olyan adat, paraméter, amelyekre az eljáráson belüli programrésznek szüksége van.

Public Sub SetItem(cb As ComboBox, ByVal cv, ss, Optional cx = 1)
    Dim p as Integer   'ez nem kötelező
    If cv = 0 Then
        p = -1
    Else
        p = cb.ListIndex + cx
        For i = 0 To cb.ListCount - 1
            If cb.ItemData(i) = cv Then p = LogLine(4, ss): Exit For
        Next i
    End If
    cb.ListIndex = p
End Sub

A paraméter lehet változó, kifejezés vagy konstans. Az utóbbit főleg az eljáráson belüli lehetőségek közötti választásra használjuk, de bármire megengedett.

Az eljárás deklarációjában használt változónevek csak az eljáráson belül érvényesek, és egyáltalán nem szükséges azoknak megegyeznie a hívási utasításban paraméterként használt változónevekkel. Tehát az utasítás hívható például így is:

Call SetItem(Árunév, darab, típus)

A példában a négy paraméteres eljárást csak három paraméterrel hívjuk meg. Ez azért megengedett, mert a deklarációban a negyedik paraméter elhagyhatónak van jelölve, az Optional kódszóval. A példában meg van határozva az az érték, amelyet ilyen esetben az eljárás ebben a változóban automatikusan vegyen fel.

A paraméterátadás lehet cím szerinti vagy érték szerinti. Az első azt jelenti, hogy az átadott változónak csak egy hivatkozását kapja az eljárás, ezért ha az itt megkapott változó értékét megváltoztatja, az a változónak az eljáráson kívüli értékét is megváltoztatja. Ha az eljárásban lenne például egy

cv = 1

utasítás, az visszahatva 1-re változtatná a darab változó értékét, amelyet a program más részeiben felhasználhatunk; ez a módszer egyszerre több érték több paraméterben történő visszaadására is jól beválik.

Az érték szerinti paraméterátadás során a paraméterbe csak az adott változó, kifejezés, konstans aktuális ért��kének másolata kerül, amelynek az eljáráson belüli megváltoztatása nincs hatással az eljáráson kívüli változókra. Az érték szerinti paraméterátadás előírható a deklarációban használt ByVal kódszóval vagy a paraméternek a hívási utasításon belüli zárójelbe tételével, de kifejezés és konstans esetében mindig érték szerinti átadás történik. Globális változót ritkán lehet okunk paraméterként átadni, mivel az az eljáráson belül is látható.

Ahogy látható, paraméterként objektum is átadható, cím szerint, így az objektum minden tulajdonsága elérhető, és meg is változtatható, ahogy ez esetben a ListIndex tulajdonsággal történt.

Paraméter használatának előírása nem kötelező az eljárások deklarálásakor. A

Sub EljNev()
End Sub

eljárás hívásakor paraméter nem adható át, hanem Call EljNev() alakban kell meghívnunk. Ha a híváskor paramétert is megadunk, az hibát eredményez.

Megjegyzés: Az eljárások hívásakor valójában nem kötelező, csak ajánlott a Call utasításszó használata, az el is hagyható; ekkor a paramétereket zárójel nélkül kell felsorolni, például SetItem Árunév, darab, típus. E gyakorlat ellen szól, hogy az eljárás így beépített kódszónak látszik, ugyanakkor a leírása a Súgóban nem található meg, ami zavart okozhat ismeretlen program elemzésekor; valamint ezzel eltérünk a BASIC utasításainak fentebb definiált hagyományos, általános szerkezetétől, amely szerint minden utasítás beépített utasításszóval kezdődik.

A metódus (method) a Visual Basic mellett néhány objektumorientált nyelv sajátságos eleme. Formailag a tulajdonságnak (property) vagy egy objektumgyűjtemény (collection) elemének hivatkozására hasonlít, feladatát tekintve a függvényekkel és az utasításszavakkal is rokonságba hozható. Metódus mindig egy objektumra alkalmazható, például:

Set nx = Combo1.ComboItems.Add(1, "Marks", "Raise flags")
RecSet(ar).UpdateRecord
pcBox1.Point(450, y * 15)
Form1.Hide
filled = dirpack.FileExists("*.exp")

A példákon feltételezzük, hogy a Combo1, RecSet(), pcBox1, Form1, dirpack elemek objektumként vannak deklarálva, a ComboItems pedig egy objektumgyűjtemény egy gazdaobjektumon. Az itt használt metódusok: Add, UpdateRecord, Point, Hide, FileExists. Az első példa a metódust utasításszerűen használja, új elemet vesz fel az objektumba, de a művelettel létrehozott új elem indexét adja vissza; az utolsó inkább egy függvényre hasonlít egy Boolean típusú eredménnyel. A metódusok a nyelv beépített kódszavai, és pontosan megszabott, hogy milyen típusú objektumhoz melyek használhatók. Egyes metódusoknak vannak paraméterei, másoknak nincsenek.

Összességében láthatjuk, hogy a metódus fogalma elhagyta a BASIC nyelvek korábbi szemléletét, és más objektumorientált nyelvekben már létező mintát követett, a BASIC nyelvet végleg eltávolítva a kezdőknek szánt nyelv kezdeti szándékaitól. A metódusokkal megvalósított műveletek nem válthatók ki más utasítások sorozatával, ezért az objektumok, vezérlések kezeléséhez ezek ismerete is elhagyhatatlan.

A legrégebben használt BASIC nyelvjárások egyik sokat bírált hiányossága volt, hogy nem támogatták elemi utasításszavakkal a strukturált programozás elve szerinti programszerkezet felépítését. A hiányzó lehetőségek egész pontosan a tetszőleges hosszúságú ágakat tartalmazó elágazás és a szabadon megadható feltétel szerinti ciklus voltak. Ezeket megvalósítani természetesen más eszközökkel is lehet – ahogy azt az assembly nyelvben is teszik –, a leggyakrabban alkalmazott megoldás a GOTO utasítással történő ugrás a program utasításai között. Mivel ez az utasítás használható helytelenül is, és mert a BASIC révén a programozással megismerkedő kezdők használták is helytelenül – a program tesztelését, elemzését, javítását megnehezítő módon –, a BASIC nyelvre máig fennmaradt módon rásütötték a bélyeget: a BASIC nem strukturált programnyelv.^{[mj 1]}

Valójában a BASIC nyelvekben már hosszú ideje ott van,^{[mj 2]} amit mások hiányolnak belőle, és a Visual Basic is teljeskörűen kiszolgálja a strukturált építkezést saját kódszavakkal és szerkezeti elemekkel, a már megismert SUB és FUNCTION típusú eljárásokon kívül.

If a = b Then c = 1 Else c = 2
If a = b Then
    c = 1
Else
    c = 2
End if

A fenti példa először egyetlen utasításban, majd több utasításba széttagolva mutatja be a feltételes elágazást. Az egysoros esetben az ágak hosszának határt szab a programsor lehetséges legnagyobb hossza, még inkább az egyetlen sorba írt utasítások kissé nehéz olvashatósága. A többsoros változat lehetőséget ad a két ágban levő utasítások hosszának elvileg tetszés szerinti növelésére, továbbá egyértelműen jelzi is, hogy az elágazás hol ér véget. Így egy önálló egységgé zárul az IF utasítás, ami a strukturált építkezést szolgálja. A Visual Basic megengedi a következőt is:

If a = b Then
    c = 1
ElseIf k<0 Then
    c = 0
Else
    c = 2
End if

Több ElseIf ág is létrehozható, ezzel a módszerrel több feltétel szerinti ágválasztás lehetséges, ami ismét bonyolíthatja a szerkezetet, de a sokoldalúsága kétségtelen. Meg kell jegyeznünk, hogy az ElseIf utasítás hatása nem azonos az egymást követő Else és If utasításokéval, amelyek több elágazás kaszkádolt egymásba ágyazását tehetik lehetővé.

Többágú feltételvizsgálatra szolgál a következő szerkezet is:

Select Case fd
    Case 1

    Case 2 To 4

    Case Is >6

    Case Else

End Select

Az első sorban levő kifejezés értékét sorban összehasonlítjuk megadott értékekkel (kifejezések is megengedettek), ezzel az If és ElseIf utasításokkal leírható szétválasztás egy egyszerűsített, gyorsabban végrehajtódó változatát használjuk.

Megjegyzést kíván, hogy a forráskódban az alárendelt programsorok behúzása egyáltalán nem kötelező, az csak egy megszokott módja annak, hogy a programozó áttekinthetőbbé tegye az egymásba helyezett logikai egységek viszonyát. Ez a tördelés nem azonos magával a strukturált programozással. A Visual Basic támogatja egész blokkok ki vagy be történő elmozdítását, és a behúzás mérete is beállítható. A program végrehajtódására a programsorok alakisága semmilyen módon nincs hatással, kizárólag azok tartalma számít.

A többszörös elágazásnak egy régi, de ma is működő lehetősége ez is:

On sw Gosub 1100, 1710, llMake, Sector20
On sw Goto 1100, 1710, llMake, Sector20

Az első esetben a felsorolt címkékkel szubrutinokat hívhatunk meg, ahonnan egy-egy Return utasítással visszatérve a program az ez utáni utasítással folytatódik. A második példa visszatérés nélküli, közvetlen ugrást hajt végre a címkékkel jelölt programsorokra, az sw változó számértéke szerint választva címkét a felsorolásból. Az elágazásnak ez a módja sérti az eljárásokból felépített programszerkezetet, így a használatuk csak egy eljáráson belül, mértékkel ajánlható.

Egy programszakasznak egy feltétel teljesüléséig való ismételgetése az első BASIC nyelvekben is létezett.

For n = 101 To 121 Step 2
    c(n) = c(n+1)
Next n

Ez a ciklusok számlált fajtája, amely végrehajtásának a feltétele megadott számú lefutás teljesítése.^{[mj 3]} A lépésköz megadása 1 esetén elhagyható, és értéke negatív is lehet.

Gyűjtemények (collections) vagy objektumtömbök összes elemére elvégzendő utasításokra indítható ilyen ciklus is:

Dim control As Variant
For Each control In fmEdit.Controls
    If control.Visible = False Then n = n + 1: nm$(n) = control.Name
Next control

ekkor nem kell törődnünk az elemek indexeivel és sorrendjével. A ciklusokból való közvetlen kilépésre rendes esetben az Exit For utasítás használható, ez szabályosan, „strukturáltan” a Next utáni utasítás után folytatja a program végrehajtását. A cikluson belül újabb ciklusok is nyithatóak, más ciklusváltozóval.

Tetszőleges feltétel szerinti ciklus szervezése kétféle módon is lehetséges:

Do While h < n0
    n = n + 1: c(n) = c(n + 1)
Loop

Do
    n = n + 1: c(n) = c(n + 1)
Loop While h < n0

Az utóbbi esetben a ciklus mindenképpen végrehajtódik egyszer, a feltétel teljesülésének vizsgálata csak ezután kerül sorra (hátultesztelő ciklus). A While helyére kerülhet Until is, ellentétes logikai jelentéssel. Megengedett a

While ...
    ...
Wend

szerkezetű ciklus is, de ezzel inkább a Microsoft Word makróiban, később a Visual Basic for Applications nyelvi verzióban találkozhatunk.

A Visual Basic, amely még őrzi a korábbi programozási nyelvek tipikus elemeit is, tartalmazza a szubrutin meghívásához használt GOSUB és RETURN utasításpárt is, valamint a strukturált programozás hívei által sokat „ostorozott” GOTO utasítást is.

If fx <= util(y, 1) Then aa = y: Goto Er1
Call Login(nm$, fx, p)
Er1: Ast$(y, p) = p - fx

A példa azt mutatja be, ahogy az ELSE utasításszót nem ismerő nyelvváltozatban az annak megfelelő logikai struktúrát meg kellett valósítani, ugrással, mint egyetlen lehetőséggel.^{[mj 4]} A GOTO és GOSUB utasításokhoz meg kell jelölni az ugrás célját adó programsort, ehhez van szükség a címke használatára. A régi BASIC nyelvekben minden sornak volt címkéje, egy egész szám, a gép eszerint rendezte sorba a program sorait.

A későbbi nyelvi változatokban, a fejlettebb programszerkesztők megjelenésével a sorszám kötelezősége megszűnt, és csak azok elé a sorok elé kell címkét tenni, amelyekre GOTO vagy GOSUB utasításokkal hivatkozni akarunk. A címkéknek vagy számokból kell állniuk, vagy betűvel kezdődniük és betűkkel, számokkal folytatódniuk, az utóbbi esetben a címke kettősponttal végződik. A csak számjegyekből álló címkéknek már nem kell számértékük szerinti sorrendben állniuk, de ezek használata ki is kopott a gyakorlatból.

A Visual Basic nyelvű programok eljárásokra tagolódnak, így a strukturált építkezés magától adódó irány. Mivel a nyelv már több beépített lehetőséget is ad ennek az egyszerű kivitelezésére, az ugró utasítások használatát ma már valóban érdemes kerülni.

1. ↑ A holland Edsger Dijkstra, akire sokan a strukturált programozás elméletének megalapozójaként tekintenek, A Case against the GO TO Statement című cikkében dühödten támadta emiatt a BASIC nyelvet, aminek a hatása évtizedek elteltével is tapasztalható.
2. ↑ A Microsoft 1988-ban megjelent QuickBASIC v4.5 fejlesztőrendszere is, amellyel MS-DOS alatt futtatható programok készíthetők, már teljes mértékben támogatta a strukturált programírást.
3. ↑ A programozás érdekesebb ötletei közé tartozik, amikor a ciklusváltozó (itt n) értékét a ciklusmagban módosítjuk, megváltoztatva a hátralevő lefutások számát, sőt, jelzőértékeket is tehetünk bele a kilépés okaira utalva.
4. ↑ Ez a szerkezet tulajdonképpen igazodik a strukturáltság szabályaihoz, csak az IF-THEN-ELSE helyett ezt a rövid ugrással megoldott variációt kell elfogadnunk szabványos strukturális elemként, aminek a megfelelő használata nem zavarja a program áttekinthetőségét. Ha egy programnyelv nem adja készen a kényelmes szerkezeti elemeket, attól még lehet őket egyszerű sémákkal egyenértékűen helyettesíteni.

Kódszónak vagy kulcsszónak a forrásprogram azon elemeit hívjuk, amelyek a Visual Basic rendszerbe a gyártó által be vannak építve úgy, hogy azok használatakor a Visual Basic saját maga hajtja végre a kódszó által jelentett műveleteket. A kódszóhoz tartozó műveletek kis programjai a forrásprogramot író programozó és a felhasználó elől rejtve vannak, azokat befolyásolni, megváltoztatni nem lehet. Amikor egy programnyelv „nyelvjárásairól” vagy nyelvi verzióiról esik szó, tulajdonképpen a fejlesztőprogramok által elérhetővé tett kódszókészlet elemeiről és az azokhoz tartozó belső műveletekről beszélünk. A különböző gyártók eltérő kódszókészletet állítanak össze a programozók részére.

A forrásprogramban kódszavak csak a nyelv által rögzített szabályok szerint alkalmazhatók. Változónévként, eljárásnévként nem használhatunk olyan neveket, amelyek valamelyik kódszóval megegyeznek. Ennek megállapítása előre csak akkor lehetséges, ha ismerjük a nyelv összes kódszavát, ami a gyakorlatban lehetetlen. A fejlesztőrendszer az eljárások és változók neveit ilyen szempontból a próbafuttatás előtt ellenőrzi, a törzsutasításszavakkal való véletlen egybeeséseket pedig a beíráskor.

A Visual Basic programsorai háromféle típusba sorolhatók:

• utasítások – az utasítás olyan programelem, amely egy programművelet végrehajtását írja elő. A lefordított (gépi) kódban is ott lesznek az ezeknek megfelelő utasítások. Például:

Open "system.ini" For Input As #3
Set tb = tbData(n): n = n - 1: tb.MoveFirst
Dim rlx(10, 12) As Double
a$ = Mid$(ex$,k,4)

Az utolsó példa az Értékadás fejezetben olvashatók szerint számít utasításnak, amelynek az elejéről elhagytuk a Let utasításszót.

• deklaráció – a fordítóprogram részére szóló deklarációs utasítás változók, konstansok, eljárások, objektumok, típusok definiálásáról rendelkezik, ami a program későbbi utasításaira, adatkezelési szabályaira van hatással. Például:

Global Const PI = 3.14159265358979
Private Function ctLap(ob As Object, nx As Integer)
Static hetnap$

• direktíva – a fordítóprogrammal közölt általános utasítás bizonyos szabályok alkalmazására vagy a fordítás során megteendő lépésre. Például: DefInt, DefStr, DefObj, Option Explicit, Option Compare

DefInt I-K, X-Z
DefDbl A-E
Option Explicit
Option Compare Text
End Function

A Visual Basic kódszókészletének elemei az alábbi csoportokba sorolhatók:

• törzsutasításszó – ilyen kódszó az utasítás első elemeként használatos, az utasításban végrehajtandó műveletet azonosítja. Többségük a többi BASIC nyelvben is létezik. Szabálytalan használatukat a rendszer már bevitelkor jelzi. Például: For, Next, If, Else, Open, Do, Erase, Type, Case, Call, Goto, Rem. A programok sorainak zöme vagy értékadás, vagy törzsutasításszóval kezdett utasítás.
• kiegészítő utasításszó – olyan kódszavak, amelyek más utasításszavakhoz társulva használandók az utasításoknak nem az elején. Például: Step, To, As, WithEvents, Is, New, Then. Egyes törzsutasításszavak kiegészítő helyzetben is használatba kerülnek, például ilyen a For, és a strukturálás következményeként kiegészítő utasításszó is kerülhet utasítás elejére, mint például a Then.
• egyéb utasításszó – szintén az utasítások első elemeként fordulnak elő, de a hibás használatukat a rendszer vagy az indítás előtt, vagy csak a sor végrehajtásakor jelzi. Például: Kill, SetAttr, MkDir, SendKeys, Load, SaveSetting.
• deklarációs utasításszó – a deklarációs utasítások nem végrehajtható parancsokat írnak elő, hanem a fordítóprogram részére jelezzük velük változók, konstansok, eljárások, objektumok, típusok definiálását. Például: Declare, Public, Private, Function, Const, Sub, Implements, Static.
• direktíva-utasításszó – csak direktívákban használatos, a fordítóprogram részére adott előírásként. Például: DefInt, DefStr, DefObj, Option Explicit, Option Compare, End Sub.

A Visual Basic 6 összesen 119 utasításszót ismer.

További kódszótípusok:

• függvénynév – olyan, a Visual Basic nyelvbe épített eljárás, amely a megadott paraméterekből vagy a rendszer valamilyen tulajdonságáról egy értéket ad vissza. Például: Replace, IsEmpty, Date, Format, Left, Abs, EOF, Chr. A VB6-ban 127 beépített függvénynév van.
• objektumtípus – objektumok adattípusának neveként deklarációkban és paraméterátadásokban használható kódszó. Például: CheckBox, App, Node, ButtonMenus, Brush, WebClass, Err, MAPISession, Dictionary, rdoQueries, TextStream, CodePanes, Screen, Folder, Form. A VB6 a beépített objektumokra, beleértve a beépített és ActiveX vezérléseket és gyűjteményeket is, mintegy 260 különböző típust tartalmaz.
• metódusnév – objektumokon alkalmazható művelet előírására utasít, vagy valamilyen értéket ad vissza az objektum valamelyik tulajdonságából vagy az elvégzett művelet eredményéről. Például: GetFirstVisible, ReadProperty, Find, NavigateTo, Play, InsertFile, MoveData. Használatuk módja eltér a BASIC nyelvek általános szabályaitól. A VB6 a rendszerrel kapott objektumokra vonatkozóan több mint 300 metódust tartalmaz.
• eseménynév – objektumokon, elsősorban vezérléseken valamilyen mozzanat vagy kezelői művelet nyomán bekövetkezett szabvány állapotváltozás, amelyek önálló programszálként párhuzamosan futó műveletsort indíthatnak. Például: Disconnect, PathChange, Timer, Unload, ItemActivated, DropDown, BeforeClick, LinkClose, Show, Validate, OLEGiveFeedback, GotFocus. Ugyan egy-egy vezérléstípuson csak 5–15 eseményfajta következhet be, az alapértelmezés szerint a VB6-ba beépített vezérlésekre és objektumokra érvényes különféle események száma több mint 270.
• tulajdonságnév – objektumban, mint osztályváltozóban tárolt adatok csoportjának egy eleme, amely vezérlésobjektum esetében annak egy gyakorlatban is értelmezhető jellemzőjét adja meg. A tulajdonság a forrásprogramtól függetlenül („magától”) megváltozhat, ennek kiolvasásával értesülhet a program a vezérlés állapotáról, mint ahogy a tulajdonságok nagy része a programból megváltoztatható, változtatva ezzel a vezérlés látható vagy nem látható jellemzőjén. Az objektumorientáltság célja épp az, hogy az objektumhoz szorosan tartozó adatokat azok tulajdonságaként szemlélhesse. A megszokott változók (tömbök) használata helyett a tulajdonságok kezelése olyankor lehet hasznos, amikor az értékeket együtt, összetartozóan kell kezelni, és az objektumról készült másolat esetében a tulajdonságértékek automatikus továbbadása lenne kényelmes. Maga a tulajdonságok csoportja is objektumként kezelhető. Tulajdonságok például: FillColor, RecipAddress, WordWrap, Top, Parent, ScaleMode, PercentFormat, Caption, LinkTopic, Alignment. A VB6 beépített (intrinsic), valamint a fejlesztőrendszerrel kapott ActiveX objektumaihoz összesen mintegy 1300 tulajdonságszó létezik.
• operátor – más néven műveleti jel, kifejezésekben változók és konstansok közötti művelet jelölésére. A két érték közötti művelet jelölésére használható 15 operátor a következő: +, –, *, /, \, ^, Mod, And, Or, Xor, Eqv, Imp, Is, Like, &; a 2 egyváltozós (unáris) operátor: Not, AddressOf.

Külön említendő a

• konstansnév – a Visual Basic nyelvű programokban, valamint a nyelvről szóló leírásokban a függvények, eljárások, metódusok numerikus paraméterei általában nem számértékükkel megadva láthatóak, hanem helyettük egy-egy leíró név látható. Nagyon sok konstansnak azonos a számértéke, de más-más esetben használatosak, és a nevük arra is utal. Például 1 a számértéke a következő konstansneveknek: vbLongDate, vbAlignTop, vbTwips, vbWrongFormat, vbFSTransparent, vbTileHorizontal, vbCFText, drp3D, VtChDisplayPlot, flexResizeColumns. A konstansok a látszat ellenére nem beépített kódszavak, így tehát ebbe a felsorolásba nem illenek. A konstansok értékét minden programban külön utasításokkal definiálni kell, ezt úgy szokás megoldani, hogy a deklarációs sorokat önálló, más programokban is használt kódmodulként vesszük fel a programprojekt moduljai közé.

A konstansnevek használata nem kötelező, és saját, egyéni nevek is használhatók helyettük.^{[mj 1]} Ezeknek a neveknek az egységes használatát a rendszer nem garantálhatja, a nevek és a számértékek kapcsolatait csak a konvenció rögzíti. Használatuk kockázatokat is hordoz, mivel ha a konstans deklarációja (például: Global Const vbOLEDropManual = 1) elmarad, ugyanakkor ezt a nevet paraméterként valahol használjuk, akkor a rendszer ezt változónévként fogja kezelni, implicit változódeklarációval létrehozva, ám az új változók értéke mindig 0. Ez igen könnyen fordulhat elő, ha máshol látott programrészletet veszünk át, és abban nincsenek benne a deklarációk, számítva a programozó tájékozottságára. Az Option Explicit direktívával a deklarálatlan nevek csendes felvételét megakadályozhatjuk, de ennek más hátrányai lehetnek. Ezt a problémát tulajdonképpen nem a nyelv okozza, hanem a konstansok használatának egy kialakult, a Microsoft dokumentációival ügyetlenül megalapozott módja.

1. ↑ Rossz esetben egy általunk definiált konstansnév megegyezik egy már publikált, ismertté vált névvel, de eltérő értékkel, ezzel félrevezetünk mindenkit, aki a programot megnézi.

A VB6 fejlesztőrendszer beépített hibaellenőrző szolgáltatása számos formai és szerkezeti hibát kiszűr, megkönnyítve a programozó munkáját. A hibákat különféle különböző szerkesztési fázisokban észleli és jelzi.

• utasítás szerkesztése után – az utasítássor befejezését a rendszernek az jelzi, hogy másik sorba lépünk. Ekkor ha a szerkesztett sorban valami alapvető szintaxishiba van, azonnal hibajelzést kapunk. A program tesztfuttatást és a lefordítást nem engedi meg, amíg a programban ilyen hiba van. Azonnal jelzett hibák vannak a következő példasorokban:

For i=1 To
I a=0 Then
Privat Sub Element(ae)
k = Len–("abc")
lbLimits.Caption = Trim$(Str$(sldLen(0).Value) & " -" & Mid$(Str$(Abs(sldLen(1).Value)))

Az olyan hibákat, amelyek elméletileg még lehetnek szándékos, legális utasítások, a rendszer nem jelzi a beírás után. Például:

k = Le("abc")

itt ugyanis a Len helyett írt Le lehet egy még később létrehozandó függvény vagy eljárás neve, ennek a bevitelét a rendszer nem akadályozza.

Megjegyzés: Az ilyen tévedéseket gyorsabban felfedezhetővé tehetjük, ha szokásunkká válik, hogy az általunk definiált eljárások neveiben nagybetűt is használunk, és az utasítások begépelésekor csak kisbetűvel írjuk azokat. Ha a sor befejezésekor az adott név nem változik automatikusan nagybetűsre, akkor a rendszer nem talált sem ilyen eljárást, sem ilyen kódszót, vagyis valószínű az elírás.

• tesztfuttatás indításakor – amikor egy már meglevő programrészt ki szeretnénk próbálni, kihasználhatjuk a beépített interpreter szolgáltatásait, elindítva a program próbafuttatását. Vannak olyan hibák, amelyek már ekkor észrevehetők, mert egy programsor kívánalmait ugyan teljesítik, de a programban alapvető határokat sért. Ezek a hibák zömmel a deklarációs utasításokban és direktívákban fedezhetők fel ebben a munkafázisban. Ilyen hiba például, ha utasítást helyezünk el egy modul felső szintű, nyitó területére; vagy ha egy felső szinten deklarált konstans vagy változó típusa ütközik egy eljárásban a felhasználási típusával; vagy ha globális konstanst vagy változót deklarálunk form modulban.

A tesztfuttatást az F5 billentyű helyett a Ctrl–F5-tel indítva a rendszer az indítás előtt az összes modulra lefuttatja a hibakeresést, végrehajtás előtt észrevehető hibák kiszűrésére. Hasonlóképp jár el a rendszer a futtatható kódba való fordítás megkezdésekor. Ekkor a rendszer már jelzi az előző pontban mutatott hibát a Len() függvény elírásáról, mivel sem beépített kódszóként, sem saját eljárásként, sem tömbnévként nem lesz a Le() elem azonosítható.

• egy eljárásba való belépéskor – az ilyen hibát csak akkor jelzi a rendszer a tesztfuttatás során, amikor a hibát tartalmazó eljárást a meghívásakor ellenőrzi. Ennek során kapunk értesítést arról, ha egy, ebben az eljárásban levő eljáráshívásnak vagy beépített utasításnak, függvénynek nem az előírt számú vagy típusú paramétere van, vagy az eljárás paraméterének típusa nem egyezik a felhasználásakor láthatóval; vagy egy eljárás egyáltalán nem azonosítható. Egy másik jellegzetes probléma, amikor egy tulajdonság vagy metódus olyan változóhoz vagy objektumhoz van kapcsolva, amelyhez az adott művelet nem érvényes, például:

Dim cm As CommandButton
nx = cm.ListIndex

A tesztfuttatás során ilyen esetben a végrehajtás egy hibaüzenettel megáll az eljárás deklarációs kezdősorán. Ha a felvett változóértékektől független hiba azonosítását már a program indításakor szeretnénk megkapni, akkor a programot az előbb leírt módon, az F5 billentyű helyett a Ctrl–F5-tel kell indítani.

Amint látható volt, az előző hibák formailag azonosíthatóak voltak, legkésőbb amikor a program eljárásszerkezete már megvizsgálható lett. Vannak olyan hibák, amelyek csak akkor válnak észlelhetővé, amikor a rendszer megkísérli annak végrehajtását. Ezek logikai hibák, amelyeket csak a programozó tud értelmezni és javítani. Például:

k = c(1) - Abs(Val(ee$))
s$ = Choose(k, "alfa", "béta", "gamma")

A Choose függvény nem értelmezhető k = 0 esetben, így ha a függvény értékének lekérésekor ez a helyzet áll fenn, a végrehajtás hibával megáll. Hogy k értéke 0 lesz, csak a program végrehajtása során derül ki – itt az előző sorban –, előre ezt gépileg, fejlesztőprogrammal levezetni a gyakorlatban teljesen lehetetlen, ez a programozásban járatos ember képességét igényli.

A Visual Basic rendszer a tesztfuttatás során az összes felsorolt hibahelyzetben megnevezi a hiba típusát és megjelöli a helyét. Több hiba esetén az első ilyenről kapjuk az értesítést, ilyen tekintetben a felsorolásban előrébb levő hibatípus kap elsőbbséget. A tesztfuttatás hiba felfedezésekor megáll, ekkor lehetőségünk van a hibák egy részének azonnali javítására, illetve a forráskódban változtatásokra. Ha a javítás szerkezeti változást is okoz, a rendszer erről értesít bennünket, és a futást leállítja. A nem szerkezeti hiba javítása után viszont a futtatás folytatható, a változók értékei és a többi futásidejű adat a hibajavítástól nem vesznek el. Ez a tesztelési metódus egyetlen futtatási folyamatban is számos hiba észlelését és javítását teszi lehetővé, nagyban gyorsítva a tesztelés és a fejlesztés folyamatát.

A tesztfuttatás teljes értékű futtatás, a program működése teljesen megegyezik a lefordított kód végrehajtásakor majdan tapasztalhatóval, azzal a kivétellel, hogy a hiba helyéről itt pontos információt kapunk. A lefordított program futása egy hiba esetén mindig félbeszakad és leáll, és a programozónak ilyenkor csak egy rövid üzenet áll rendelkezésére a hiba jellegéről, de a helyéről nem.^{[mj 1]}

1. ↑ Emiatt a hibakeresés komoly szakértelmet és esetleg sok időt is követel, a programban számos nyomjelző ideiglenes elhelyezését igényli, és nagy szükség van a felhasználótól minél részletesebb információkra az utolsó műveletekről, a szituációról.

Az utasítások végrehajtásakor észlelhető hibák kategóriájában a Visual Basic számos hibatípusra lehetővé teszi azt, hogy a hiba bekövetkeztekor a program a hibaüzenettel történő leállás helyett egy megtervezett műveletsort hajtson végre. Ez a képesség azt eredményezi, hogy bizonyos kezelői hibák esetén nem szükséges a kritikus utasítás előtt a programban minden hibalehetőséget megvizsgálni, hanem elegendő a bármilyen okból bekövetkező hibára való reakciót megtervezni.

A hiba „kezeléséhez” vagy eltereléséhez szükséges technika formailag egy szubrutinhívásra emlékeztet, annyiban, hogy a hiba bekövetkezésekor egy elkülönített programrészre adódik át a vezérlés, ahonnan egy speciális utasítással kell visszatérni, hasonlóan a RETURN utasításhoz. Például:

Sub Számolás()
    ...
   On Error GoTo erhSz
    ...
   k$ = Mid$(anx$, t$, 1)    ' << hiba
   For i = 10 To 20
    ...
   On Error GoTo 0
   Exit Sub                  ' !
' === hibakezelő
erhSz:
   e = Err
   v = MsgBox(Str$(e) & " számú hibát észleltem, folytatom a munkát.", 48)
   Resume Next
End Sub

Megfigyelhető, hogy a hibaelterelés bekapcsolásakor megadjuk annak a programrésznek a címkéjét, ahová a programnak ugrania kell egy hiba esetén. Ezt előre kell megtennünk, és ezt követően az ugrás automatikusan történik meg, csak abban az esetben, ha lekezelhető típusú hiba lép fel (itt a Mid$ függvényben). Bármelyik utasításnál is következik ez be, a hibakezelő részben leírtak végrehajtódnak – a rész hossza és funkciója kötetlen –, majd a Resume utasítás zárja le az utasítássort. Ennek három különböző alakja van, az itt látható Resume Next hatása az, hogy a hibát okozó utasítást követő utasításnál folytatódik a végrehajtás; folytatódhatna még a hibát okozó utasítás megismétlésével vagy egy címkére való visszaugrással. Végül egy másik utasítással kikapcsoltuk a hibafigyelést. Hibakezelő rutinba másként belépni nem szabad, mert a Resume utasítás nem fog hibajelet találni a bejegyzett rendszeradatok között, ezt a „ráfutásos” hibát előztük meg az eljárásból való előírt kilépéssel.

Nem minden hibafajtát lehet lekezelni, a VB6 összesen 119 hibatípus elterelését engedi, ezek hibakódja 3 és 31307 között van. A hibaelterelés kényelmes lehetőségeket biztosít bizonytalan utasítások egyszerű megírására. Például ha törölni akarunk egy fájlt, de az nem létezik, akkor az utasítás hibát okoz. A fájl vizsgálata helyett, főleg egymás után több hasonló helyzet esetén egyszerűbb így elkerülni ezt az érdektelen problémát:

On Error Resume Next
Kill "posta\t*.txs"
 ...
On Error GoTo 0

Az esetleges hibát így gyakorlatilag figyelmen kívül hagyjuk. Ilyet természetesen csak indokolt esetben és körültekintően kell használni.

Nem minden hiba programhiba, mert okozhat hibát a felhasználó vagy a futó program környezete is.^{[mj 1]} Lekezelhetetlen vagy kikapcsolt hibafigyelés alatt bekövetkező hiba esetén a Visual Basic rendszerének futásidejű komponense egy hibaüzenetet jelenít meg a képernyőn, a hiba kódszámával és rövid megnevezésével, ezután a program futása félbeszakad.

1. ↑ Ezzel együtt végső soron minden programhiba egy programozó hibája, az alkalmazói programokat ugyanis, elterjedt szóval, „bolondbiztossá” kell tenni. Jó esetben a program fejlesztője volt figyelmetlen, rossz esetben a fejlesztőprogram, a futásidejű könyvtár vagy az operációs rendszer tervezői, az utóbbi esetben a hibát kijavítani nem lehet, csak megkerülni valahogy.

A VB6 nyelvi kódszavai és lehetőségei közül azok a programozók, akik más BASIC, vagy más objektumorientált nyelveket is ismernek, hiányolni szoktak néhány megszokott eszközt a Visual Basic 6 nyelvből. Hogy a hiányérzet nem alaptalan, azt mutatja az, hogy a Visual Basic .NET verziókban ezek egy része már megtalálható.

• print utasítás – egész pontosan az a lehetőség hiányzik, hogy a program egy egyszerű üzenetet kiírhasson a képernyőre, esetleg csak a felhasználót tájékoztatva a munka előrehaladtáról, vagy eredményeket közöljön a munka végén. A régebbi BASIC nyelveket megvalósító rendszerben a képernyő egy egyszerű, karakteres állapota volt az alapértelmezés szerinti kimeneti eszköz, olyan, amilyen a DOS operációs rendszerek alatt a PC-ken is megszokott volt. Ez az úgynevezett konzolképernyő^{[mj 1]} a Visual Basicből hiányzik, így szövegeket kiírni csak egy form területére vagy valamely szöveges vezérlésébe lehet a .Print metódussal, ami némi kényelmetlenséget okoz az egyszerű, windowsos küllemet nem kívánó programok írása során.
• input utasítás – az előző szakaszban leírtakhoz csatlakozik ez a probléma is, mivel nemcsak alapértelmezett kimeneti eszköz nincs, hanem alapértelmezett beviteli sor sincs. Kevéssé ismert, hogy a VB6 tartalmaz egy InputBox nevű függvényt, amely egy sornyi adat beviteléhez nyit egy párbeszédablakot, lényegében megoldva ezt a problémát.
• data utasítás – amikor a program egy pontján (gyakran az elején) nagyobb mennyiségű változót, esetleg tömböt kell feltölteni kezdőértékekkel, például egy statisztikai vizsgálathoz, ez elvégezhető egyszerű értékadásokkal, így:

Dim ds(3,5)
ds(1,1) = 18: ds(1,2) = 3: ds(1,3) = 45: ds(1,4) = 110: ds(1,5) = 1
ds(2,1) = 34: ds(2,2) = 3: ds(2,3) = 91: ds(2,4) = 8: ds(2,5) = 70
ds(3,1) = 2: ds(3,2) = 0: ds(3,3) = 4: ds(3,4) = 57: ds(3,5) = 6

Ennél a nehézkes megoldásnál kényelmesebb a READ – DATA utasításpárral megtenni ugyanezt:

Dim ds(3,5)
For i=1 To 3: For j=1 To 5
Read ds(i,j)
Next j: Next i
Data 18, 3, 45, 110, 1, 34, 3, 91, 8, 7, 2, 0, 4, 57, 6   '5x3 paraméter

Az utóbbi megoldásban a DATA nem végrehajtandó utasítás, csak a READ számára tárolja az értékeket. A módszernek több előnyös tulajdonsága és alkalmazási finomsága van, és a BASIC nyelvekben hagyományosan ott is vannak ezek az utasítások; a Visual Basicből valamiért kimaradtak, noha választható lehetőségként meghagyható lett volna, számos más, régies utasításhoz hasonlóan.

• megjegyzésblokk – vannak olyan programnyelvek, amelyekben több összefüggő sort egyben tudunk megjegyzés (komment) állapotúvá lefokozni, kivonva azokat a végrehajtandó utasítások közül, a tesztelés során. Például ilyenek a <!-- --> vagy /* */ jelpárok. A BASIC csak egyetlen sorra kiterjedő lehetőséget ad erre, klasszikus változatában a REM utasítással, a Visual Basic esetében ezenfelül az aposztróf (') karakterrel (lásd az előző példa végét). Ez egy többsoros programszakasz átmeneti kiiktatását nehézkessé teszi, de a szerkesztőfelületen van egy lehetőség egy kijelölt szakasz minden sorának egyszerre történő, soronkénti megjegyzéssé alakítására és abból visszaállításra.
• öröklődés – ez az objektumorientált programozási elméletbe később bevont fogalom az adatok és adattípusok közötti logikai kapcsolatok automatikus fenntartását és átalakítását tartalmazza. Elsősorban a C+ nyelvtől indult nyelvi irányzat használói hiányolják ezt az eszközt, noha ezzel nehezen követhető adatstruktúrát is gyorsan létre lehet hozni. A Visual Basic .NET már tartalmaz ilyen lehetőségeket.
• polimorfizmus – az eljárások definiáltságának ez a szélsőséges rugalmassága kétségtelenül eltávolodna a Visual Basic klasszikus konvencióitól és egyértelmű utasításszerkezetétől, megnehezítve az automatikus hibaellenőrzést is. De mivel a nyelv a gyengén típusos nyelvek csoportjába sorolható, a polimorfizmushoz szükséges rugalmas típuskonverziók, valamint az eljáráshívásokban elhagyhatóvá (Optional) tehető paraméterek részben megadják a lehetőséget ennek az eszköznek az utánzásához.

1. ↑ Az elnevezés abból az időből származik, amikor még képernyő helyett a programok üzeneteiket a konzolra, a billentyűzettel egybeépített nyomtatóra küldték.

A forráskód alakban fejlesztett és tesztelt programot végül olyan alakba kell átalakítani, amelyet a Visual Basic telepítése nélkül is futtatni lehet más felhasználók gépein. Ehhez a program lefordítása („kompilálása”) szükséges, az ezt végző program szintén a fejlesztőrendszer része.

A fordítás megkezdése előtt a rendszer teljes ellenőrzést végez a programon, amivel az összes futtatás előtt kiszűrhető hibát megtalálja, és ezek közül az elsőnek a helyét és típusát megjelöli. A programban levő logikai vagy adatkonverziós hibákat programmal nem lehet kiszűrni, az a programozó munkájának a része.

A fordítás kétféle jellegű futtatható programkódba alakíthatja át a forráskódot. Az egyik típus neve P-kód (más esetekben használt néven tokenizált alak). Az ilyen alakba lefordított programban nincs minden művelet gépi kóddá alakítva. A Visual Basic nyelv összes fontosabb elemi műveletét, utasításait gépi kódban leíró programrutinok egy közös fájlba vannak összefoglalva, és a P-kód az ezekre való hivatkozásokat tartalmazza csak. Így nincs minden tevékenységet pontosan előíró gépi kódú program a lefordított programba is összeillesztve, emiatt a fordítás eredményeként létrejövő futtatható, EXE kiterjesztésű fájl jóval kisebb méretű lesz. Az alapelemeket tartalmazó futásidejű könyvtár (Run-Time Library) a gépen megtalálható, és onnan töltődik be akkor, amikor szükség van rá. Amikor a gépen több P-kódba fordított, Visual Basic 6-ban készült program van, akkor ezek alapelemeit egyetlen közös fájlban meg lehet találni a Windows rendszerfájljainak mappájában, MSVBVM6.DLL néven (a mérete 1354 KiB). Ahhoz, hogy egy P-kódba fordított program működhessen, a telepítéskor ezt a fájlt is a Windows rendszerbe kell másolni. Mivel a P-kódú program a műveleteket mindig máshol keresi meg, a program sebessége a helynyereségért cserébe egy kicsivel lassabb; a program céljának ismeretében mérlegelhető a fontosabb szempont. Olyan programnál, amely általában a felhasználó egérmozdulatára, billentyűleütéseire vár, a sebesség nem bír nagy jelentőséggel.

A másik lehetséges fordítási forma a natív kód, ami azt jelenti, hogy az egész program, minden részletével együtt gépi kódba van lefordítva, amelyet aztán a Windows operációs rendszer alatt közvetlenül futtatni lehet. Futásidejű könyvtárra ekkor nincs szükség. A minden elemi utasítást is tartalmazó programkód nagyobb méretű, de a végrehajtási sebessége valamivel gyorsabb. Olyan programnál lehet ez lényeges szempont, amely hosszú műveletsorokat, számításokat, adatbázis-elemzéseket végez a felhasználó beavatkozása nélkül, illetve amelyre sok képernyőművelet, rajzolás, képfeldolgozás jellemző.

Még a natív kódba lefordított programoknál sem gyakori, hogy a fordítás eredményeként létrejött EXE kiterjesztésű fájlnak egy másik gépre való átmásolása önmagában elegendő annak futtatásához. A Visual Basic fő célja ugyanis képi elemekből egy látványosabb felhasználói felület felépítése és kezelése, és a képen megjelenő vezérlések megjelenítéséhez és működtetéséhez szükséges programrutinokat a rendszer már a tervezési folyamatban külső fájlokból veszi. Ilyen ActiveX vezérléseket OCX vagy DLL kiterjesztésű fájlok szoktak tartalmazni, és az ezekben levő kód a natív kódba való fordításkor sem kerül át a programba. Emiatt a program üzembe helyezéséhez ezeket a fájlokat is az adott gépre kell másolni, ezt a feladatot végzi el a programok telepítőcsomagja.

A Visual Basic fejlesztőrendszer tartalmaz egy Package & Deployment Wizard nevű programot, ezzel a programunkhoz összeszerkeszthető egy telepítőcsomag, amelyet már lemásolhatunk, elküldhetünk, terjeszthetünk. A telepítőcsomag az összes szükséges ActiveX vezérlést, a futásidejű könyvtárat és az egyéb szükséges elemeket tartalmazni fogja, és telepítéskor az adott gép rendszerébe építi.

A külön fájlokban tárolt vezérlések és más kiegészítők látszólag kényelmetlenséget okoznak, holott a módszer előnye az, hogy ha az adott gépen valamelyik kiegészítőnek már egy frissebb, feltehetőleg javított minőségű példánya van, akkor a program azt fogja használni. Hasonlóképp ha egy már telepített program valamelyik összetevőjének egy frissített változata válik elérhetővé, akkor elegendő a gépen csak azt lecserélni, és nem szükséges magát a programot is újra lefordíttatni annak készítőjével.

Egy programozók között jól ismert, népszerű pamflet egy híres kijelentése a FORTRAN programnyelvről így szól: „Amit nem lehet megcsinálni FORTRAN-ban, azt meg lehet csinálni assemblyben. Amit nem lehet megcsinálni assemblyben, azt nem lehet megcsinálni.”^[11] Ez ugyanígy érvényesnek tekinthető minden magas szintű programnyelvre, így a BASIC-re is. Ám azért, hogy minden olyan célra, amire a Visual Basic nem tartalmaz beépített utasításszót vagy függvényt, ne kelljen a programozónak assembly nyelven saját kiegészítő programot írnia, a Visual Basic sokféle lehetőséget ad mások által már elkészített és közzétett részprogramok egy-egy részletének közvetlen felhasználására.

A VB6 által alapértelmezés szerint felhasználhatóvá tett vezérlések egyike az OLE típus. Ez a vezérlés külső dokumentumok, más fájlok tartalmának megjelenítését teszi lehetővé az épülő programon belül, anélkül, hogy a program írójának ismernie kellene az adott dokumentum tartalmi szerkezetét, adatkódolási eljárásait. A beágyazott dokumentumot ugyanis az ahhoz a fájltípushoz társított alkalmazás fogja megnyitni, együttműködve a készülő programmal, vagyis a program futtatásakor az ide tartozó másik alkalmazásnak egy része szintén elindul. Ezzel a módszerrel akár egy videófájl, egy 3D műszaki rajz, egy hangfelvétel is a programba illeszthető és megjeleníthető. Minden olyan típusú dokumentum beágyazható így, amelynek a saját kezelő-, szerkesztőprogramja kész az OLE típusú együttműködésre, ezeknek a listáját a vezérlés beillesztésekor megkapjuk. Az így beágyazott objektumot a programunk nem tudja megváltoztatni, csak megjeleníteni, valamint elindítani a szerkesztéséhez szükséges alkalmazást.

Az OLE formátumú objektumok egyik későbbi felhasználási módja lett a saját vezérlési objektumok készítése és tárolása. Ezek az objektumok más programokba beilleszthetők, tulajdonságaik, metódusaik és eseményeik a programkódba bevonhatók, ugyanakkor külső, függetlenül frissíthető rendszerelemek maradnak. Az ilyen vezérlések többségének van látható formája, ezt a készítője tervezi meg és készíti el. A VB3 verzióig ugyanezt a feladatot a VBX (Visual Basic eXtension) komponensfájlok látták el. Az OCX típusú bővítéseknek a Microsoft az ActiveX nevet adta, de ennek a névnek a használata nem egységes, és gyakrabban találkozhatunk vele olyan kiegészítéseknél, amelyek nem pusztán más Visual Basic-vezérlésekből összefogott kisebb programok valamilyen feladatra, hanem mélyebb rendszerszintű képességek egyszerűbb elérését teszik egyszerűbbé. Az OCX objektumok OCX vagy DLL kiterjesztésű fájlok alakjában érhetők el.

A DAO a Microsoft saját fejlesztésű rendszerkomponense, és adatbázis-fájlok létrehozásához és kezeléséhez ad közvetlen támogatást a programok részére. Microsoft Jet típusú adatbázisok kezeléséhez való, az adatok „MDB” kiterjesztésű fájlokban lesznek tárolva. A Data típusú beépített vezérlés egy adatbázis megnyitására és tartalmának kezelésére ad egy primitív eszközt, de ennek használatára nincs szükség, mivel a kiegészítés új típusú objektumok definiálását teszi lehetővé. Ezek: DBEngine, Workspace, Error, Connection, DataBase, TableDef, Table, QueryDef, Recordset, Relation, Field, Index, Container, Document, Group, User. Ezeken az objektumokon végzett metódusokkal, utasításokkal, valamint az objektumok tulajdonságaival többféle adatbázis-kezelési és megosztási modell szerint is felépíthetjük az ezt használó alkalmazást, akár az SQL-hez hasonló lekérdezési és háttértranzakciós szolgáltatásokat is igénybe véve. A DAO a korábbi ISAM (Indexed Sequential Access Method) támogatást váltotta fel.

Ez az adatelérési módszer egy másik alkalmazás által kezelt távoli adatbázis elérését teszi lehetővé, azzal az alkalmazással kommunikációt tartva. Ez a technika az OLE kapcsolatokhoz hasonlóan nem törekedik a más programok által használt adatbázisok szerkezetének felismerésére és közvetlen kezelésére, hanem ha az adatbázistípus kezelésére készült alkalmazás elindítható, valamint szerepel benne az ODBC kapcsolat létrehozásához szükséges képesség, akkor az adatok kezelését a programunk annak az alkalmazásnak a tolmácsolásában intézheti. A mára elterjedt SQL (Structured Query Language) adatbázis-kezelő parancsfelület ún. motorja is így vehető igénybe. Az ODBC-szolgáltatásokat a Visual Basic közvetlenül a nyelvbe építve támogatja, de azok az API felülethez hasonló módon közvetlenül is hívhatók.

Fentebb már említés történt a DLL kiterjesztésű fájlokról, mint a programba illeszthető ActiveX vezérlések egy lehetséges hordozójáról. De a DLL ennél többet tesz lehetővé, mivel ez a fájl eljárások és szolgáltatások könyvtárát tartalmazza más programok részére, és ezeket, ha az ehhez szükséges adatokat ismerjük, mi is igénybe vehetjük; ennek technikája azonos az API eljárásának meghívásával. Az is lehetséges, hogy a készülő program egy részét más írja meg, és a főprogram által elindítható eljárások alakjában adja át nekünk. A DLL gépi kódú programrutinokat tartalmaz, emiatt nem számít, hogy azokat milyen programnyelven írták meg. Ezzel a technikával a Visual Basicben írt programunk is felhasználhatja a mások által írt programrészeket, lényegében univerzálisan illeszkedve az összes többi, PC-alapú programnyelvhez.

A Windows is számtalan eljárást és szolgáltatást tartalmaz, amelyet a saját részprogramjai használnak, de a programozók is felhasználhatják azokat saját programjaikhoz, jellegzetesen Windows-kötődésű, fontos alapfeladatok megoldására. (Ezek zöme egyébként szintén DLL fájlban van jelen, főleg a Windows\System32 alkönyvtárban.) Ezek minden olyan programnyelvből meghívhatóak, amelyek képesek külső gépi kódú eljárások elindítására és paraméterek szabványos átadására; a Visual Basic is ezek közé tartozik. API alatt az ilyen, nagyszabású rendszerkomponens-gyűjteményt értjük, illetve az ezek eléréséhez szükséges paraméterdefiníciók részletes listáját. Ezek felhasználásával azok a feladatelemek is megoldhatók, amelyeket a Visual Basic nem támogat saját kódszóval, esetleg kívül is esik egy közönséges alkalmazás szokásos hatókörén. Az API eljárásainak felhasználására egy példa:

Declare Function IsWindowVisible Lib "user32" (ByVal hWnd As Long) As Long
Function LoadTaskList(vvP$)
    If IsWindowVisible(cw&) Then
        h = fl And 1
    End If
End Function

Ez az (önmagában értelmetlen) példa azt mutatja, hogy az API függvényének vagy eljárásának deklarálása után a programban az már ugyanúgy használható, mint bármely más függvény vagy eljárás. Az API felhasználáshoz természetesen ismerni kell az elérhető eljárások listáját, a hívott eljárás paramétereinek szerepét, típusát és sorrendjét, de a Microsoft mindezt letölthető, részletes dokumentációban teszi közzé.^[12]

Nem csak a Windowsnak van saját dokumentált API rutingyűjteménye, hanem néhány más jelentős rendszerkiegészítésnek is (pl. Java, DirectX, OpenGL), lehetővé téve az azokban rejlő speciális lehetőségek felhasználását egy Visual Basic nyelvű programból is.

• ↑ Microsoft Visual Basic Programming System for Windows: – Version 3.0 (Microsoft Corporation, 1993, USA DB51410-0993)
• ↑ Hargittai Péter – Kaszanyiczki László: Visual Basic 3.0: (LSI Oktatóközpont, ISBN 963 577 101 0)
• ↑ Kaszanyiczki László: Visual Basic 5.0 felhasználóknak: (LSI Oktatóközpont, 1998)
• ↑ Visual Basic 6.0 Product Documentation: Termékleírás (angol nyelven). msdn.microsoft.com. (Hozzáférés: 2013. augusztus 4.)
• The Visual Studio Documentary: Part One (In celebration of the 2010 Launch) Archiválva 2013. augusztus 16-i dátummal a Wayback Machine-ben Part Two Archiválva 2013. augusztus 16-i dátummal a Wayback Machine-ben (angol nyelvű videók) (msdn.com)