Vba, R.i.p?

Re: Vba, R.i.p?

VBA still exists and will do so for some time. Many companies including some larger ones will not upgrade to 2007 for some time.

Note: I am moving this to the Lounge

Re: Vba, R.i.p?

Quote from lingyai

I was blown away by the response of a pretty knowledgeable friend of mine to the question of whether anything I learn about VBA now will be rendered obsolete by Excel 2007.

That is not really correct, but I do understand where your friend is coming from..... Excel 2007 will still support VBA. MSFT have said that VBA will not be developed any further though, so you will not see the addition of any new functionality, and the ability to "customise" the UI of 2007 will certainly not be as easy and virtually impossible just using just VBA..

Having said that, there are already many examples of Ribbon customisation hitting the 'Net (using XML mainly) and so all is not lost.

What is true is that to get the best of Office 2007, you will need to embrace a new set of skills, namely Visual Studio Tools for Office (VSTO) and if you're brave, XML. You'll also need to work with the software and "embrace" the changes as there are amazing new functionalities included as standard that we used to have to add via VBA. These functionalities, whilst they are still possible to do with VBA, are effectively not necessary... examples that spring to mind are getting around the old conditional formatting limits and sorting by cell background color.

So in some ways your friend is correct in that he's advising you to be prepared to learn new languages and skills, but he is wrong in his statement that VBA is "obselete". It's just that is won't be as necessary if you use the new tool's built in functionality correctly & to the full extent.

Personally, I've been using Office 12 since beta 1 and I just love it to bits. Given the work that I do is mostly interfacing with SQL databases, the interation with back-end database servers is absulutely superb. The UI (Ribbon) does take some getting used to, however I now find it far more intuitive and get more frustrated with Office 2003's clunky interface when I have to use it.

If you're going there, you'd be wise to read David Gainers blog and start checking out the "guru" sites for some excellent new techniques, and remember this....

"If all you do is what you know, you'll never grow"

Re: Vba, R.i.p?

Will, thank you for the clear explanation.

Re: Vba, R.i.p?

Eh, doesn't Excel still support Excel4 macros and dialog sheets?

As far as I know they date back to 1995 (or earlier).

So while I understand that VBA may be on the way out and/or not going
to be given the same support in the future I seriously doubt it's just
going to be dropped.:)

Oh and Excel still supports Auto_Open.:confused:

Re: Vba, R.i.p?

Whilst the VBA language may not be moving forward the Object Model is, although admittedly it is batchy
So in theory new excel features will be exposed to VBA.

It really depends why you are using code.
Professional developer selling addins or working at a corporate level then VSTO is the way to go. And don't forget this route offers more than 1 language. In fact I would suggest that if you are learning a language choose C#.

Writing addin or code for single instance use then VBA or VSTO are valid.

Simple repetitive 'MARCO' usage VBA. Using VSTO is overkill IMHO.

If you consider that XLM code is still suppported you can see that VBA still has life for a long time to come.

Re: Vba, R.i.p?

My understanding is that for the Macintosh version Office 2008, VBA will not be supported. Moreover, I believe there will be no replacement for it beyond the more general Applescript. Microsoft's announced reasoning is it is too hard to make the conversion of the clunky Mac version of VBA to the more modern coding basis Office will be using.

Re: Vba, R.i.p?

"Personally, I've been using Office 12 since beta 1 and I just love it to bits. Given the work that I do is mostly interfacing with SQL databases, the interation with back-end database servers is absulutely superb."

Awesome! I too, deal with sql databases quite frequently... what specific new stuff have you found thats helped or changed?

Re: Vba, R.i.p?

I work in IT (softWare House) - these programmers with the raw codes use true Windows 32bit applications, the core product is massive. I see VBA around for 10 years before we need to worry even if Microsoft pull Excel for some fang dangled Office Applications, remember the guys that are behind us

Reference
Today I played with a quad 2.66Htz processor (Hyper threaded), 8GB memory running Microsoft Vista 32 Bit Windows, not everyone has that, and its useless to all but testing and learning the rest of the world needs to catch up before standards are set In My Honest Opinion, this is quite normal and a good comparison with the VBA question… no panic here

