Overleg:Visual Basic for Applications

Terwijl ik onderstaande aan het scrhijven was, werd de oorspronkelijke pagina hernoemd. En daar kreeg ik geen melding van.

VBA is object-georiënteerd? Dat zou ik toch niet durven stellen.

--Taka 4 okt 2004 10:44 (CEST)

Verder: is VBA niet dichter by VBScript dan bij Visual Basic? Wordt het bijvoorbeeld gecompileerd opgeslagen? En hoe kom je aan versie informatie van VBA? Ik zie alleen Application.Version, maar dat geeft natuurlijk de versie van de applicatie, en niet de versie van de scriptengine. Ik zie niet hoe je de versie van de scriptengine kan oproepen, die is er waarschijnlijk helemaal niet.

Nogmaals, VBA is net zo object-georiënteerd als VBScript, en dat is dus *niet* object-georiënteerd. Het is wel mogelijk om een object te creeëren vanaf een bestaande Class, en zelfs om classes te schrijven in VBA, maar het is geenszins verplicht. Dat is toch niet echt "object-goriënteerd".

Ik heb het woordje "quasi" erbij gezet. Het artikel kan overigens nog wel een beurt gebruiken, ik zal er vanavond eens naar kijken. Danielm 4 okt 2004 17:12 (CEST)

Dat VBA object-georiënteerd is heb ik erbij gezet. (Gebruiker:Johan Lont). Maar ik ben er niet zo super zeker van. Ik heb VBA een tijd terug eens bekeken, en ik meende me te herinneren daarin die typische constructie met objectvariabele.methodenaam en objectvariabele.membervarabele gezien te hebben.

Naar aanleiding van bovenstaande opmerking van Taka ben ik nog eens gaan kijken. Ik zie in de taal wel enige 'objectgeoriënteerde' trekken; je komt namelijk objecten tegen, die staan voor dingen als Workbooks, cells, charts. Ik zie nu echter ook dat de mogelijkheid om zelf een class voor een nieuw soort object te programmeren ontbreekt. Je kunt geloof ik ook niet schrijven

Dim mijnVariabele As mijnClass  
mijnVariabele = New mijnClass 

of zoiets.

in VBA wordt het volgende gebruikt: Set MyObj = CreateObject("klasse-referentie") '--Taka 11 okt 2004 18:51 (CEST)

In de gewijzigde formulering (als quasi-object-georiënteerd) kan het er wel bij blijven staan. Johan Lont 11 okt 2004 17:28 (CEST)

Ik ontken niet dat VBA objecten kan gebruiken, maar dat kan javascript ook. In javascript kan je ook classes definiëren. Dat maakt de taal nog niet object-georiënteerd. In VBA kan je wel een Class definiëren. In de VBA editor zie ik onder "Insert" "Class Module" staan. VBScript kan vanaf versie 5.0 ook Classes aan. In een taal als java moet alles in objecten staan. Een belangrijk onderdeel van OOP is inheritance. Inheritance is bij VBA echter niet aan de orde. Verder is het in VBA wel mogelijk om een instantie van een bestaande class te gebruiken (met het CreateObject statement), en vervolgens kunnen dan alle properties & methods van het object benaderd worden met obj.MethodName() en obj.PropertyName(). Maar ook dat is in vele script-talen mogelijk (ook bv Javascript, VBScript en Perl kunnen dat), daarmee zijn ze als taal zelf nog niet object-georiënteerd.

Ik weet ook niet heel zeker wat de definitie is van een OOP taal, maar ik zou zeggen: alle code *moet* in classes staan (lineair programmeren is onmogelijk), en classes erven van van hun superclass. VBA voldoet aan geen van beide voorwaarden. --Taka 11 okt 2004 18:45 (CEST)

Ik heb de indruk dat 'object-georiënteerd' geen exact begrip is. Het omvat kenmerken als polymorfie, overerving, encapsulatie en een programmeertaal kan daar meer of minder van hebben. Naar mijn idee kun je echter een taal waarin je een class niet kunt laten erven van een superclass moeilijk object-georiënteerd noemen. Die andere eis - dat alle code in classes moet staan - is moeilijk vol te houden. De taal C++ wordt omschreven als een uitbreiding van de programmeertaal C met classes en dergelijke. Ik vermoed dat je daarin wel lineair kunt programmeren, terwijl C++ over het algemeen toch als object-georiënteerde taal beschouwd wordt. Johan Lont 12 okt 2004 10:49 (CEST)

