Microsoft blijft VBA in toekomstige Office-versies ondersteunen

Het ontwikkelteam van Microsoft Office heeft op zijn blog aangekondigd dat Visual Basic for Applications ook in toekomstige versies van de kantoorsoftware ondersteund zal worden.

De speculaties over een eventueel einde van de scripttaal doken op nadat Microsoft Office 2008 voor de Mac uitbracht. In dit pakket is ondersteuning voor VBA weggelaten, omdat Microsoft van mening was dat het overzetten van de taal naar het OS X-platform te veel tijd zou kosten. Mac-gebruikers kunnen wel macro's op basis van AppleScript in de verschillende Office-applicaties aanroepen, maar uitwisseling van scripts met pc-gebruikers is niet mogelijk.

Dat VBA in de ogen van Microsoft in feite al is afgeschreven, is algemeen bekend. De softwaregigant geeft sinds augustus 2006 geen licenties voor de scripttaal meer uit en probeert ontwikkelaars te bewegen om Visual Studio Tools for Applications of Visual Studio Tools for Office te gebruiken. De aankondiging dat Microsoft in het aankomende Office 2009 nog wel een plaatsje voor VBA heeft ingeruimd, is vooral bedoeld om de talloze Word- en Excel-macro's die in gebruik zijn, niet in een keer onbruikbaar te maken. Eerder kreeg de softwaregigant al de nodige kritiek op het afschrijven van oudere bestandsformaten, waaronder een aantal Office-formaten.

Reacties (20)

[SPee]

Zijn er geen converters die het over kunnen zetten naar een scripttaal die wél ondersteund wordt

Bv. van VBA, naar C# of VB.net ?

[Niemand_Anders]

Novell was bezig om .NET te implementeren in OO, maar dat werd volledig door de open source community afgekraakt. Ook het feit dat Novell OpenXml (Microsoft's XML formaat) heeft toevoegt aan OO werd ze niet in dank afgenomen.

Het grootste probleem waar Novell mee kamt is het feit dat de scripting mogelijkheden van OO zelf erg beperkt zijn, waardoor het erg lastig is om bijvoorbeeld Word macro om te zetten naar een Writer macro. Scripting mogelijkheden in Javascript, BeanScript of Python zijn niet krachtig genoem. Blijven de add-on's in java over. Helaas moet je als developers deze wel eens compileren voordat je deze kunt gebruiken. Daarbij is het eerder OpenOffice welke beschikbaar wordt in Java, dan Java welke bescikbaar is in OpenOffice.

Novell probeerde hier omheen te werken door enorme libaries binnen OO te bouwen (op basis van de java api's) zodat deze vanuit andere talen beschikbaar zijn Door die library vervolgens beschikbaar te stellen aan bijvoorbeeld het Mono project, kunnen 'helper' applicaties worden geschreven welke binnen dmv van api call's binnen OO draaien. Daarbij wil mono zowel de java- als mono runtime gaan hosten *IN* open office.

Het laatste wat ik heb vernomen van dit team is dat ze bezig waren de Mono CLR te integreren in OO zodat application domains beschikbaar komen en daarmee de broodnodige sandboxing. Van wat ik heb begrepen zijn ze nu bezig het object model van MS Office in kaart te brengen zodat ze wrapper objecten kunnen schrijven welke macro's omzetten naar OO macro's.

Novell doet flink zijn best om OO interessant voor bedrijven te maken, maar wordt op zo'n beetje elk vlak tegen gewerkt. Vorige week toen ik in Kansas was heb ik de Novell 2008 Kick-off meeting bijgewoond waarin Novell de koers voor 2008 uit de doeken deed.

De kans dat Novell een fork gaat doen op de code base van OO is erg groot. Een terugkerend punt was het feit dat open source communities maar geen kunnen (of willen) krijgen in zaken welke belangrijk zijn voor het bedrijfsleven. Miguel (de Icaza, lead developer van Mono) deed zelfs de uitspraak dat als open source developers krampachtig alle pogingen om compatible met Microsoft producten te worden blijven afkraken c.q. tegenhouden dat Linux nooit meer dan een huis, tuin en keuken OS voor de desktop word.

Voor zover zijn er geen converters voor VBA.

[SMGGM]

Waarschijnlijk niet, om dezelfde reden waarom er geen converters zijn voor ASP naar PHP, Java naar J# ...
Hoewel de taal en syntax praktisch hetzelfde is kan een programma nog niet inbeelden wat de programmeur wilde maken met zijn code. De kans is zelfs zeer klein dat er ooit zoiets komt. Er zijn al bedrijven dat dit hebben geprobeerd maar telkens liep dit op tot zeeeeeeer zware programma's die rotslecht geoptimaliseerd waren.

[Aaargh!]

In dit pakket is ondersteuning voor VBA weggelaten, omdat Microsoft van mening was dat het overzetten van de taal naar het OS X-platform te veel tijd zou kosten.

Als je een heel office pakket kan ontwikkelen dan zou het porten van de VBA interpreter toch niet zo heel veel extra werk zijn, tenzij het zulke lelijke, niet-portable code is dat het betekend dat je de boel vanaf 0 moet herschrijven.

Ik vermoed dat dit hier het geval is, MS lijkt niet in staat om nette, portable code te schrijven.

Dit was ook al duidelijk toen MS nog een versie van IE voor de Mac uitbracht, deze werkte met een totaal andere rendering engine (tasman) dan IE voor windows (trident). Dit is erg vreemd vooral gezien het feit dat elke andere browser bouwer wel in staat was een crossplatform render engine te schrijven. Zo wordt b.v. de render engine die Apple gebruikt (WebKit, afgeleid van khtml) tegenwoordig zelfs gebruikt op Nokia Series 60 toestellen, waar gewoon zeer uitgebreide ondersteuning voor CSS, Javascript (en b.v. ook AJAX apps) in zit. Ondertussen is 'pocket IE' op Windows Mobile om te huilen zo slecht.

Je zou denken dat als Nokia een door Apple aangepaste, origineel voor KDE op *nix geschreven render engine kan gebruiken in hun toestellen, dan MS niet zo'n moeite zou moeten hebben om de engine uit IE naar Windows Mobile te porten.

[Dreamvoid]

Da's niet zo gek, aangezien op Windows IE ook de filebrowser is en er een hele API aan hangt voor allerlei Windows progs. Die functie hoefde het op de Mac helemaal niet te hebben (dat zou de code alleen maar lastiger maken), dus hebben ze de rendering engine van IE al in een eerder stadium (ik geloof de IE3 tijd al?) gestript en geforked als Tasman, en daarna onafhankelijk van Trident doorontwikkeld, totdat ze er geen brood meer in zagen. MS is wel in staat geweest om IE en allerlei andere apps en frameworks te porten naar ARM (Windows Mobile), dus portable code schrijven kunnen ze wel.

Probleem blijft dat MS altijd sterk uit lijkt te gaan van de hele uitgebreide API's die al in Windows zitten ipv de applicaties heel stand-alone te ontwikkelen (aka, "het wiel opnieuw uitvinden"). Dat maakt de portability naar andere OS'en lastig. Een applicatie ontwikkelen in DirectX kost bv veel minder tijd en moeite (zie ook bv een open source project als MediaPortal), maar porteerbaar is het vervolgens niet. Idem als je die handige CoreImage API gebruikt op OS X.

[Reactie gewijzigd door Dreamvoid op 23 juli 2024 17:35]

[Vaudtje]

Als zelfs Microsoft VBA niet meer ondersteunt, is er ook nauwelijks meer over om bedrijven bij een upgrade te weerhouden van een overstap naar bv. OpenOffice.
Als je toch al je macros opnieuw moet bouwen, doe dat dan lekker in een vrij formaat

[TERW_DAN]

Ik denk idd dat dat nog wel eens een belangrijke reden kan zijn geweest. Zelf gebruik ik nooit macros, maar er zijn genoeg bedrijven waarbij het voor talloze dingen gedaan wordt (urenlijsten, orderlijsten, werkplanningen etc). Als dat dingen zijn die je dagelijks gebruikt en dan na 1 update niet meer werken dan haal je als softwareleverancier de nodige woede op je hals. En ik denk niet dat MS daarop aan het wachten is.

[Verwijderd]

Natuurlijk, want je kan voor OpenOffice zo veel gestructureerder programmeren dan met .NET en Visual Studio Tools for Office.

[mae-t.net]

Misschien niet gestructureerder of misschien wel, ik ken de betreffende talen niet, maar als je hoe dan ook moet gaan zitten programmeren en er zijn andere redenen waarom je over zou willen stappen is er dus niets meer dat je tegenhoudt.

[Verwijderd]

Interessant hoe iedere beslissing van Microsoft een manier schijnt te zijn om te voorkomen dat mensen naar vrije software overstappen.

[MadEgg]

Helaas is dat wel de harde werkelijkheid. Microsoft doet er alles aan om mensen, en in het bijzonder bedrijven aan zich te binden. Kan je interessant noemen maar het is wel gewoon waar.

[Dreamvoid]

Uh, doet niet iedereen dat? OpenOffice probeert ook bedrijven naar OO te laten overstappen, en dat doet Apple met iWork ook. iWork macro's in AppleScript zijn ook niet te draaien op Office for Windows, dus eens geschreven voor iWork, zit je "voor altijd" aan OS X vast. Doe je weinig aan. Ik kan mijn AutoCAD scripts ook niet in SolidWorks draaien, of mijn Matlab scripts in Excel.

[ljo13]

Microsoft zou echt dom zijn als ze mensen zouden stimeleren over te stappen naar andere software. Iedere bedrijf probeert zoveel mogelijk winst te maken en dus probeer je ook zoveel mogelijk klanten aan jou te binden. Dat is bij alle bedrijven zo. De basis van de economie is net dat iedereen het hoogst mogelijke eigenbelang probeert na te streven. Zo ontstaat normaalgezien specialisatie en bijgevolg betere producten.

[Icekiller2k6]

behalve office 2008 mac, juist dat is de reden in office 2004 ging het wel & 2008.. voor m'n opleiding moet ik met VBA's werken.. en ik weiger Office 2007 of 2003 (windows versie) te kopen >< zitik dus in de kou als ik nieuwe versies wil.

[Reactie gewijzigd door Icekiller2k6 op 23 juli 2024 17:35]

[Database freak]

Ik werk bij een grote financiele dienstverlener en heb net een hele applicatie in MS Access afgebouwd die geheel op VBA rust. VBA is iets dat je als eindgebruiker makkelijk mee om kan gaan om snel een applicatietje te bouwen zonder dat er een heel IT-project hoeft te worden opgezet. Als MS dit in nieuwere versies laat vallen dan wordt er heel simpel gewoon niet geupgraded en blijven we doorwerken met MS Office 2003.

[Verwijderd]

Backwards compatible blijven met verouderde technieken, en ondertussen mensen stimuleren om de nieuwe tools te gebruiken... Lijkt me de gewoonste zaak van de wereld.

Ik heb even gegoogled, en krijg een video die Visual Studio Tools for Applications introduceerde.... En het eerste wat er gezegd wordt is dat gebruikers macro's kunnen schrijven in Visual Basic en C#....

Tja... lijkt er dan toch op dat Visual Basic echt niet verdwijnt. Ik zou eerder zeggen dat het concept gewoon verder uitgebreid wordt.

[Verwijderd]

Het artikel zegt niks over VB maar over VBA, dat is toch echt wat anders.

[NL-JP]

Geen idee of het mogelijk is maar er zou misschien ook een 'plugin achtige oplossing' voor bv. Openoffice kunnen worden gemaakt. Als dat mogelijk zou zijn is het veel eenvoudiger om over te stappen naar een andere (en goedkopere) office suite.

[jmmk]

Merkwaardigerwijs zal Open Office naar verluidt in het najaar van 2008 VBA juist introduceren in versie 3.0 (en ze hedden al een reeks talen waarin applicaties binnen OOo te schrijven zijn...). Nog een reden om over te stappen?

[Aaargh!]

Da's niet zo gek, aangezien op Windows IE ook de filebrowser is en er een hele API aan hangt voor allerlei Windows progs.

Dat is wel heel gek, een render engine heeft helemaal niets met een filebrowser van doen, die twee staan helemaal los van elkaar. Sterker nog: khtml, waar webkit op gebaseerd is en dat op zeer veel verschillende OSen draait, was oorspronkelijk ook gewoon onderdeel van konqueror, wat ook een gecombineerde file/webbrowser is die ook nog eens als component in veel verschillende apps kon worden gebruikt. Precies zoals MSHTML dus, en die blijkt dus wel ontzettend portable. Dat er vanalles omheen gebouwd is wil niet zeggen dat de render engine niet portable kan zijn.

Een applicatie ontwikkelen in DirectX kost bv veel minder tijd en moeite (zie ook bv een open source project als MediaPortal), maar porteerbaar is het vervolgens niet.

Ga eens praten met iemand die zowel DirectX als OpenGL heeft gecode en vraag 'm eens wat handiger en makkelijker werkt. En dan is OpenGL nog eens beschikbaar op een hele rij OSen ook.