27 votes4 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
NB While these are Excel object model functions, they aren't VBA functions as they could be used from any language which supports COM.
119 votes32 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
@JamesLee @vinnyjames I think an overhaul of the IDE is not something Microsoft is willing to invest in ATM. However, if MS would be willing to provide a language server, any editor (VS Code, Atom, Visual Studio, Eclipse, etc.) could theoretically be used to write VBA code.
Fortunately, the Rubberduck community have started work on a VBA language server (https://github.com/rubberduck-vba/Rubberduck/issues/5176) using the Rubberduck parsing engine, so we won't have to wait on MS for that either.
> it's quite frustrating to have to use the much more limited language of VBA
What specific language features do you feel are missing from VBA? Not editor features, because that is the subject of this suggestion. The only language feature / API I miss very strongly is functional data processing, which would require 1) first-class functions, and possibly 2) generics.
> much harder to manage than it should be with Excel's VBA editor
Again, does this reflect the limitations of VBA? Or is this because of the ancientness of the VBA editor?
The litmus test would be to use http://rubberduckvba.com, which is an active addin for VBA dedicated to adding features to the editor.
> translate 90% of VBA scripts to VB.NET
What would VB.NET bring to the table that you don't already have in VBA? It would only increase the complexity of what is a very simple use case -- scripts that manipulate Office application objects embedded inside Office documents.
> I hear you saying we need a VBA.net.
I think the only changes to VBA which would add significant value, would be 1) access to the .NET framework, and 2) functions as first-class-citizens, which would enable LINQ-style data processing.
> when you have processors with 8 cores 16 threads and there you have a language which is single threaded.
In order to use that power, you need a language which introduces significantly more complex paradigms. Just like it doesn't make sense for virtually all LOB applications to be written in assembly, in spite of the greater power and flexibility this would offer; the use case for VBA usually doesn't require the performance efficiency that multithreading would bring.
> why anyone would complain about VBA and suggest that JS is a viable replacement
> It makes far more sense for the official language to be VB.NET as this is the rightful heir to VBA7.
And yet, after nearly 20 years, VBA has not been replaced with VB.NET, because VB.NET is still not a drop-in replacement for VBA. Programming in VBA is a simple matter of opening the editor writing code, and saving the file; the code is now part of the document. Providing embedded VB.NET code in an Office document, or via an Office add-in, is an order of magnitude more complicated/
But again, the point here is not "what should the official language be?", but rather making it possible for **any** language to be embedded in an Office document and to make use of the application's API, and providing a unified editor experience via VS Code.
> But VB.NET is a must since it will be much more similar to VBA and allow porting of macros more easily.
VB.NET is far closer (though not entirely so -- https://anthonydgreen.net/2019/02/12/exhausting-list-of-differences-between-vb-net-c/) to C# than VBA. There may be some superficial resemblance in syntax between VBA and VB.NET, but a language is far more that its' syntax.
> allow porting of macros more easily
... which is why there are a number of code translators between C# and VB.NET, because that is a far simpler problem than translating between VBA and VB.NET.
@Conan Keep in mind the use case for VBA -- it is designed to augment either an Office document, or an instance of Office. It's not meant to be a full-blown language / environment for standalone programs. Also, because VBA has a relatively long history, and has been adopted in enterprise environments, it is very difficult to divert resources to new features, while ensuring backward compatibilty with all this legacy code.
Asynchronicity does introduce a certain level of complexity, and in virtually all cases is not needed for the VBA use case.
Framework support would be nice, but not as necessary.
Callbacks would be a very welcome addition, as they would enable a functional style of data processing. I think it's a resource issue.
Note that @Mathieu Guindon is quite familiar with C#, WPF, and .NET, as he is the maintainer of Rubberduck, an VBA addin written in C# which adds a number of useful features to the VBA IDE.
Also note that the main point of this proposal is NOT multiple language support against the Office object model (which if you don't want to embed in a document, is quite possible and straightforward). The primary point here is that the VBA editor+debugger is rather bare-bones, and since Microsoft does not seem willing at this point to invest resources in improving the editor, and extending the editor currently requires a deep knowledge of COM and creating COM addins, VS Code seems to me like a viable alternative.
I want to emphasize that I greatly appreciate -- and benefit personally -- from your tremendous efforts towards dragging the VBA IDE kicking and screaming into the current century. Rubberduck;s many features fill a tremendous hole in VBA development.
It certainly would not be "simple" to integrate VS Code into Office; I've listed 4 points (1-2, 4-5) which a possible VS Code extension would have to provide, in order for it to be on par with what exists in the VBA editor today.
But considering VS Code's flexibility and versatility, and the relative ease with which extensions can be written for it, I think there might be value in such an integration. Case in point -- if the language processing parts of Rubberduck could be separated from UI parts, it could be run in a separate process, working as a language server.Zev Spitz shared this idea ·
45 votes11 comments · Excel for Windows (Desktop Application) » Other · Flag idea as inappropriate… · Admin →
6 votes3 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
6 votes1 comment · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
5 votes3 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
VS Code already supports this; vote here (https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/20010145-integrate-vs-code-into-excel-at-the-same-level-as) for integrating VS Code into Excel.
236 votes14 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
Visual Studio is probably a bit heavy for this purpose, but maybe VS Code? (https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/20010145-integrate-vs-code-into-excel-at-the-same-level-as)
6,338 votes447 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
Thank you to all those participated in our survey. What an amazing number of responses, many of them with very deep content. We’re processing the over ten thousand responses(!), and already appreciate the time so many of you took to answer with passion and experience.
Please know this survey is used to help influence various topics – both on Python as well as other related topics that the comments started to bleed into. Given the passion, I want to be clear this remains an area of exploration for us, without any specific timeline.
We’ll provide updates as we progress on this feature request.
Lead Program Manager
Do we have to choose? Integrate Excel with VS Code (https://excel.uservoice.com/forums/304921-excel-for-windows-desktop-application/suggestions/20010145-integrate-vs-code-into-excel-at-the-same-level-as) and use both.
(Not familiar with R). I support this idea for (if nothing else) Python's lambda expressions, which enable a succinct style of data processing (think LINQ) than requiring multiple nested For/For Each loops in VBA.
How would the editor/debugging experience work? Must Office also have an embedded Python IDE, like the VBA IDE? I know Visual Studio Code supports debugging Python via an extension, so it should be possible to debug with an external IDE.
Would Python support be enabled for other Microsoft Office programs as well?
I understand the intention is to either 1) allow Python programs to be embedded inside Excel documents, or 2) allow Python programs to be hosted by the Excel application. Or both. What about security implications?
10 votes15 comments · Excel for Windows (Desktop Application) » Macros and Add-ins · Flag idea as inappropriate… · Admin →
1,3) Python can access the same COM API as VBA can, via win32com.
2) Whatever version of Python is installed on the user's system, with an option in the Office options dialog to specify the path to the Python interpreter. Presumably the first time a user tries to open a file with embedded Python code, or execute a Python script, Excel (or whatever application) would prompt for the location of the interpreter.
4) I think the primary benefit of Python-as-an-embedded-scripting-language is not in performance, but rather in the higher-level abstractions. Specifically, because Python has a function-as-first-class-object mechanism, it enables a more succinct style of data processing (think LINQ).