Also my study is MSCA MCSE so the stuff there has nothing re programming or VBA its related to the on hands Desktop and FileServer Applications, this will not change that fast. Not yet. Also remember Microsoft Windows Xp only supports 4GB memory so VBA is not looking at the axe just yet it cant however look at the multi platform applications for programming is a good idea

jiuk

Re: Vba, R.i.p?

Like to add my 2c worth of ramblings.

I have been using 2007 for a while.

From the front end there is a wealth of new features. Yep that "ribbon" takes some adjusting too. The SQL Server 2005 integration makes it a certain path for me.

On the VBA side, the VBE hasn't changed at all - apart from the colour. The only major difference seems to be that you can not use commandbars. I guess < 5% of VBA users make any use of commandbars and we now have ways of using the ribbon so - a pain but no big deal.

Aside : The 2007 big concern for me is performance and bugs. All my testing shows it to be much slower than 2003.

I have managed to do a bit of Excel programming using VB.NET (thanks to Dennis W for getting me going), but I just do not see the need (yet) for 99% of Excel users. I do need it because I want to take over an Excel object from within a .NET application for reporting but that is not Excel.

So I would say definitely stick with VBA for now. To use .NET (with or without VSTO) requires too much investment in software (Visual Studio) and the learning curve is far too big for the average Excel user who wants to start automating their spreadsheet. One day you will need to use .NET but what you learn in VBA along the way will be relevant, and I think that day will be some years away yet.

That said, I believe the future must be in .NET so for serious MS Office developers I think it is probably time to start learning. As for VB.NET or C#.NET well there is a thousand debates raging on the www for that one.
My own take is that now they will run at the same speed (+/-1%) it doesn't matter which one you use so I focus on VB.NET (VBA roots) but am trying to learn enough C# to be able to read the code if I need to.

Re: Vba, R.i.p?

Andy,

Quote

In fact I would suggest that if you are learning a language choose C#.

You've been listening too much to MSFT : D

C# is more of "plumbing" then what VB.NET ever will be which can either be interpretated as "more flexible and gives more control" or "using C# with Office is like ---".

Developers who's coming from the business side tend to set focus on the business requirements and therefore usually don't pay attention to the detailed underlying plumbing. Developers with a technical background are used to be in control and therefore prefer to use C# when working with the .NET platform.

The good news is that MSFT seems lately to realize that there still exist a great number of developers that prefer VB.NET then C#

Re: Vba, R.i.p?

Hi Dennis,

Not listening exactly, but when it comes to reading, studying and learning the prefered explanation method seems to be C#. And as you point out this is probably due to the examples being provided by the 'plumbers'

I did preface my suggestion with "if you are learning a language..."
So if you already code in VBA/VB then yes stick with VB.Net.

My biggest concern is that whilst MSFT are making things easier for developers they are causing everyday users to question where they fit into MSFT and Offices future.

With xl2007 they may have made it easier to use but it's more difficult to control.

Re: Vba, R.i.p?

Quote

My biggest concern is that whilst MSFT are making things easier for developers they are causing everyday users to question where they fit into MSFT and Offices future.

Easier in terms of :confused:

I'm not 100 % convinced that MSFT actually has made it easier for developers.

Quote

With xl2007 they may have made it easier to use but it's more difficult to control.

I like the RibbonX and as a developer I'm forced to work with it from a different approach then with classic commandbars

Re: Vba, R.i.p?

It easier in terms of the intergration of xl within the VBE. Using drag and drop to construct UIs for instance.

I'm not against the ribbon. But it lacks the ease of integration that is currently available to users via the commandbar object.
My understanding is, and please let me know if I'm wrong, that in order to add a button to the ribbon to run a macro you need to edit xml prior to using/opening the workbook. There is no way to build the button on the fly from within the workbook.

Re: Vba, R.i.p?

Quote

It easier in terms of the intergration of xl within the VBE. Using drag and drop to construct UIs for instance.

