Hieronder een samenvatting (wellicht niet eens volledig) van de belangrijkste beperkingen van de VBE voor Excel op Mac.

Voor de meeste van deze beperkingen is er tot op heden geen bruikbare oplossing of “workaround” op Mac (en het ziet er niet naar uit dat die beperkingen gaan weggenomen worden door Microsoft).

Voor sommige beperkingen (zoals bijvoorbeeld “Application Events”) is het mogelijk om een en ander zelf handmatig uit te schrijven, maar de kans op fouten is dan erg groot.

De beste manier om deze beperkingen te omzeilen is helaas om het VBA ontwikkelingswerk te doen op een Windows-versie van Excel (ik gebruik daarvoor een Virtuele Machine van Parallels Desktop, die Windows 11 draait op mijn Mac).

Tenzij specifiek vermeld werkt de resulterende code wel op Mac eens die is ontwikkeld.

Beperkingen:

• Op Mac is het niet mogelijk om een Userform in VBA te designen en daar de lay-out en de plaatsing van “controls” op te doen. Het is wel mogelijk om de code van een Userform te schrijven, en Userforms die in Windows gemaakt zijn, werken ook op een Mac.
  In deze context heb ik wel al geobserveerd dat voor Userforms waarbij de controls (labels, listboxes, …) vanuit VBA worden ingevuld het af en toe gebeurt dat op Mac de namen van de elementen van een Userform verloren gaan (overschreven worden door de default-naam), waardoor het Userform in kwestie resulteert in foutmeldingen. Dit “gedrag” is echter te onvoorspelbaar gebleken om een juiste oorzaak te achterhalen en te herstellen.
• Dictionary Objects bestaan in het Excel object model op de Mac NIET. Om met Dictionaries te werken, is het dus nodig om zelf met behulp van eigen Classes de Dictionary in kwestie “na te bootsen”, wat nogal specifieke en complexe code betekent. Dit is een van de gevallen waarin een “conditional compilation” in de VBA-code nuttig is (“#If Mac Then … #Else … #End If”), zodat bij uitvoering van de code nog vóór de compilatie kan nagekeken worden of het onderliggende OS Windows of Mac is en zo compilatiefouten vermeden worden. In geval de code draait op Windows kan zo alsnog gebruik gemaakt worden van de standaard ingebouwde Dictionary Objects die daar WEL beschikbaar zijn.
• Application Events zijn erg nuttig om bijvoorbeeld workbook- of worksheet-events (zoals een dubbel-klik) te onderscheppen in een andere workbook dan die waar de code zich bevindt (bv. in een Add-in kan je zo een dubbelklik in gelijk welke actieve Workbook onderscheppen). Om Application Events te kunnen onderscheppen, is een vrij eenvoudige toevoeging van een specifieke Class Module in het VBA-project nodig, waarna het Application Object Model toegankelijk wordt. Alleen … de VBE voor Mac maakt het niet mogelijk om dat Object Model op een bruikbare manier te benaderen (alle details van de te schrijven syntax moeten manueel worden ingebracht zonder enige hulp bij het opsporen van fouten door de VBE, zoals dat WEL in de Windows-versie mogelijk is.

De meeste VBA ontwikkelaars schrijven daarom hun toepassingen in Windows, en heel vaak zelfs op een manier waardoor die toepassingen ook alleen echt bruikbaar zijn in Windows. Het vraagt extra inspanningen om een VBA-toepassing “cross-platform” bruikbaar te maken (bv. een Add-in die zowel op Mac als op Windows draait). Of die extra inspanningen de moeite waard zijn, hangt af van het doelpubliek … als alle potentiële gebruikers van Uw VBA-toepassing zich op hetzelfde platform bevinden, dan is “cross-platform” development niet echt nuttig.