Je hebt pure oop-talen (Smalltalk, Java) en gemengde talen (C++, moderne Pascalimplementaties). In een gemengde taal kun je oop mengen met procedurele code. VB ontbreekt veel functionaliteit van OO-talen, zoals overerving, polymorfie. Daarnaast is het standaard niet goed mogelijk eigen objecten aan te maken, je gebruikt alleen objecten uit kant en klare modules (uit DLL- en OCX-bestanden). Dit is wel erg mager om VB object geörienteerd te noemen; in een gemengde taal als C++ of Pascal kan je nagenoeg pure oop-code schrijven, in VB is het in de buurt komen hiervan totaal onmogelijk. Danielm 12 okt 2004 11:27 (CEST)

Waar is VBA van afgeleid?

Ed de Jonge heeft

De programmeertaal van VBA is exact dezelfde als die in Visual Basic, waarvan het is afgeleid. VBA is evenals Visual Basic een quasi objectgeoriënteerde programmeertaal.

verandert in

VBA is een voortzetting van macro-talen, zoals WordBasic, dat in de oudere versies van Microsoft Word werd gebruikt. Het werd later aan Visual Basic toegevoegd.

met in de samenvatting: (Niet afgeleid van Visual Basic, maar later hieraan toegevoegd) Ik weet niet zoveel van VBA, maar is het niet zo dat VBA zowel wat van VB heeft als van macrotalen zoals WordBasic.

Ik heb het vermoeden dat de functionaliteit van WordBasic e.d. helemaal is overgenomen, dat de functionaliteit van Visual Basic grotendeels is overgenomen (de kern in elk geval), en dat de 'syntax' en 'structuur' helemaal is aangepast aan Visual Basic.

Misschien kan iemand die er meer van weet dat in wat meer detail in het artikel te schrijven. Qua functies is het wellicht van WordBasic e.d. afgeleid; qua opbouw en syntax is het wellicht van VB afgeleid. Johan Lont 20 mei 2005 15:45 (CEST)

Na enig speurwerk blijkt mijn wijziging deels onjuist. Ik stel voor, hem te vervangen door:

VBA is een vervanging voor macro-talen, zoals WordBasic, dat in de oudere versies van Microsoft Word werd gebruikt. Visual Basic stond model voor de structuur. Het werd later aan Visual Basic toegevoegd.

Van dat achteraf toevoegen ben ik zeker. Ed de Jonge 20 mei 2005 16:56 (CEST)

Ik begrijp niet goed wat je bedoelt met "toevoegen aan Visual Basic". Misschien dat je dat duidelijker kan formuleren? Taka 20 mei 2005 16:57 (CEST)

Het is helemaal niet toegevoegd aan Visual Basic. Veel moderne applicaties zijn uitgerust met de mogelijkheid VBA-macros te gebruiken. VBA gebruikt de taal van Visual Basic, die uniform wordt gebruikt door alle programmas die zijn uitgerust met VBA (zoals Excel, AutoCAD vanaf AutoCAD2002, Word), maar werkt onafhankelijk van Visual Basic. Voor het gebruik van VBA hoef je geen Visual Basic te hebben. Visual Basic is een ontwikkelomgeving waarin stand-alone programmas geschreven kunnen worden. Het is wel mogelijk om een Visual Basic programma bijvoorbeeld in Excel een xls-bestand te laten bewerken of in AutoCAD een tekening te laten maken. Hiervoor kunnen grotendeels vergelijkbare codes worden gebruikt als bij VBA, maar dan extern. Voor het schrijven van Visual Basic programmas is een apart packet nodig, Visual Basic of Visual Studio (waar Visual Basic in zit) en is meer programmeerkennis vereist dan voor VBA. Als ik tijd heb zal ik eens naar dit artikel kijken, want ik programmeer vrij veel is Visual Basic en zo nu en dan met VBA. Jcb - Amar es servir 20 mei 2005 17:20 (CEST)

De oudste versies van VB kennen geen VBA. VBA bestond al een tijdje, toen het van kantoor-software werd overgeheveld naar Visual Basic 4, als uitbreiding. Ed de Jonge 20 mei 2005 17:33 (CEST)

VBA is geen onderdeel van Visual Basic. Jcb - Amar es servir 20 mei 2005 18:02 (CEST)

Alle VB-versies vanaf versie 4 installeren standaard de VBA-library, zelfs de Learning Versions. In VBA zitten zaken als Collection, ErrObject en een aantal andere veel gebruikte classes. Boeken voor beginners gaan op deze zaken in. Hierbij gaat men niet uit van de toevallige aanwezigheid van een MS-Office-onderdeel of een andere applicatie, die de library zou moeten leveren. Zie ook MSDN. Ed de Jonge 20 mei 2005 19:02 (CEST)

