Paul Stubbs : VSTA

Top 20 cool new features of VSTA

pstubbs — Fri, 10 Nov 2006 18:11:00 GMT

Now that VSTA has RTM’d (See KD Hallman’s announcement at http://blogs.msdn.com/vsta ) I would like to call out all of the great features of VSTA. You can see some of these features in action today as part of InfoPath 2007. Just install InfoPath 2007,...(read more)

Video Demo: Using VSTA

pstubbs — Mon, 25 Sep 2006 20:42:00 GMT

Watch and learn about new features in VSTA....(read more)

VSTA and VBA side by side walkthrough

pstubbs — Tue, 01 Aug 2006 08:46:00 GMT

When we developed VSTA, one of the key scenarios for us was that VSTA should work side by side with VBA. We understand that developers would be unable to cut over cold to VSTA. Just like with COM interop VSTA and VBA side by side allows developers to migrate their VBA solutions over time when it makes business sense to do so. Summit has written an excellent article to demonstrate ShapeApp integrated with VSTA and VBA at the same time.

Integrating VSTA with an Unmanaged VBA-Enabled Application

-Paul

VBA to Visual Studio Tools for Applications Migration

pstubbs — Mon, 26 Sep 2005 18:47:00 GMT

"How do I migrate my code from VBA to VSTA?", is a common question that is asked by many people. The short answer is that VBA code and VSTA code can run side-by-side. So if you have an existing VBA program it will continue to work. If you are creating a new program it should use VSTA. The long answer is that there is no magic available to automatically convert your code, just like from VB6 to VB.Net automatic converters can only take you so far. Luckily there is a solution. Art in Soft has announced services to help you migrate your VBA code to VSTA. http://www.artinsoft.com/so_vba.aspx

VSTA: What is an Add-in?

pstubbs — Thu, 15 Sep 2005 21:24:00 GMT

This is an excellent question posed by TQ, one of our architects, on his blog. The definition of an add-in is:

An “Add-in” is any component that is dynamically discovered and loaded by its host. It usually is compiled separately from the host and the host and Add-in version independently of each other. The host and add-in must agree upon a common contract or contracts through which they communicate.

So think about all of the types of add-ins in Office alone: VBA macros, Com add-ins, Smart Tags, Real Time Data, VSTO assemblies and others. As TQ talked about in his blog, these all require some kind of contract that enables them to communicate with the host. For example Com add-ins requires the IDTExensibility2 interface. Smart Tags must implement ISmartTagRecognizer and ISmartTagAction. The point is that all of these different types of add-ins are not only add-ins in the common sense but enable customization at all levels of an application. For example your application could support application level add-ins, document level add-ins or any other level. So free your mind to think about at what level is the appropriate level and what context should the add-in focus on. Creating the add-in at the correct level and context makes it easy for the add-in writer because they do not have to walk the object model to get to the correct context. Similar to the experience between writing a generic Com add-in for Excel or using VSTO to create a solution. The VSTO solution is easier to write because it focuses on the correct level and context.

-----
This posting is provided "AS IS" with no warranties, and confers no rights.