Yes, there exist some advantages but they are well "compensated" with new complex stuff.

To deploy .NET-solutions is challenging and with Vista's new security model including User Account Control (UAC) it's at best described as very challenging.

Quote

... that in order to add a button to the ribbon to run a macro you need to edit xml prior to using/opening the workbook. There is no way to build the button on the fly from within the workbook.

One thing we can agree on is the fact that the the Ribbon is here to stay.
We can also fully agree on that it was not the group of developers MSFT had in mind when they designed the new UI.

Initially I didn't like the Ribbon UI at all. However, when I decided to not view it from the experience with classic commandbars I saw the benefits the new UI actually provides.

Creating customized XML files with the RibbonX code may "on its face" look difficult and complext but is both logical and understandable. By implement the IRibbonExtensibility we get the callbacks. It's possible to alter the visibility etc and also via callbacks control what will be done.

The following coming article in MSDN Magazine gives a basic introduction:
Extend The 2007 Office System With Your Own Ribbon Tabs And Controls

Patrick Schmid has a forum dedicated to Ribbon which gives additional knowledge and also the possibility to discuss and raise questions.

Re: Vba, R.i.p?

Just wanted to chime in with my own two cents.

I know that I'll find the transition to the Office 2007 probably frustrating.

Reason 1)
For all intents and purposes my personal use doesn't justify getting the new office everytime it comes out.

Reason 2)
If the company that I work for ever does upgrade to the Office 2007, heck we just updated from 2000 to 2003 and that wasn't even all the computers, I'm sure that new projects would need to be written to accomodate multiple platforms. For that I mean from Win98 thru Vista.

I've had the VST 2005 installed for sometime on my computer but have yet to develop anything because of the wide ranging platforms here. Some may or may not have the Framework installed and seeing how I'm not in the IS department I'd spend alot of time going around just trying to install the framework on all the PC's ( in effect doing someone elses job ) and not getting my own job accomplished.

Just a thought. For those who distribute applications. How many platforms do you need to accomodate?

Re: Vba, R.i.p?

Quote from XL-Dennis

Initially I didn't like the Ribbon UI at all. However, when I decided to not view it from the experience with classic commandbars I saw the benefits the new UI actually provides.

Creating customized XML files with the RibbonX code may "on its face" look difficult and complext but is both logical and understandable. By implement the IRibbonExtensibility we get the callbacks. It's possible to alter the visibility etc and also via callbacks control what will be done.

The following coming article in MSDN Magazine gives a basic introduction:
Extend The 2007 Office System With Your Own Ribbon Tabs And Controls

Patrick Schmid has a forum dedicated to Ribbon which gives additional knowledge and also the possibility to discuss and raise questions.

Display More

I myself was "anti-ribbon", but I have been using it (Office 2007) at home on a daily basis (and use 2003 at work), and I find the other features definately worth while. While the new interface is a complete 180 from what we were all used to, I have been getting used to it. My biggest issue was the ability to customize. I like having "my" version of Excel with all my customizations. It allows me to work effectively and efficiently. thanks for sharing those links, I am loading those pages as we speak.

I start my day of work with a cup of coffee and a bit of Oz. it is a healthy diet for an Excel junkie! : D

Re: Vba, R.i.p?

Quote from Derk

My understanding is that for the Macintosh version Office 2008, VBA will not be supported. Moreover, I believe there will be no replacement for it beyond the more general Applescript. Microsoft's announced reasoning is it is too hard to make the conversion of the clunky Mac version of VBA to the more modern coding basis Office will be using.

Yeah, I may have seen the last update for myself (Office 2004). Since it runs VBA (as long as it is compatible with Office 97, it works on Mac). But with the 2008, it will not even run. At work we upgraded to 2003 just in the last 18 months (65,000 employees). So if they support VBA for 10 years, I'll be long gone into retirement. So may not bother with VB.net.

I know some companies that have depended on VBA for Macs (not heavy duty, but essential tasks). There is no way they can upgrade.

I wonder if a third-party language might offer the best cross-platform potential (Python, Ruby, etc.).