Coffeehouse Thread

11 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

why excel vba != .NET?

Back to Forum: Coffeehouse
  • User profile image
    SteveRichter

    Slightly with the question of how commited is MSFT to .NET, what is the reason for excel not having a VBA based on .NET? Is there a new office beyond 2010?  Does it have a better automation story than the prior versions?  Please correct my understanding of Excel automation, but I find VBA simply terrible to use. And considering the number of business people who use excel it seems like a great waste of programming possibilities.

     

  • User profile image
    DCMonkey

    Because nobody wants to re-write all of those crufty Excel macros in .Net?

    Because MS decided that distributing executable code in a document file was perhaps a bad idea security wise and decided to go with a different model with VSTO.

    Because there is VSTO.

    Because HTML5 and JavaScript are the new hotness, therefore there is also "Apps for Office 2013".

     

  • User profile image
    spivonious

    @SteveRichter: I don't really have a problem with VBA. It's extremely similar to VB6, which is one of the most popular Windows programming platforms even today.

    MS leaves it in there for backwards compatibility. Look at VSTO/Apps for Office 2013 for new projects.

  • User profile image
    SteveRichter

    , DCMonkey wrote

    Because MS decided that distributing executable code in a document file was perhaps a bad idea security wise and decided to go with a different model with VSTO.

     

    I don't follow why there cannot be a sandbox framework that would limit which methods, classes and assemblies could be used from a VBA.NET.

  • User profile image
    SteveRichter

    , spivonious wrote

    MS leaves it in there for backwards compatibility. Look at VSTO/Apps for Office 2013 for new projects.

    my only problem with VSTO is it seems to take programming away from the end user. But I should learn it.

     

  • User profile image
    magicalclick

    They are still making their own C# Interpreted Language I suppose.

    Leaving WM on 5/2018 if no apps, no dedicated billboards where I drive, no Store name.
    Last modified
  • User profile image
    Sven Groot

    VBA wouldn't be too bad if the IDE wasn't still exactly the way it was in VB6 (even in Office 2013).

    Certain behaviors, like the modal dialog for a syntax error whenever you move your cursor away from a line that has an error on it, are just extremely annoying. Another pet peeve is the way the editor capitalizes names based on declarations. If I declare a variable named "width" (without capitals), then any reference to e.g. a property named Width in the same function will automatically be cased like my variable rather than the proper casing for the property. Since VBA is case-insensitive it doesn't affect functionality, but it looks messy.

    The editor's UI also looks really incongruous in recent versions of Office.

    VSTO and stuff are nice, but if I quickly need to move all graphs ten points to the left or something, it's much easier to quickly write some one-time-use code in VBA, so I'd really appreciate it if they gave the editor some love.

  • User profile image
    AndyC

    @SteveRichter: VBA exists now solely for backwards compatibility. It's a horrendously crufty language, with almost as many quirks as the actual Office Object Model itself. VSTO was an attempt to somewhat modernize things by encouraging people who were currently building horribly overcomplicated applications in VBA (I know this pain, I have to work on one from time to time!) to something closer to .NET development, but it never really took off fully. I think that is not insignificantly down to the fact the Office automation is horribly flaky, so it's borderline impossible to actually build a robust solution on it, regardless of the language.

    The new kid on the block is the Javascript-based Office plug in app things. They're a little more constrained in what they can theoretically do, but they should at least work in a reliable way (and transistion to an Office 365 arrangement rather more seamlessly).

  • User profile image
    evildictait​or

    You need to get your history right.

    VBA existed in Excel long before .NET even existed.

  • User profile image
    spivonious

    , Sven Groot wrote

    VBA wouldn't be too bad if the IDE wasn't still exactly the way it was in VB6 (even in Office 2013).

    Certain behaviors, like the modal dialog for a syntax error whenever you move your cursor away from a line that has an error on it, are just extremely annoying. Another pet peeve is the way the editor capitalizes names based on declarations. If I declare a variable named "width" (without capitals), then any reference to e.g. a property named Width in the same function will automatically be cased like my variable rather than the proper casing for the property. Since VBA is case-insensitive it doesn't affect functionality, but it looks messy.

    The editor's UI also looks really incongruous in recent versions of Office.

    VSTO and stuff are nice, but if I quickly need to move all graphs ten points to the left or something, it's much easier to quickly write some one-time-use code in VBA, so I'd really appreciate it if they gave the editor some love.

    You can stop that modal popup by going to Tools->Options and unchecking "Auto Syntax Check". It would be nice if they updated the editor. It's not even up to par with VB6; it's more like VB4's IDE.

  • User profile image
    contextfree`

    , AndyC wrote

    @SteveRichter: VBA exists now solely for backwards compatibility. It's a horrendously crufty language, with almost as many quirks as the actual Office Object Model itself. VSTO was an attempt to somewhat modernize things by encouraging people who were currently building horribly overcomplicated applications in VBA (I know this pain, I have to work on one from time to time!) to something closer to .NET development, but it never really took off fully. I think that is not insignificantly down to the fact the Office automation is horribly flaky, so it's borderline impossible to actually build a robust solution on it, regardless of the language.

    Yeah, the flakiness is what always killed it for me ... all the Office automation stuff I've built had to include a lot of "if operation foo randomly fails, retry a few times and then try fallback solution XYZ" sort of logic. It felt like a nondeterministic environment, and maybe if I had a deeper understanding it wouldn't anymore, but there never seemed to be any clear path to get one (other than join the Office team and get access to the code ...)

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.