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.
Comments
Anonymous
March 15, 2005
The comment has been removedAnonymous
March 15, 2005
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.Anonymous
March 18, 2005
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?Anonymous
March 21, 2005
The comment has been removedAnonymous
March 22, 2005
The comment has been removedAnonymous
March 22, 2005
The comment has been removedAnonymous
March 22, 2005
The comment has been removedAnonymous
March 23, 2005
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 <g>. 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.Anonymous
April 27, 2008
PingBack from http://mediafornews.com/excel2003databindvsto.htmlAnonymous
June 15, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=13310Anonymous
June 15, 2009
PingBack from http://unemploymentofficeresource.info/story.php?id=7850Anonymous
June 18, 2009
PingBack from http://barstoolsite.info/story.php?id=6633