Ik ben ook wel benieuwd naar de zeer gebrekkige set standaard objecten worden meegeleverd. Voor zover ik weet worden een heleboel objecten standaard met bepaalde programma's meegeleverd. Zelf doe ik vooral dingen met ASP (met VBScript). Objecten als ADODB (voor werken met databases) en MSXML (voor werken met XML) staan op bijna elke PC, ADODB komt vooral met Access (maar is ook een gratis download), MSXML komt met Internet Explorer. Uiteindelijk kan je met VBScript (en dus ook met VBA) met behulp van standaard-objecten bijna alles doen, inclusief binaire bestanden bewerken. VBA (VBS) zelf heeft weinig binarie functies - wel een paar zoals InstrB, MidB en LenB die in combinatie met standaard objecten van alles kunnen. Bijvoorbeeld base64 encoding gaat zeer snel met de volgende code (en het werkt net zo goed in VBA als VBS).

Function ToBase64(ByVal bin)
    Dim oXML, oNode

    Set oXML = CreateObject("Msxml2.DOMDocument.3.0")
    Set oNode = oXML.CreateElement("base64")
    oNode.dataType = "bin.base64"
    oNode.nodeTypedValue = bin
    ToBase64 = oNode.text
    Set oNode = Nothing
    Set oXML = Nothing
End Function

Taka

Bedoel je nou dat het wel of juist niet gerechtvaardigd is om het te hebben over zeer gebrekkige set objecten die applicaties en VBA zelf aanleveren. Dat leerboeken uitgaan van de standaard objecten lijkt me vrij normaal. Ik meen dat er een aantal vrij interessante objecten gratis ter beschikking zijn voor VBA, of als installatie bij verschillende applicaties, of als gratis download, al dan niet van Microsoft. Zowel ADODB als MSXML zijn een gratis downloads, de laatste wordt met IE geïnstalleerd, en aangezien IE een onderdeel is van Windows staat het altijd ter beschikking.

Het hangt er natuurlijk ook erg van af wat je wil doen. Zoalng VBA als macro-taal wordt gebruikt, dan is er natuurlijk weinig behoefte aan dergelijke objecten. Zodra iemand professioneel te werk gaat, tja, dan is MS Access natuurlijk ook maar een speelgoed database.

Kortom als VBA naast C++ wordt gelegd dan wint C++ natuurlijk probleemloos. Maar VBA is dan ook niet bedoeld als een volwaardige programmeertaal. Dat is wel vermeldenswaard. Maar over VBA vermelden dat er van "gebrek aan kracht in de taal" sprake is, lijkt me wat overdreven gezien de context waarvoor het bedoeld is.

Taka 20 mei 2005 19:48 (CEST)

Mijn vorige bijdrage (nu verplaatst) was gericht aan het adres van Jcb - Amar es servir, die beweert dat VBA überhaupt niet in VB voorkomt. Ik heb geen oordeel over de waarde van VBA, daar ik geen kennis heb van andere talen dan VBA en VB en dus niet kan vergelijken. Ed de Jonge 20 mei 2005 20:01 (CEST)

Je haalt twee zaken door elkaar, namelijk:

• VBA, standaard meegeleverd (geïntegreerd) bij alle programmas die ermee zijn uitgerust, niet bij Visual Basic. Hiermee kunnen binnen een programma macros worden geschreven.
• De mogelijkheid van Visual Basic programmas om van buiten programmas als Excel te gebruiken. Hoe dan ook kan een Visual Basic programma geen programmas aansturen die niet op de pc aanwezig zijn. Excel opstarten al Excel niet aanwezig is gaat eenvoudig niet.

VBA voor Visual Basic zou ook nogal overbodig zijn, wie wil er nu macro's maken voor binnen Visual Basic? Jcb - Amar es servir 21 mei 2005 00:17 (CEST)

Accoord. Begripsverwarring van mijn kant. De VBA-library is maar een onderdeeltje van de hele VBA. Ik neem maar vast de vrijheid om het lemma weer bij te stellen. Ed de Jonge 28 mei 2005 11:30 (CEST)

Visual Studio for Applications

De opvolger voor VBA is Visual Studio for Applications (VSTA). Misschien leuk om hier een link naar toe te maken?

Dat is niet helemaal zo, Visual Basic is een onderdeel van Visual Studio. Jcb - Amar es servir 23 mei 2006 17:49 (CEST)