Hi John

Just FWIW, but most of the work for the Excel 2003 VBA Prog Ref was done by Paul Kimmel, not me; Rob Bovey, John Green and I have instead recently released <a href="www.oaltd.co.uk/ProExcelDev"><i>Professional Excel Development</i></a>.

What I really want to be able to do is create my own top-level, application-wide task panes, which might pull in data from external sources, but might also just present a nice UI for doing stuff entirely within the app.

For the former, imagine something that looks and behaves like the XML Source task pane, but shows a hierarchy of stock prices instead of XML nodes - when dropped on to a cell in any sheet, it creates an RTD formula in the cell to track that stock.

For the former, imagine something like the Mac Excel's formatting pallette.

So are we going to see more white papers and examples of #1 and #2?

And I'm not sure what you mean by the "false dilemma" of VBA vs VB.NET? In what way is it False? Surely you don't mean that .NET should always be used for everything? (FWIW, I won't be using .NET for Excel automation until the 'culture issue' is fixed - and I consider using reflection to be an extremely poor workaround rather than a fix).

And while I've got your attention <g>, it'd be great to hear your views on the 'Classic VB' petition (www.ClassicVB.org), with respect to how the possibility of including support for VBA within the VS IDE would help Office developers adopt .NET (see my post on www.dicks-blog.com for my thoughts).

Regards

Stephen Bullen

Hey John,

I would concur with your reader ... how hard would it be to allow hosting your own content within a task pain without having to jump thru all the hoops you currently have to with VSTO?

I mean, all I really need is the ability to dock a window.

I am member of VSTO team, so I am trying to understand what difficulties we are talking about here.
Mike,
"jumping through the hoops with VSTO" you mean VSTO 2003 which did not address task "pains" at all, right? If you were referring to ActionsPane in VSTO 2005 then I am not sure I understand what you mean?

Stephen,
I hear you in your request for the document level custommization (aka COM Add ins) to be able to attach programmable task pane to an arbitrary document. This is valuable, but event the ActionsPane is only accessible for document level customization.
The thing that I do not understand is what you mean by "one way flow" and .NET is good for bringing data in but not for working with Excel OM. Aside from culture issue, you've got access to the entire OM via PIAs, you have the IntelliSense, VSTO 2005 gives you the ability to place winform controls directly onto worksheet, ActionsPane is flexible enough to allow you to create an experience ala XML structure pane, you can even databind to Excel's List Objects in VSTO 2005. I believe there is enough value to not dismiss VSTO 2005.
Can you address in more details where other roadblocks are?

Hi Misha

I don't think you do understand my wishes. I don't want a concept of 'attaching' a task pane to anything - is the "Help" task pane attched to anything? I don't want to put my UI inside the 'Document Actions' task pane. I want to be able to create my own task panes that will always be there, alongside the 'Open','Research', 'Help' etc panes, and showing in the popup menu you get when clicking the task pane title bar.

As for VSTO 2005, I'm keeping an open mind about it, watching carefully as it develops. Definitely, the culture issue is a job-stopper for me right now. Just because of that one issue, I know I won't be able to get to the deployment stage, which makes obtaining a deep understanding of VSTO a poor investment of my time. If that issue gets resolved, my adoption of VSTO will become more of a 'market' issue - if I see potential clients showing an interest in VSTO, I'll invest my time in learning it in depth (and I haven't seen any so far).

The confusion over my "one way flow" comment arises, I think, from our different attitudes towards .NET and VBA in general. The attitude from most people in Microsoft seems to be "Use .NET for everything you possibly can.", while my attitude is "Use whatever's best for each bit." So the ability to put WinForms controls on the sheet is only appealing if you've been using .NET for some years and have been frustrated about not being able to do that before. Personally, I've been putting controls on sheets for 10 years, so the fact that I can (soon) do it again doesn't light my fire.

I know VBA well enough to know that there are things it doesn't do well, if at all, and which .NET makes easy - and for those things, I'll use .NET for what it does well and VBA for what *it* does well. For example, if I want to access a database over the internet for a roaming user, I'll probably create a web service in .NET to handle the db interaction and read/write XML to the world and do the client side in VBA using the Web Servics Toolkit. Just because I *could* do the client end using VSTO doesn't automatically make it the *right* choice.

The biggest roadblock by far, though, is that most of the time I'm using Excel itself, or using the VBA editor to maintain some of my existing applications. If I see something else that needs doing while I'm there, I'll do it there - rather than close down Excel and fire up VS, just so I can do the same thing in a different language/UI.

I keep seeing things that reinforce my impression that VSTO has been designed, and continues to be designed, to target those people whose natural working environment is the VS.NET IDE - bringing the Excel surface into their environment is a great idea for them.

However, if I'm working in Excel (which I am 90% of the working day) and want to put a button on a sheet to repeat an advanced filter (say), I'm going to use either the Forms or Control Toolbox toolbars to do it with a line of VBA. I'm going to do that because those tools have been brought to me, to where I'm working and they're a mouse click away. I'm not going to close Excel, start VS, create a new VSTO project to attach to that workbook, drop a winforms control on the sheet, write pretty much the same line that I would in VBA, build the solution, close VS, reopen Excel (so I get the usual Excel menus back), reopen the workbook, hope the security got configured OK, then click the button to filter the data. It just doesn't make sense.

In my opinion, this is by far the biggest and most important roadblock that Microsoft needs to overcome in order for .NET to penetrate the Office Automation/VBA market, and I'm convinced that the only way to overcome it is to bring .NET and VSTO to where the user is - i.e. inside Excel and maintaining their VBA code - and using paradigms that match existing Excel UI behaviour (e.g. add a WinForms toolbar to Excel).

