Here's a brief description of the SharePoint workflow tools you'll find in Visual Studio 2008 Professional. Norm Estabrook talks with John Durant, a program manager on the Visual Studio Tools for Office team.

For more information about Visual Studio 2008 SharePoint tools, see the articles on MSDN.

There’s recently been some confusing information circulating about the future of VBA in the press that we want to clear up. The report that the next generation of Office will not contain VBA is untrue – the next generation of the Microsoft Office system will definitely contain all of the functionality that developers and power users expect from VBA. 

What is correct is that we will no longer license Visual Basic for Applications to new partners, as previously announced on MSDN.  Microsoft has traditionally had two main avenues for VBA.  The first, and the one the vast majority of users take advantage of, is that VBA was included as a part of the Microsoft Office system and used for recording macros and automating applications like Microsoft Excel and Microsoft Word.  Beyond that, Microsoft had a licensing program which enabled third-party ISVs to license VBA to include in their applications.  Over the years, a number of partners such as Corel and AutoDesk, have licensed VBA to add application automation functionality to their products.  Any existing partner can continue to ship VBA and Microsoft Office will continue to include it.

As noted previously on this blog, one of the most exciting aspects of the release of Visual Studio 2008 is that the functionality for developing applications for Office has now been incorporated into Visual Studio 2008 Professional Edition.  This means that all of the functionality previously in Visual Studio Tools for Office and a large number of enhancements are now available to developers for building enterprise-grade applications on Office.  Download a trial version at http://msdn.microsoft.com/vstudio and check it out for yourself!

Update:

We’re happy to report that the story has been updated and includes a correction at the bottom of the article.

Thanks!

http://www.regdeveloper.co.uk/2008/01/14/office_mac_08_vba/

My name is Saurabh Bhatia. I recently joined the VSTO team as a Program Manager. In this post I would like to talk about one of my first projects here at Microsoft. Over the last couple of months a few members of the VSTO team have been developing a remarkable Outlook add-in. We call it the Outlook Meeting Planner or OMP for short. The basic idea behind the add-in is to extend Outlook's meeting scheduling capabilities so that it is able to easily find conference rooms in the various buildings at Microsoft.

Anyone who works in a large organization knows how painful it is to first find conference rooms that are available and then actually find your way to the conference room through the maze of corporate offices. This has also been a problem for us here at the Microsoft Redmond campus. Luckily, using VSTO we feel we have been able to develop the right solution to this problem. The Outlook Meeting Planner add-in searches through the free-busy information for various conference rooms and displays the available rooms on a floor plan of the office building. This enables us to search for available rooms and also locate them on a map. OMP dynamically queries various enterprise resources to collect all the information including the floor plans. All of this has been made possible by recently released features in Visual Studio 2008. Here's a little sneak peek at what OMP looks like:

The OMP screen is an Outlook Form Region which hosts a WPF control to display the interactive map. You can find out more about the Outlook Form Regions and WPF capabilities in VS2008 through MSDN. For this post I would like to focus on some of the tricks we learned while developing this add-in.

Enhance your user experience with WPF in Form Regions

Hosting WPF controls in Outlook Form Regions opens up novel possibilities for creating rich user experiences inside Outlook. The OMP add-in is an excellent example of this capability. One of the challenges facing us was to provide a responsive UI when loading the WPF maps. The OMP team came up with a nifty trick to deliver a smooth load behavior for WPF controls. 

Here's what Igor Zinkovsky, one of the developers of OMP, has to say about this:

The first interaction with a FormRegion happens in FormRegionShowing event handler, so that's where developers are likely to put initialization code for their WPF controls:

// Occurs before the form region is displayed.

private void FormRegion_FormRegionShowing(object sender, System.EventArgs e)

{

   // Perform [perf-intensive] initialization of WPF control

   // like starting animation, loading more XAML, creating shapes, 3D animations, etc

   this.myWpfControl.InitMyControl();

}

If the call to myWpfControl.InitMyControl() takes a long time -  the FormRegion will appear to be frozen until the call returns (giving the impression that opening the FormRegion it-self is hanging).  One way to mitigate this is to remove the expensive initialization from FormRegionShowing handler, and to run the initialization from the Idle loop.  Note that this does not completely solve the UI freeze problem, but it does make it look better to the user.  Instead of the UI being frozen when you open the FormRegion, the FormRegion will open almost immediately and the WPF control will initialize on first Idle loop.  The UI will hang while myWpfControl.InitMyControl() executes, but by this time the FormRegion has already been shown with initial state of the WPF control (which could display something like "Loading").

// Occurs before the form region is displayed.

private void FormRegion_FormRegionShowing(object sender, System.EventArgs e)

{

   System.Windows.Forms.Application.Idle += new EventHandler(Application_Idle);

}

void Application_Idle(object sender, EventArgs e)

{

   try

   {

      // Perform [perf-intensive] initialization of WPF control

      // like starting animation, loading more XAML, creating shapes, 3D animations, etc

      this.myWpfControl.InitMyControl();

   }

   finally

   {

      System.Windows.Forms.Application.Idle -= new EventHandler(Application_Idle);

   }

}

Form Regions and Appointment Items

I would also like to share another useful workaround. If you create an add-in with a Form Region which is attached to an Outlook Appointment Item you will notice some strange behavior when modifying existing appointments.

• Open an existing meeting from your Calendar.
• Change something in the Meeting Request like the location/subject/body etc.
• Close the Meeting Request. Outlook will prompt whether you want to save changes.
• Choose Don't Save Changes.
• Open the meeting again. Notice that the changes you made still exist and Outlook has not reverted back to the original Meeting Request.

These changes are lost if you restart Outlook and the item reverts back to its original state. However, in the process Outlook automatically sends out an update to all the recipients of the Meeting Request with the updated information which should not have been saved.

This is a known bug in Outlook programmability which should be fixed soon. Till then all add-in developers can use this trick to make sure that the dirty updates aren't sent out.

This can be achieved by a simple two line magic:

Just call GC.Collect() when the add-in quits. Calling the garbage collector could potentially cause more finalizers to run. To collect the newly disposed object you can call the garbage collector twice.

void ThisAddIn_Quit()

{

   GC.Collect();

   GC.WaitForPendingFinalizers();

   GC.Collect();

   GC.WaitForPendingFinalizers();

}

Calling the Garbage Collector gets rid of any rooted references to the appointment item in the managed code which ensures that the updates aren't sent out. This trick does not solve the problem with the perceived saving of unintended updates (The updates aren't really saved but they will keep showing until you restart Outlook). We will have to wait for Outlook to fix this issue and once it is fixed you will not have to make the call to the Garbage Collector anymore.

Hope you find this information useful in your add-in development adventures. If you haven't already, get Visual Studio 2008 from MSDN.

Special thanks to the OMP team for all the technical insights and to Christin Boyd for convincing me to blog about this experience.

Saurabh Bhatia, Program Manager, Microsoft Corporation

Update on February 16th:  Lots of people have left comments asking for the source code.  The code depends on connecting to some private servers that contain the layout of Microsoft corporate buildings.  There are concerns about publishing the layout of our buildings, as if we will be overrun with criminal masterminds breaking in to my office to steal hardware and all the knick-knacks off my desk.  So we're working on a way to publish the code that removes all references to our servers, and replaces those lines with //todo:  comments.  We also need to find the time to accomplish this task.  We're super busy working on fixing bugs for Service Pack 1 and testing SP1 on 4 operating systems, 2 versions of Office, and 23 foreign languages.  That's quite a test matrix! 

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