I think this video is one of the most exciting videos hosted on Channel 9.After watching this video, my blood started pumping a little bit faster....why? Because I can foresee my annual salary increasing about 15K a year within the next 2 years as a result of the incredible things I will be doing with the Office add-in capabilities in VS 2005.Your products are truly world class...Thank you Microsoft!Brice RichardP.S. Will the Office add-in also be provided for VS 2005 Standard edition, or just the Team Edition?The website for additional information on Office development tools can be found at:http://msdn.microsoft.com/office/Got ya covered scoble...
I still use VBA for my Microsoft Word jaunts. And, as Microsoft’s Catherine Heller suggests on Channel9.msdn.com, the next version of VSTO will not radically revisit the extremely complex, application object model covered by VBA. It appears that the next version of VSTO is preoccupied with all the stuff shown on Channel9 and the ‘boring’ task of making sure that managed code safely and completely replaces VBA appears to be an obscure edge case that about which ‘our’ Mort cares little. I do not find it impossible that Microsoft will abandon VBA (and VBA-replication) entirely and force us to wait several years before there is a suitable replacement—an equivalent to what we now call “managed.” One possible path is that Office 14 (or maybe Office 12) will run entirely on managed code and Microsoft will simply say, “Upgrade your documents to the new file format and write your new managed code against the new managed object model.” Microsoft will be successful in file-format backwards compatibility but the code will have to be rewritten—even code written in C# or VB.NET for VSTO 1.x.
RASX:::What on earth is wrong with managed code? What is your beef with VBA being ported as managed code into Visual Studio?I think the reality is that it's not outside the scope of possibility that VBA will be ported into a managed code construct within Visual Studio some time in the future.I personally wouldn't mind being able to use VBA's DOCMD functionality which is currently supported in MS Access as managed code within Visual Studio if it were to be ported in that fashion.If VBA is restructured in the future within Visual Studio, well, that's just the nature of change - .Net will reverberate change in the technology world for some time to come in unique and diversified ways.I welcome new and improved ways to code even if it means restructuring or eliminating VBA - by the way, I am a strong supporter and avid user of VBA in my MS Office applications.Brice Richard
Brice It wrote: RASX:::What on earth is wrong with managed code? What is your beef with VBA being ported as managed code into Visual Studio?
RASX:::What on earth is wrong with managed code? What is your beef with VBA being ported as managed code into Visual Studio?
/// <summary>
/// Returns a data-only Word XML string.
/// from the specified Word XML Node.
/// </summary>
/// <param name="XmlNode">Word XML Node</param>
/// <remarks>
/// Unfortunately the C# version of VSTO 1.x does not support
/// the <c>Word.XMLNode.XML()</c> method and its "raw getter" is exposed
/// for our temporary use.
/// </remaarks>
internal static string GetXml(Word.XMLNode XmlNode)
{
return XmlNode.get_XML(true);
}What's "wrong" with get_XML()? In VBA, it's XmlNode.XML(true). What I need to hear is that Microsoft is eager to hide the "raw getter" get_XML() and wrap it up in XML(). What may really happen, is that this syntax will be replaced with an entirely different approach that is not compatible with VBA (and VSTO 1.x's incomplete translation of VBA functionality).
Hi
I wish the video recording (Product / Code Demo) was recorded bit appropriately; its too difficult to catch-up with the demo while the camera man keeps moving the camera here-n-there and keeps zooming here-n-there.
I guess it would be good to have a static view of the demo
My 2 cents
Thanks
PP
Catherine says that before VSTO the only option for document level customisations was to use VBA. However, with VSTO 2005 SE, this is still the case (except for Infopath document level customisations) as it only allows you to create application level add-ins. Hopefully, this is just an intermediate stage until the next version of VSTO.