On the programming side, I just don't see Office developers choosing to switch IDEs in order to code in VB.NET/C#, so if they're already in the VBA editor to maintain their apps, they'll stay there to write new code. The only way for .NET to penetrate that market is to have a single IDE that allows the creation of hybrid VBA/VB.NET projects. The choice of whether to use VBA or .NET can then be reduced to which type of module to add to the project.

That, BTW, is exactly that the 'Classic VB' petition at www.classicvb.org is asking for.

There are, of course, lots of smaller roadblocks - each one more of a stumbling block, but having a cumulative effect. I'm thinking of things like not being able to For...Each through many Excel collections; parameter names of some methods conflicting with .NET reserved words; not being able to use .NET code with OnKey, OnTime, etc; c# not supporting optional parameters that the Excel OM uses extensively; having to deal with the security configuration when sharing the workbook with colleagues, or taking it home to work on; etc.

Enough for starters?

Regards

Stephen Bullen

Because you and I come from the real-world of solutions development, Stephen, I completely agree that the right tool for the job is the best answer, and often that means tinkering with legacy tools, code, and other dependencies. To me, a legacy system is one that works. You are right that it may not make a lot of sense to whip out the VS IDE and do a full-blown managed solution in .NET when all you want to do is make amendments to a solution that exists.

At this juncture in the product development, I'm not sure that this is what we are after. What I see us consistently promoting is a new way to approach productivity solutions. My position is this: for new solutions, you can cobble together the various development tools and components we have given to the Office dev community over the years (Web Services Toolkit is a good example) and architect your solution with the old assumptions.

OR (!) you can rethink your application design in terms of the new benefits of the .NET Framework and all of the advantages it provides. But there's more. Rather than just give you benefits of .NET, VSTO gives you so much more. Separation of data and views, task-pane programming made easy for a lot (a lot) of uses, data-pumping to server-side documents, slick deployment and maintenance model, and much, much more.

Here's an historical example of how I have seen early adoption of a technology (in this case Web) go with my clients:
I remember pitching my clients on doing ASP apps clear back in late 1996 (ASP was in beta, if I recall correctly, and I had no dev tools). I was pitching the idea that we could do Web-based apps, consolidate their data, centralize access, and this would be easier than do CGI. I was mostly right. But, I met a lot of resistance. People had all sorts of objections, but my argument was about re-thinking their existing architecture and investing in a new way of handling their systems- not just amending what they had. For the next 3 years I had a ton of work in this area. As the tools matured (gratefully!) new possiblities opened up. In some cases, we just did tweaks to the legacy systems, but in other cases, we did some wholesale rethinking of the architecture in terms of the new possibilities that had opened up.

I have other examples like this one, but the point is: in the real-world, there are clearly times to do small adjustments or tiny increments of migration. In other cases, there is a chance to set a new foundation. To me, VSTO is a new, though not iconoclastic if you will, foundation for productivity applications.

I would encourage taking the time to get a deep understanding of what it entails and then see if there are business needs that this new approach can more easily meet.

Hi John,

It's great to see that you consider us to be at the 'early adoption of a technology' stage, which I very much agree with. For any new technology to gain acceptance, I think three things must be in place:
1. Education about the benefits of the new technology, explaining the (unequivocal) benefits that it brings.
2. Penetration of any supporting and required infrastructure.
3. Tools that make it easy for people to move to the new technology, building on what they already know.

At this juncture in the product development, I think Microsoft needs to balance all three of those. Right now, I'm innundated with lots of #1, am disappointed at the amount of #2 (i.e. adoption of Office 2003 Pro) and haven't seen any of #3.

I'm sure Microsoft will continue to produce the (rose-tinted <g>) articles for #1. I hope Office 12 will have enough new 'must have' features to make it the de-facto standard for business and solve #2. And I fervently hope Microsoft listens to the Classic VB petitioners and gives us #3. I am, of course, assuming that adopters of the technology will eventually come from the pool of existing Office/VBA developers - such as me!.

Hi Stephen,

As much as we would like to get .NET penetration for the ad-hoc kind of Office development the tools are not there yet. We do recognize that and we do not pitch to hobbyist developers yet - (put a button there, write a macro here). Instead VSTO targets professional developers. We are bringing VS to the people that were limited to primarily VBA programming for development of complex solutions. Those developers and organizations are the primary target of VSTO v2.
VBA is very much alive and one can develop mixed VBA/VSTO solutions. Macro recordng, quick ad-hoc customizations - those features are not matched by VSTO 2.0 The list might go on, but the point is VBA is somewhat limited too.
IMO, the important thing here is to recognize the trend. So far we are seeing heavy investments in building better/easier to use tools that leverage the richness of existing .NET-based tools and provide SmartClient solutions.
And, yes, I do agree with all your valid points in regard to the conditions necessary for successful wide adoption of new technologies. It takes persistance and time, time and time again to get there.

Hi Misha <br> <br>I fully understand that VSTO targets professional developers, but it seems to me that is professional *.NET* developers, rather than professional *Office* developers being targetted. I see lots of .NET developers looking at VSTO and struggling to learn the Office OM's, but the anecdotal evidence I'm hearing from Office Developers (who know the OMs intimately) is that most of us are seeing how it develops and waiting until we become your target audience - at which point we might get some useful tools. <br> <br>Yes, it takes time, and I'll certainly be persistant in my nagging of Microsoft &lt;g&gt;. It also takes a commitment from Microsoft to do everything in its power to help all their customers migrate both their skills and their applications.

PingBack from http://mediafornews.com/excel2003databindvsto.html

PingBack from http://debtsolutionsnow.info/story.php?id=13310

PingBack from http://unemploymentofficeresource.info/story.php?id=7850

PingBack from http://barstoolsite.info/story.php?id=6633