Feedback by UserVoice

Mathieu Guindon

My feedback

  1. 42 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon supported this idea  · 
  2. 118 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon supported this idea  · 
  3. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon commented  · 

    Until this is fixed, you can ensure consistent behavior between different host bitness by avoiding member calls against an object whose reference isn't held in the current scope.
    IOW declare a local object variable, assign it to the factory method's result, *then* make the member calls against the local variable - chaining member calls directly against the factory method (i.e. any method that returns an object defined by a user class) can cause this undefined behavior; the Terminate handler is a red herring, the problem is that the object is out of scope and the reference count is off (in x64) because of this.
    Rubberduck will implement an inspection to flag instances of this: https://github.com/rubberduck-vba/Rubberduck/issues/4442

    Mathieu Guindon supported this idea  · 
  4. 114 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon commented  · 

    Isn't VSCode open-source? If it's so simple then why isn't it done already? There's a reason it's not done and never will be... Killing off VBA cannot happen, and good luck reimplementing VBA - Rubberduck's parser is 99% there and still doesn't handle every edge case. Your best bet is to contribute to OSS that enhances the VBE such as Rubberduck (written in C#7), or contribute to VSCode itself... I don't get the "dear lord" comment here, corporate VBA folks love VBA and won't trade it for JavaScript or Python anytime soon. Enhancing the existing toolset ecosystem is a much more sane way to improve things IMO.

  5. 5 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon commented  · 

    Rubberduck enhances VBE's navigational capabilities already, and as of the last few pre-release builds also massively enhances auto-completion in the editor, not to mention all the other features, from unit testing to refactorings and static code analysis.

  6. 54 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon supported this idea  · 
  7. 331 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon supported this idea  · 
  8. 230 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Mathieu Guindon commented  · 

    Hi there,

    I own rubberduckvba.com and manage the Rubberduck open-source VBIDE add-in project.

    There are a couple of problems with this feature request: it's conflating VBA (the language) with the VBE (the editor).

    Getting VBA "fully integrated" in Visual Studio isn't going to fly, for many reasons. First, a parser would need to be written from scratch for Roslyn to work with it (VB.NET syntax trees can't work with VBA). Then the language would need to be built from the ground up with Roslyn. This is a tremendously complex task, with little to no benefit at all. The COM libraries (including the VBA standard library) would have to be ported over to the .NET world, which is another enourmous task, with real possibilities to introduce subtle bugs literally everywhere. The quirks of the language would have to be replicated in Roslyn too, so as to not break billions of lines of code that are working fine in COM-based VBA land.

    Moreover, VBA developers don't want to use Visual Studio. Most VBA developers aren't programmers. They're financial or marketing analysts, merchandise planners, whatever: forcing them onto Visual Studio would be a massive problem: the full-featured-ness of VS would be playing against it, people familiar with the VBE would be completely lost. So not only integrating VBA in Visual Studio would be a technical near-impossibility, it very likely wouldn't get the buy-in from its target audience.

    VBA isn't inherently tied to Office, either: there are well over 200 3rd-party applications that used the SDK to integrate VBA in their applications. Sage ERP, SolidWorks, Corel DRAW, AutoCAD, to name a few. Integrating VBA into Visual Studio would wreck these.

    There is definitely room for improvement though: as I said, I manage the Rubberduck OSS project, and our goal is literally to bring the VBE into this century and, actually, provide a solid answer to "stage 1" above, making the VBE on-par with modern IDE's. "stage 3" is unrealistic because of "stage 2" being pretty doomed. So that leaves "stage 1", which isn't about updating VBA at all, but about updating the VBE: people hate the editor, not necessarily the language.

    If the VBIDE API was easier to work with, especially through managed COM interop (i.e. extended from C#/.NET). Improving the VBIDE extensibility library would go a long way towards helping 3rd-parties such as the Rubberduck project, achieve this goal of modernizing the VBE.

    Ideas:

    - Expose code pane events. One of the most frustrating thing with the VBIDE API is that it's impossible to tell exactly when code is being modified, at least without subclassing the editor or capturing keypresses, which destabilizes the host process. Or...
    - Expose annotated parse/syntax trees. Rubberduck needed to implement its own parser and resolver off the VBA language specifications in order to pull its prowesses. This has been a daunting task, and while we're 99% there, that 1% is really, really tricky.
    - Expose project properties on `VBProject`. It's currently impossible to know anything about project properties without physically bringing up the properties dialog and implementing some nasty p/invoke to grab textbox values, e.g. to pick up project-wide precompiler constants.
    - Expose module and member attributes through the CodeModule API. It's currently impossible to pick up these very important values (let alone modify them) without physically exporting the code file and re-importing it back in.
    - Fix the annoying bug that inserts an extraneous empty line when re-importing a UserForm. Rubberduck is working around it, but we shouldn't be needing to do this.

    IMO that would be more realistically feasible than anything else mentioned on this page, and it would have very impactful effects on the ability of 3rd-parties to seamlessly integrate with the VBE.

    Regards,
    Mathieu

  9. 254 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    Thanks for the suggestion Nick. We’ve got some related work we’re looking at soon, and we’ll be sure to carefully consider if we can get a fix in for this then. As always, more votes helps – so keep voting for the things you care about most.

    Thanks,
    John [MS XL]

    Mathieu Guindon supported this idea  · 
  10. 2 votes
    Sign in
    (thinking…)
    Sign in with: Facebook Google
    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Excel for Mac » Macros and Add-ins  ·  Flag idea as inappropriate…  ·  Admin →
    Mathieu Guindon shared this idea  · 

Feedback and Knowledge Base