[Mono-list] Re: Am confused

[Marco Parenzan]

Some precisations:   >Brief summary.  Highly suspect, but brief, and has the highlights. ;-) >1.  Microsoft BASIC on DOS >2.  Microsoft extends/rewrites, named Visual Basic 1.0     Microsoft writes Visual Basic 1.0 on Alan Cooper's work named Ruby (an environment that allow to draw windows - in 1987) and on QuickBasic   >3.  Visual Basic is popular; has several revisions (VB 1.0 - VB 6.0) >4.  Microsoft gets great idea that there should be a common scripting >    language across all Microsoft products; calls it VBA (Visual Basic >    for Applications).  It's a simplified version of Visual Basic;  >    same (similar?) syntax, different object model (to take advantage >    of the applications).  First introduced (IIRC) with Office 6.0 for  >    Windows 3.1.  Initially supported in Excel & Access; Word not  >    supported until Office 95 or 97.       Microsoft added basic like macro languages to Access 1.0 and Excel. they were VB-like (not VB subset). VBA starts appearing with office 4.2 (Excel 5.0 and Access 2.0), but again different from VB1.0/2.0/3.0.     The big change comes with VB5.0/6.0 in which VBA for Office 97 and VB are completly rewritten and VBA is a real subset of VB (just look into DLLs - they are the same)     VB become "the COM-language" in the Internet/ActivceX era.   >5.  Internet gets big; Microsoft releases smaller version of VBA, calls  >    it VB Script.  Used primarily with IIS ASP, Windows Scripting Host, >    etc.       VBScript is not a VBA Subset: is a kind of JavaScript with VB syntax - and some different costructs (it's like VB.NET that can be though as a C#  with VB syntax)   >6.  Microsoft works on .NET; changes VB syntax/semantics, calls it  >    VB.NET. >The deal with VBA, primarily, is a library that developers can link into >their applications to allow scripting of the applications.  All the >developer needs to do is expose a COM object model (implement lots of >IDispatch COM interfaces), and link in the VBA library.  (Of course, >this simplifies things a bit; the object model must be created, and >there are probably more steps to add VBA.)  After this, users can write >VBA script, utilizing the applications object model, and script the >application.       VBA is not scripting: it's a real compilation as it was under VB6. VB was instead completly interpreted only until VB3.0 (and 4.0, if I remember well) >VBA is basically a VBScript interpreter, linked to the application so >that it knows about the program's object model, which interprets VBA >>scripts the user provides.       VBA is not a VBScript interpreter, but they use the same approach: when you host VBScript or VBA, you have to add you object model (example: Excel adds Workbook/Worksheets objects to VBA engine) >As for the relationship between Access, Excel, and VBA, all Office apps >expose an object model which can be scripted through COM, as described >above.  Access, Excel, et. al merely expose the object model so the >script interpreter can operate.  They accept scripts written in VBA (a >superset of VBScript), but they can also be "scripted" through "normal" >COM interop, allowing for control from  C/C++, Perl, TCL/TK, and any >other COM-supporting language. >Hope this provides an adequate summary. > - Jon