SirJB7
Excel Rōnin
Hi, all!
Having tried a bit version 2013 a year ago I decided to keep using 2010 version. Now due to certain wonderful functions like WEBSERVICE I admitted that it was time to move on and upgrade, even if I didn't like the new version too much. World evolves, sometimes not towards where you'd have liked to, but it evolves, so following the advice of evolution theory's father (aka Charles, aka Darwin) I evolved.
After a few days of intensive use, I think I dislike absolutely 2013 version, and I'm not talking about the flat interface, the big fonts, the animations, and all that stuff tablet / touch oriented. The main point is the help feature, by default to online help switchable to local help but only for Excel and not for VBA.
Even Mocosoft (Spanish jargon, in English it'd be Mucus instead of Moco) published a year after the release date!!! (09/10/2013 as Hui posted http://chandoo.org/forum/threads/vba-documentation.12502/ vs. 25/10/2012), the standalone or offline VBA documentation in form of .chm help files, these points look unadmittable in my opinion:
a) Only English version, which I wouldn't care (but not many other people) if the following points were solved
b) There's no integration with the "?" icon nor the F1 key
c) The reference isn't clearly a VBA reference but to an "integrated" Office reference with SDK, API and other languages reference:
- slightly biased to Apps for Office and SharePoint
- not VBA mention in Build Apps for Office but yes to HTML5, JavaScript, CSS3, and XML:
http://msdn.microsoft.com/en-us/library/office/jj220060.aspx
- cropped access to enum values, i.e., I click on .Type, press F1, I'm led to .Type help/documentation, but I have no access to its enum values
- subtle intent to make people move to Office.365 and Napa framework
- unveiled invitation to stop using and developing in VBA and start with Apps for Office:
http://msdn.microsoft.com/en-us/office/ff688774.aspx
"Which technology―VBA macros, managed add-ins built with Visual Studio, or apps for Office―is the best choice for your solution? It's important to note that all three technologies will be supported in the foreseeable future (1). This means that if you have an existing VBA project that you are satisfied with, you can be confident your investment is safe (2). However, if you're looking for a new way for users to interact with Office customizations, apps for Office is a great place to start (3)."
Bold is mine, (n) too.
MS has a particularly intricate and DO (deliberately obfuscated) language usage, that it uses like politicians: not to say what they should and are asked to, and to say what they couldn't openly do and are not wanted to. So let me give my translation:
(1) We don't have other choice to keep VBA alive for the time being, but we intend to cease it support asap.
(2) As safer as if you've continued using '97 version with macro sheets, or don't they work today? Read as: keep on using older versions like 2010, which will be discontinued at our 1st chance.
(3) Did we make ourselves clear? Use Apps for Office, stupid.
In other products like Visual Studio .NET, MS has done something similar:
Up to 2003 or 2005 (I don't remember now exactly) version, DAO (direct access objects) was the standard and then ADO (active X data objects) become "the" solution. In next version they introduced LINQ and in the documentation ADO isn't mentioned unless no other choice (BTW, LINQ was a failure like WinMe or WinVista or Win8.0). In next version, LINQ still mentioned but just a little, taking its place now "the ultimate" solution: EF (entity framework). Who knows what destiny reserve for next version? Not even Redmond guys, IMHO.
But what happened in the real world? People still use ADO (and less but DAO too) as it's the most widely spread and proved solution. Those who moved to LINQ wish that they hadn't. Only new developments with no ADO legacy are done with EF, which in fact it's the future. And today we all should be migrating ADO and LINQ to EF, since in the near future it'll become the new actual standard. Unless and until a new XYZW appears. But as world evolves, software evolves, thus we should follow world evolution but not software evolution until it proved stable.
Therefore MS would have killed and eliminated VBA, if they could have done so. But like ADO it resist and it's generally "the" choice. Like ADO in VS.NET documentation it has been almost buried and explicitly omitted in 2013 version. And like ADO it'll come the day when EF or Apps for Office (or whatever the name or initials would be) would have evolved enough to become the most practical and recommendable choice.
So my conclusion and advice is this: start learning Apps for Office while you keep maintaining VBA, in new projects try to apply the new kid of the block and check how it behaves; if you don't like it, switch back to the old known and postpone the new to know until... next version?
As very comfortable with VBA for many (I don't want to count how many) years, I'm beginning to say good bye to VBA and welcome to Apps for Office. As I'm doing with ADO and EF (thankfully I decided to skip LINQ). It looks to me a lot like MS Messenger and Skype with MS email accounts: messenger was wonderful but they let it die and replaced with skype which isn't as wonderful but sometimes almost unbearable. But it's what we've left to deal with. And evolution is about it: adapt to the changes. It's up to us to choose to which ones we'll try to adapt to, surely not to all.
Despite of this, my dislike of Excel 2013 version isn't related at all to the VBA death foretold (thanks to Gabo for that literature gem, Crónica de una muerte anunciada, Gabriel García Márzquez). It's just because of my first impressions regarding its use and the differences versus 2010 version, where the help features have a great relative weight.
Regards!
Having tried a bit version 2013 a year ago I decided to keep using 2010 version. Now due to certain wonderful functions like WEBSERVICE I admitted that it was time to move on and upgrade, even if I didn't like the new version too much. World evolves, sometimes not towards where you'd have liked to, but it evolves, so following the advice of evolution theory's father (aka Charles, aka Darwin) I evolved.
After a few days of intensive use, I think I dislike absolutely 2013 version, and I'm not talking about the flat interface, the big fonts, the animations, and all that stuff tablet / touch oriented. The main point is the help feature, by default to online help switchable to local help but only for Excel and not for VBA.
Even Mocosoft (Spanish jargon, in English it'd be Mucus instead of Moco) published a year after the release date!!! (09/10/2013 as Hui posted http://chandoo.org/forum/threads/vba-documentation.12502/ vs. 25/10/2012), the standalone or offline VBA documentation in form of .chm help files, these points look unadmittable in my opinion:
a) Only English version, which I wouldn't care (but not many other people) if the following points were solved
b) There's no integration with the "?" icon nor the F1 key
c) The reference isn't clearly a VBA reference but to an "integrated" Office reference with SDK, API and other languages reference:
- slightly biased to Apps for Office and SharePoint
- not VBA mention in Build Apps for Office but yes to HTML5, JavaScript, CSS3, and XML:
http://msdn.microsoft.com/en-us/library/office/jj220060.aspx
- cropped access to enum values, i.e., I click on .Type, press F1, I'm led to .Type help/documentation, but I have no access to its enum values
- subtle intent to make people move to Office.365 and Napa framework
- unveiled invitation to stop using and developing in VBA and start with Apps for Office:
http://msdn.microsoft.com/en-us/office/ff688774.aspx
"Which technology―VBA macros, managed add-ins built with Visual Studio, or apps for Office―is the best choice for your solution? It's important to note that all three technologies will be supported in the foreseeable future (1). This means that if you have an existing VBA project that you are satisfied with, you can be confident your investment is safe (2). However, if you're looking for a new way for users to interact with Office customizations, apps for Office is a great place to start (3)."
Bold is mine, (n) too.
MS has a particularly intricate and DO (deliberately obfuscated) language usage, that it uses like politicians: not to say what they should and are asked to, and to say what they couldn't openly do and are not wanted to. So let me give my translation:
(1) We don't have other choice to keep VBA alive for the time being, but we intend to cease it support asap.
(2) As safer as if you've continued using '97 version with macro sheets, or don't they work today? Read as: keep on using older versions like 2010, which will be discontinued at our 1st chance.
(3) Did we make ourselves clear? Use Apps for Office, stupid.
In other products like Visual Studio .NET, MS has done something similar:
Up to 2003 or 2005 (I don't remember now exactly) version, DAO (direct access objects) was the standard and then ADO (active X data objects) become "the" solution. In next version they introduced LINQ and in the documentation ADO isn't mentioned unless no other choice (BTW, LINQ was a failure like WinMe or WinVista or Win8.0). In next version, LINQ still mentioned but just a little, taking its place now "the ultimate" solution: EF (entity framework). Who knows what destiny reserve for next version? Not even Redmond guys, IMHO.
But what happened in the real world? People still use ADO (and less but DAO too) as it's the most widely spread and proved solution. Those who moved to LINQ wish that they hadn't. Only new developments with no ADO legacy are done with EF, which in fact it's the future. And today we all should be migrating ADO and LINQ to EF, since in the near future it'll become the new actual standard. Unless and until a new XYZW appears. But as world evolves, software evolves, thus we should follow world evolution but not software evolution until it proved stable.
Therefore MS would have killed and eliminated VBA, if they could have done so. But like ADO it resist and it's generally "the" choice. Like ADO in VS.NET documentation it has been almost buried and explicitly omitted in 2013 version. And like ADO it'll come the day when EF or Apps for Office (or whatever the name or initials would be) would have evolved enough to become the most practical and recommendable choice.
So my conclusion and advice is this: start learning Apps for Office while you keep maintaining VBA, in new projects try to apply the new kid of the block and check how it behaves; if you don't like it, switch back to the old known and postpone the new to know until... next version?
As very comfortable with VBA for many (I don't want to count how many) years, I'm beginning to say good bye to VBA and welcome to Apps for Office. As I'm doing with ADO and EF (thankfully I decided to skip LINQ). It looks to me a lot like MS Messenger and Skype with MS email accounts: messenger was wonderful but they let it die and replaced with skype which isn't as wonderful but sometimes almost unbearable. But it's what we've left to deal with. And evolution is about it: adapt to the changes. It's up to us to choose to which ones we'll try to adapt to, surely not to all.
Despite of this, my dislike of Excel 2013 version isn't related at all to the VBA death foretold (thanks to Gabo for that literature gem, Crónica de una muerte anunciada, Gabriel García Márzquez). It's just because of my first impressions regarding its use and the differences versus 2010 version, where the help features have a great relative weight.
Regards!
Last edited:
