Bringing back Visual Basic IDE to Office for Mac

That is really good news. This was the only down side to my move from Windows to Mac when I retired. I have had to keep an old Windows laptop working just to maintain my existing Excel file / tools that occasionally require updating and that involves macro development work.

My IMac 27" screen has just failed (luckily within a 3-year warranty so is currently being fixed) but this was enough for me to reconsider my move to MacOS and get a new Windows10 laptop so at least my Excel will be fully usable again.

I will wait a bit longer and keep my fingers crossed that a fully functioning VBA editor is on its way as generally I have been very happy with the move to a Mac and MacOS (although my wife has a new DellXPS Windows 10 laptop, and hardware and particularly the new Windows have definitely brought things closer to the Apple experience).

I'm happy this day is an important day for me.

I'm using a lot of macros and VBA module in my excel since 2003, so it's necessary to have this on my mac notebook.

Finally, I can leave at home my oldest notebook with windows that I use only to edit the macro.

To use the virtual machine for this was another opportunity but, asks too much resource on my mac to be used. 

Many thanks and many thanks also for all the improvements done since today on the VBA functions in MAC. One for all, the not monomodale property for the forms.

Roberto

Very good news for all Office 365 users on macOS! 👍

Will be there some information about possible compatibility problems between Office for macOS and Office for Windows? Will VBA on macOS support everything what VBA on Windows can do?

I hope MS will extend their support/development for even more Office features like Pivot Charts that are still not available on Office 365 for macOS.☹️

Keep going and thank you for VBA on macOS 👍

Good news.

The question I have is will Visual Basic in Excel for Mac for the full 100% as functional as in Windows (macros, connections with MSSQL, etc.), so that my developed tools in  Windows Excel can finally be used by Mac users?

Carlo

You will get to try it very soon, as indicated.

There was a problem when using ODBC as a data source for a PivotTable. This was fixed last December. This is something to test.

There is a known major blocking error. This code fails in the current crappy VBE:

With ActiveWorkbook.Connections("ConnectionName").ODBCConnection
.CommandText = stSQL1
End With

Currently there is not a programmatic way to initiate a connection. It is unknown whether this blocking issue has been addressed in the new VBE. My hunch is that it has not. If you join Insider Fast and can test this scenario, please do and file reports against it if it has not yet been fixed. However, if the connection exists, you should be able to program the resulting querytable using the reduced command set in Office for Mac:

http://www.agentjim.com/MVP/Excel/2011Relational9Queries.html

From Schweib's description, will be able display userforms in this first edition, but we won't be able to actually edit their controls in the interface for a while.

Hi all,

I see lots of questions about object model parity between Mac and Windows versions of Office. The object model is completely independent from the IDE and thus is not part of this particular effort to revisit the IDE. The object model depends on having the actual features supported in the app, whereas the IDE is a separate feature that allows you to browse, edit, and deploy code that uses the object model that currently exists (and may change over time) in the apps. For example, Mac Excel does not yet have OM support for Pivot Charts because the app does not have an implementation of Pivot Charts to begin with, but if Mac Excel gains the Pivot Chart feature it should also gain Pivot Chart object model support.

Each app team is keenly aware of the feature differences between the Mac and Windows versions. There is a separate effort underway to greatly improve the code convergence between the Mac and Windows apps, and that will make it much easier to achieve feature parity. Due to OS and platform differences, the apps will likely never have precisely matching features and abilities (such as the security restrictions of the Sandbox on the Mac that constrain feature behavior). Stay tuned for separate Insider discussions on app feature and object model convergence!

On a side note, I will be offline for vacation for the next two weeks and will follow up on any IDE-specific questions when I return. To Jim's point above, Forms will continue to run as part of macros as we roll out the new IDE; it's just that the new IDE will not yet support editing existing or creating new Forms when we first release it. We will add that support in the future.

Schwieb

Hi Schwieb,

When it comes to something like being unable to make a connection via VBA, it's hard for us on the outside to know whether that's an IDE problem or an Object Model problem.

Regarding making a data connection, clearly, a new connection can be made using the interface, so Connection is working as part of the application. The IDE understands, but can not execute, the correct syntax. The failure seems to be in the communication between the IDE and the Object Model. Is the Object Model at fault or is it the IDE? Over here developer land, we can't know. All we can do is alert you to the error and hope that it gets resolved wherever it lies.

The IDE edits (and test-compiles) the code.  The app runs it. 

If the code doesn't work right, crashes or tosses errors, it's a problem with the code or with the OM or its implementation, not the IDE.