John R. Durant's WebLog

The "Voice" of Office Development

Office 2003 task pane discussion CONTINUES

NOTE: I am sorry that I couldn't update my blog for a few days. I still have proxy issues that prevent me from updating it while at work (even when bypassing the proxy and using the bland IP).

All of the reponses to my post on the task pane a few days ago were pretty thoughtful (except for the dumb attempts by some to post feedback with nothing but ads for gambling sites). Stephen Bullen, Excel VBA genius and team author of the Excel 2003 VBA Programmer's Reference (and nice guy all around),

made some very important remarks which I re-paste here to catch others up on the thread:

Hi John,

Yes, the Task Pane can be a useful area of the screen to use for UI, but why isn't it possible for us to use it for application-level customization? Why can't I create my own top-level task panes? Why can't I tell the host to show my VBA Userforms as Task Panes (e.g. Form1.Show vbModal/vbModeless/vbTaskPane)? Why is it that 99.9% of the articles on the site are about making use of .Net in (at least) six different ways (Smart Docs, Smart Tags, Research Services, IBF, VSTO) to get information *to* Excel/Word, rather than using it *within* Excel/Word once it's there? Is that where the natural boundary between VBA and .NET lies? .NET is best for getting information there, but VBA is best for manipulating it (through the OM) once there?

It's the Application-level piece and the one-way data flow comments that I find so important here. It is true that many of the customizations we are seeing for Word and Excel are document-specific. VSTO is clearly a doc-level approach. Smart docs is doc-level as are smart tags and Research services. COM Add-ins, as rickety as they are, are attractive because of the application-oriented approach they make possible.

And, we have not done a good enough job telling three stories:

1) Using Office as a data (or XML) producer

2) Using customizations to manipulate data and documents once they are in the authoring environment

3) When VBA or .NET is best (or is this a false dilemma?)

That said, some of the killer VSTO demos do respond to #2 (the stock allocation demo I showed at the Office developer conference is a fine example). In other words, once the data are in the spreadsheet, we interact with the task pane to re-cast the data, provide different views and so on. This is one of the great strengths of VSTO: separation of presentation from data (views from data).

 Rock Thought for the Day: One of the best albums of the 70's still holds up today: They Only Come Out at Night by Edgar Winter, brother of Johnny Winter. Those of you who read my blog regularly know that I have an affinity for the prog rock era of the 70's. I remember when this album was getting airplay in the early 70's while riding around in my uncle Richard's black '69 Pontiac. The smell of the slowly broiling vinyl interior of the car is still fresh in my mind as we drove around town. Richard's life (infantry in 'Nam and so much more) is much more interesting than most of the movies one can see. I often wonder if this is true of all of us.

Published Tuesday, March 15, 2005 6:49 AM by johnrdurant

Comments

 

Stephen Bullen said:

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
March 16, 2005 3:31 AM
 

Mike Parsons said:

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.
March 16, 2005 4:26 AM
 

Misha Shneerson said:

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?
March 18, 2005 8:25 PM
 

Stephen Bullen said:

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
March 22, 2005 7:46 AM
 

John R. Durant said:

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.
March 22, 2005 9:33 AM
 

Stephen Bullen said:

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!.
March 22, 2005 1:57 PM
 

Misha Shneerson said:

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.
March 22, 2005 10:48 PM
 

Stephen Bullen said:

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.
March 23, 2005 9:42 AM
 

excel 2003 databind vsto said:

April 27, 2008 11:00 PM
 

John R Durant s WebLog Office 2003 task pane discussion CONTINUES | debt solutions said:

June 15, 2009 9:03 PM
 

John R Durant s WebLog Office 2003 task pane discussion CONTINUES | unemployment office said:

June 16, 2009 3:27 AM
 

John R Durant s WebLog Office 2003 task pane discussion CONTINUES | bar stools said:

June 19, 2009 2:53 AM
Anonymous comments are disabled

© 2009 Microsoft Corporation. All rights reserved. Terms of Use  |  Trademarks  |  Privacy Statement
Microsoft
Page view tracker