Tag Archive for Office

האם עוד צריך את VB.NET לתכנת מול אופיס?

עברו כמה שנים מאז שעבדתי עם Visual Basic.NET, והייתי בטוח שבימינו, ב-2013, נגמרו כבר הויכוחים של “איזו שפה יותר טובה”. שתיהן שפות עם יכולות דומות, והבחירה ביניהן היא בעיקר העדפה סגנונית. אבל מידי פעם אני עדיין רואה בפורומים או ב-Stack Overflow שאלה בנוגע ליתרונות של שפה אחת על השניה, וספציפית על יכולות ה-COM Interop של VB. האם היא באמת שפה נוחה יותר?

המצב טרום .NET 4.0

לפני .NET 4.0 (שיצאה, יש להזכיר, לפני כמעט 3 שנים), התשובה היתה “כן”, אם כי “כן” קצת דחוק. VB הגיעה מתוך עולם ה-Late Binding, ולא היה לה בעיה להעביר לרכיב רק חלק מהפרמטרים שהם צריכים, ולדאוג לשאר לברירות מחדל מאחורי הקלעים. היתרון הזה היה בולט במיוחד כשעובדים מול אובייקטים של אופיס, שמכילים מתודות שמקבלות חמישה, עשרה, ולפעמים שישה-עשר פרמטרים אופציונאליים, כשברוב המקרים אנחנו נרצה להעביר רק אחד או שניים מהם, אם בכלל. ההבדל בין C# ל-VB במקרה כזה הוא ההבדל בין הקוד הזה ב-C#:

Code Snippet
  1. myWordDocument.SaveAs(ref fileName, ref missingValue,
  2.                  ref missingValue, ref missingValue,
  3.                  ref missingValue, ref missingValue,
  4.                  ref missingValue, ref missingValue,
  5.                  ref missingValue, ref missingValue,
  6.                  ref missingValue, ref missingValue,
  7.                  ref missingValue, ref missingValue,
  8.                  ref missingValue, ref missingValue);

לבין זה ב-VB:

Code Snippet
  1. MyWordDocument.SaveAs(FileName: fileName)

שזה, אתם חייבים להודות, הבדל לא קטן.

אבל מצד שני, לא כל ממשק COM עובד ככה. למען האמת, בכל שנותי אני חושב שנתקלתי בסגנון כתיבה הזה רק בספריות של אופיס, ולא בשום רכיב אחר, בין אם של מיקרוסופט (כמו רכיבי DirectShow שאיתם עבדתי לאחרונה) או של חברות אחרות. ברוב המקרים, לעשות COM Interop ב-C# פשוט באותה מידה כמו ב-VB.

.NET 4.0 – גם C# זוכה ליחס

היתרון הקטן הזה של VB נהיה גם הוא פחות רלבנטי החל מ-C# 4.0 ו-Visual Studio 2010, משתי סיבות:

הראשונה היא מילת הקסם שהתווספה לה לשפה, dynamic. כשאנחנו מגדירים אובייקט כדינאמי, אנחנו מוותרים על הרבה מה-static type checking שהקומפיילר עושה בשבילנו, ונותנים למנגנון ה-late binding (שסופח ל-C# באמצעות ה-DLR, ה-Dynamic Language Runtime שנבנה לתמוך בשפות דינאמיות כמו Python או Ruby) לעשות בשבילנו את העבודה ב-runtime. מכיוון שיש late binding, אפשר להתעלם מהפרמטרים המיותרים ולתת ל-DLR להבין לבד מה לחבר לאיפה. אפשר למצוא הסבר כללי על שימוש ב-dynamic במאמר הזה, והסבר יותר ספציפי על השימוש בו ל-COM Interop במאמר הזה.

אבל אם אנחנו שקלנו לעבור ל-VB רק בשביל לעבוד מול רכיבי אופיס, אז C# 4.0 מאפשר לנו להקל על החיים גם בלי לצלול לעולם העכור של dynamic languages. אנחנו עדיין לא יכולים להתעלם מ-ref parameters במתודות של מחלקות, אבל אנחנו כן יכולים להתעלם מהפרמטרים הללו בקריאות למתודות על interfaces. אני לא יכול להגיד שאני מבין לגמרי למה זה ככה (טרם התעמקתי) אבל זה אומר שאם מה שיש לנו ביד זה לא אובייקט DocumentClass של אופיס, אלא interface מסוג Document, אז אפשר לקרוא למתודות שעליו כמו ב-VB.

לנוחותינו, ספריות ה-Interop של אופיס חושפות לנו את ה-interfaces האלה, דרך property בשם InnerObject שיש על רוב האובייקטים המעניינים. (כן, זה property בשם InnerObject שחושף את ה-Interface. אני יודע. זה מבלבל. זה מה יש). אז את הקוד שכתבנו למעלה  אפשר להחליף, ב-C# 4.0, בזה:

Code Snippet
  1. myWordDocument.InnerObject.SaveAs(FileName: fileName);

וזהו! אמנם לא כל אובייקט של אופיס זוכה ל-InnerObject הזה, אבל המרכזיים והגדולים (שהם גם אלה עם המתודות המפלצתיות) דווקא כן. ואם אין ברירה, נעבוד גם עם dynamic – או עם Missing.Value.

אז מתי בכל זאת VB?

כל המלל לעיל לא נועד לשכנע מישהו לבחור דווקא ב-C# או דווקא לא ב-VB. שתי השפות יכולות לעשות פחות או יותר כל אחת את מה שהשניה יכולה לעשות, והבחירה בה צריכה להיות של העדפה אישית לסגנון כתיבה, לא בגלל יכולת קריטיות לכאן או לכאן. זה מה שניסיתי להעביר כאן – כמו ש-VB יישרה קו עם C# לאורך השנים בכמה פיצ’רים שהיו חסרים, כך גם C# השלימה את החסר לה בנוגע לעבודה עם אופיס. הבחירה היא, שוב, סגנונית בלבד.

Preventing Outlook from closing with Alt-F4

I have come to the realization, at some point, that I never want to close Outlook. Really, there's no reason for me to shut it down except when doing something special, like freeing every available byte of memory, or when developing add-ins to it. During day-to-day work, I always want it on and minimized. The problem is that there's no easy keyboard shortcut to minimize Outlook like there is to close it – I don't like the two-step shortcut of Alt+Space – n, and I don't want to define a new non-standard keyboard shortcut that I have to remember in addition to the standard Windows keys.

So instead, I've decided to go the route that RSSBandit and other programs did – intercept the Alt-F4 keypress, and minimize to the tray rather than closing. Whenever I do want to close Outlook, I can do it via the File->Exit option. It's rare enough not to bother me.
Writing this proved to be ridiculously easy when using VSTO 2005 SE and a library I had already developed a while ago to hook into the keyboard events.

The steps are simple:

1) Create the Outlook Add-in Project. I wrote this for Outlook 2007 – it should work the same for 2003:

2) Add a reference to the HookLibrary mentioned above.

3) Write the following code in the ThisAddin_Startup event:

private KeyboardHook altF4Hook;
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
   altF4Hook = new HookLibrary.KeyboardHook();

   // false/true/false is for ctrl/alt/shift modifiers, respectively.
   altF4Hook.AddFilter(Keys.F4, false, true, false);
   altF4Hook.KeyPressed += new KeyboardHookEventHandler(altF4Hook_KeyPressed);
   altF4Hook.Install();
}

void altF4Hook_KeyPressed(object sender, KeyboardHookEventArgs e)
{
   Outlook.Explorer exp = Application.ActiveExplorer();
   exp.WindowState = Microsoft.Office.Interop.Outlook.OlWindowState.olMinimized;

}

 

And that's it. On our development machine it should automatically be installed in Outlook. For other machines, we can build the MSI file that's created for us and install it. I've attached the MSI here, as well as the full code. Enjoy.

Screencasts vs. Whitepapers

A few weeks ago, Lawrence Liu (a senior technical PM and community lead for Sharepoint at Microsoft) linked to a few screencasts for learning how to use various features in MOSS2007. In that entry, he mentioned how screecasts are more effective and efficient in training and learning to use a new piece of software. Me, I’m a bit divided about them:

1) Screencasts are great for getting a hands-on view of the system, that’s true. A picture is worth a thousand words, and a movie is worth about 30 frames per second. I know software authors that have replaced the help file completely with a small Camtasia screencast. This, of course, only works for simple programs with few use-cases.

2) As Lawrence mentions, most screencasts are way, way too long. It’s understandable – when speaking you want to be as clear and understandable as possible. Too often it turns into a slow, repetitive lecture. To illustrate: last month Microsoft Israel held a Developer Academy conference to give lectures on new Vista dev topics. I squeezed in one Office 2007 talk. Because I was too worried about being clear and understood, I ended up repeating myself. Even a completely non-technical listener who just came in to hear me speak (yes, indeed, it was my mother) said she got the point already and that I should get on with it.

My point? Too many screencasts are way too long. Jan Tielens’ SmartPart (and sons) is a wonderful web-part to use and to learn from, but the screencast takes 16 minutes to describe what the 2-page readme.txt contains.

3) Screencasts are mostly a solution to learn the how, not the why. I can use Lawrence’s screencasts to learn how to add a library to the Records Center, but I would have found that out myself with little effort. What I would really want right now is a good set of whitepapers to understand the goals of the Records Center and how to use, not abuse it in my solutions.

4) A final tip for screencasts and webcasts – when using Windows Media Player you can speed up playback without affecting the pitch. This is to mitigate slow lecturers and needless repetition. It might require downloading the video locally first. Speeding it up to 140% is usually perfectly understandable.
On my Media Player 9, it’s under View -> Enhancements -> Play Speed. Enjoy.

Outlook Calendar as your Windows Desktop

In a Channel 9 conversation, user Dr. Herbie expressed his long-standing desire to see his Outlook calendar as a desktop wallpaper. This, I admit, has never once occured to me. The nice thing about it is that it's so amazingly simple to implement.

Ever since Windows 98 and the Active Desktop, you could use HTML as the desktop wallpaper and embed anything you want in it. For the last 4 versions at least, Outlook comes with an ActiveX control that lets you display the contents of any Outlook folder in your application. Mix the two – and you have an HTML page that embeds the Outlook View Control maximized to fullscreen, defaulting to today's date, and add two simple Javascript buttons to move back and forward in the days.

A less lazy developer can make this much nicer, with a monthly date-picker and less ugly buttons. Considered as as Proof of Concept, it works with some caveats:

1) Due to the whole Eolas/ActiveX lawsuit fiasco, you need to click on the desktop once to enable interaction with the ActiveX control.

2) You can click on desktop icons, but you can't drag them around (well, without dragging them into an appointment. :). This can be fixed by resizing the control to allow some free desktop space, I suppose.

 

3) This keeps an instance of Outlook permanently in memory. Probably isn't a problem, but good to know.

4) As it stands, the control will mirror the view current selected in your Outlook calendar.

Here's a screenshot of my desktop right now. Thanks for the idea, Herbie!

 

TO INSTALL:

Download the specified attachment (CalendarWallpaper.zip) and unzip into any convenient place. My Documents, for instance.

Then, Go to your desktop properties -> Desktop -> Browse and choose the unzipped file (CalendarWallpaper.htm). Et voila!

Exposing add-in errors in VSTO for Word 2007

One of the most annoying things about writing add-ins for Office is that it tends to swallow any and all errors that occur. All exceptions are silently thrown into the trash heap without even a statusbar flag. Nothing. This meant that we often had to add messageboxes for debugging, or Debugger.Launch to see what’s going on.

At first I thought that Word 2007 was no different, but then I was idly browsing through the Word Options dialog and discovered a wonderful prize – a checkbox called “Show add-in user interface errors”. Quickly checked and lo and behold – exceptions in my code are shown by Word! Life is good again!

So in case you’ve missed it too (and it’s easy to miss), it’s under the Office/File menu -> Word (or Excel) Options -> Advanced:

 

Enjoy!

VSTO for Outlook 2007 – Building the Add-in (part 2)

Writing the Outlook add-in described in my previous post was composed of the following steps:

1) Creating the project

Ah, the wonders of VSTO. Saving us all the unnecessary hassle of adding COM references, implementing interfaces and working too hard. After installing VSTO 2005 SE we can create a new Outlook 2007 Add-in project that creates both the add-in project and the MSI Setup project that can be used to install it.

2) Building the Context Menu

To add my own menu items to each item's Context Menu, I use the new ItemContextMenuDisplay event that is exposed by the Outlook 2007 object model. In the pre-supplied Startup method I simply add the following event registration:

this.Application.ItemContextMenuDisplay += new Microsoft.Office.Interop.Outlook.ApplicationEvents_11_ItemContextMenuDisplayEventHandler(Application_ItemContextMenuDisplay);

In my event handler method I start by fetching the current Outlook folder:

MAPIFolder currentFolder = Application.ActiveExplorer().CurrentFolder;

and creating the root of the popup menu tree:

// Create a new button in the commandBar. The command bar itself is received as a parameter to the event
// handler  method.

CommandBarPopup rootButton = (CommandBarPopup)commandBar.Controls.Add
(Office.MsoControlType.msoControlPopup, Type.Missing, “MoveToFolder”, commandBar.Controls.Count + 1, Type.Missing);
 

rootButton.BeginGroup = true;
rootButton.Tag = “MoveToSubFolder”;
rootButton.Caption = “Move To…”;
rootButton.Visible = true;

Now I recursively go over the current folder and its subfolders, adding new buttons under the rootButton as I go along.

Things to note:

  •  I create a different menu control depending on whether I'm creating a leaf node or a node that has children – one is a Button, the other a Popup. For some reason I couldn't create a PopupButton, maybe it's a control that's reserved for a toolbar and can't be used in a ContextMenu. This means that a node with children cannot be clicked, and we can't copy items to it. There may be a workaround to this using the OnAction property rather than the Click event, but I haven't gotten around to checking it out. I'd appreciate feedback.
  • I'm saving the FullFolderPath in each node's Tag object. This is so I can access it later when I'm moving the items. I originally wanted to save the EntryID + Store's EntryID in the Tag for a totally unique identifier, but for some reason Outlook crashed whenever I tried to save that in it. I have no idea why.
  • Note the recursion – each folder is addings its leaf-nodes as buttons, and sending each non-leaf children to another call to AddFolder.

private void AddFolder(MAPIFolder folder, CommandBarPopup menu)
{
      foreach (MAPIFolder subFolder in folder.Folders)
      {
MsoControlType linkType = (subFolder.Folders.Count > 0) ? 
               MsoControlType
.msoControlPopup : MsoControlType.msoControlButton;

     
CommandBarControl folderLink = menu.Controls.Add
(linkType, Type.Missing, subFolder.Name, 1, Type.Missing);
 
            folderLink.Tag = subFolder.FullFolderPath; 
            folderLink.Caption = subFolder.Name;

 
            if (linkType == MsoControlType.msoControlPopup)
            {
AddFolder (subFolder, folderLink as CommandBarPopup);
            }
            else
            {
(folderLink as CommandBarButton).Click += new
                             _CommandBarButtonEvents_ClickEventHandler
(
            MoveToFolder);
            }             
      }
}

3) Moving the items

As we could see above, each leaf node's Click event is handled by the MoveToFolder method:

Again, noteworthies:

  • The FullFolderPath we saved earlier is translated to a MAPIFolder object using the GetFolderFromPath function, a glaring omission in the Outlook object model that we have to rectify by hand. I'll post the full (and simply) code for this in a different post. It's included in the attached project. 
  • Note that we're casting the items in the current selection to MailItem objects, meaning standard outlook email messages. We're ignoring non-MailItems in this code. Since the COM object model doesn't give us any shared base-classes or interfaces for other entities, we need to write some ugly code to handle PostItems, AppointmentItems and so forth.

 

 
void MoveToFolder(CommandBarButton Ctrl, ref bool CancelDefault)
{
          MAPIFolder destFolder = GetFolderFromPath(Ctrl.Tag);
 
          foreach (object item in Application.ActiveExplorer().Selection)
          {
                    MailItem mi = item as MailItem;
                    if (mi != null)
                    {
                             mi.Move(destFolder);
           }
                    else
                    {       
                             // Can only copy MailItems;
                    }
          }
}

4) Profit!

Well, maybe not. But this is the entire extent of the code needed to implement this add-in. I've attached the whole project (including the MSI project) so you can install it at home, or use the code as a base for whatever add-in you feel like writing. The pre-built MSI is in the MoveToFolderAddInSetupDebug folder. Enjoy!

VSTO for Outlook 2007 – New Features, More Fun (part 1)

Introduction

Outlook has always been a bit of a latecomer to the VSTO game, being a step behind and a version later than Word and Excel. I'm glad to see that with Outlook 2007 and VSTO 2005SE it's gotten simpler and easier to write add-ins for it. So I did.

The basic premise of this was an exercise to know more of the new Object Model enhancements in Outlook 2007, but it best serves as an example of a add-in for Outlook that uses the VSTO environment and the abilities of the new version.

The Goal

Lately I've found my inbox exploding with many new subfolders. Lots of new projects and tasks that accumulate messages and information. Since I don't subscribe (yet?) to the “Search, don't Sort” philosophy, I tend to group my correspondences into subfolders in some intricate and arcane hierarchy. Outlook 2007 gives me three methods of copying messages from my inbox to the relevant folder:

1) Rules. The problem here is that I don't always know in advance who the mail will be coming from or what will be on the subject line.

2) Drag&Drop. Necessitates keeping my folder tree open to its full depth, or else waiting for the interminable timeout until the tree expands itself. Also, no keyboard support.

3) Move To Folder dialog. This allows me select several items and move them en masse to a new folder. The problem here is that it opens a whole dialog for me to traverse (like in the Drag & Drop scenario above) until I can move my items. Move clicks, more UI to go through.

As you can see, I'm not thrilled with either one of these alternatives, so I decided to add a fourth.

The Solution

A solution that was suggested to me a while ago was, unfortunately, very hard to implement using Office 2003. The idea is to add a new menu item to an item's Context Menu in Outlook that will allow quick access to all subfolders. This will allow a two-click moving (one to raise the context menu, another to choose the destination). It also allows keyboard navigation and selection, making it easier for those times when I'm experiencing mouse fatigue.

There are some problems and limitations with my current implementation, an admittedly quick'n'dirty solution. The first is that I currently only support moving MailItems, meaning normal Outlook messages. It currently won't work for tasks, appointments or Public Folder posts. This isn't really a problem for most scenarios, but if someone needs that functionality, it should be added.

Another problem is that you can only move items to a leaf folder – if I have a Projects->Sharepoint->NewSharepointProject hierarchy, I can't copy my items to the Projects or Sharepoint folders. This is probably solvable, but I decided against confornting the Office Commandbars for now. I'll elaborate more later when I talk about the code.

The Code

This has gotten longer than I expected, so I'll be splitting the actual code of the add-in to a different post. Here's the link to the second part: The Add-in Code post.

Screenshots

(For the sake of politeness I've blacked out most of my inbox. Do not be alarmed. Don't try to adjust your sets)

File Properties in Word 2007

A client asked me the other day what happened to File->Properties in Word 2007. They simply couldn't find it.
In the Beta1 TR, I remember it was confusingly located on the Status Bar (!) – right-click, pick View and View Properties. Very annoying.
In Beta 2 it took me a minute to find it, and I have to say the new location isn't much better – it's under File/Office/Orb -> Finish:   

This, I feel is hardly obvious. I don't necessarily want to input this data only when I'm finishing off the document. It contains other data, even if we ignore the statistics that can be seen elsewhere (again, on the status bar). 

Clicking Properties in the Finish menu, however, doesn't actually open the familiar dialog at all, but a strange new beast – the horizontal pane:   

This pane is, I feel, a mistake. There is some justification, perhaps, for the sudden appearance of a Mail Header pane when we send an email from Word. It sticks out a bit, but it brings the familiar Outlook UI, which makes sense when we're sending an email.
Here, however, it's just unexpected. There's no other use of this sort of UI in Word, so consistency is shot. It eats up a huge amount of screen real-estate that doesn't go away until you explicitly close it – wasn't the whole point of the ribbon to avoid all those messy toolbars that users bring up and don't know how to remove?
 
And all this for 7 text fields which also appear on the Summary tab of the Properties dialog, which can much more intuitively closed by pressing Ok on the dialog.  I really feel this is a bad UI choice for Office 2007. I hope they change it in the final release.

Enough of the rant. Now for proposed solutions. I went over this with a friend, and our opinions differed. I suggested sticking with the old familiar dialog for adding/seeing metadata, while he proposed a new solution: Add the metadata as a Cover sheet or End sheet, built into the document itself.
That means we'll add another virtual page to the beginning/end of the document that isn't, by default, shown or printed. The user will add the metadata fields (Creator, Title, etc) the same way he writes the document itself.
 
I feel this isn't a good idea. To my mind, the metadata is separate from the document text itself. Not only will most users not want to see it (which isn't really a problem if it's disabled by default) but I think that adding metadata is a separate thinking process. Putting it under the Finish submenu shows that Microsoft seem to feel the way I do. 

Enough of the rant. Now for proposed solutions. I went over this with a friend, and our opinions differed. I suggested sticking with the old familiar dialog for adding/seeing metadata, while he proposed a new solution: Add the metadata as a Cover sheet or End sheet, built into the document itself.
That means we'll add another virtual page to the beginning/end of the document that isn't, by default, shown or printed. The user will add the metadata fields (Creator, Title, etc) the same way he writes the document itself.
 
I feel this isn't a good idea. To my mind, the metadata is separate from the document text itself. Not only will most users not want to see it (which isn't really a problem if it's disabled by default) but I think that adding metadata is a separate thinking process. Putting it under the Finish submenu shows that Microsoft seem to feel the way I do. 

Any opinions or ideas?

Outlook Miscellany: Erasing a name from the Autocomplete Cache

The drop-down list of names that Outlook gives us to auto-complete a name or address being written is stored in a file called .NK2 in our Application DataMicrosoftOutlook directory. This file is stored in a proprietary binary format, and there's no known documentation for it as far as I know. There seems to be a company that (apparently) reverse-engineered the format and are selling a cache-editing tool, but it's pricey – the basic desktop version can edit, import/export and print for $35. The network/helpdesk editions can do remote NK2 editing for all computer on the network, but gets really pricy with per-seat licenses and so forth.
(They're called Ingressor, if anyone needs those tools)

It turns out, however, that the most common usage for such an editor isn't necessary. If we just want to remove an item from the cache we can do it from within Outlook itself – simply navigate the drop-down options using the arrow keys and press Del on the one we want to erase – and away it goes.

Very simple, and even logical when you think about it. We're just not used to live editing of an auto-complete list.

DatePicker Blues.

I’m really surprised at how hard it is to find a good DateTimePicker control that meets all our requirements:

1) Must suppost null dates, like the Due Date datepicker in Outlook tasks.
2) Must be an ActiveX, and supported inside both .NET winforms and Outlook forms.
3) Be generally bug-free and supported.

Doesn’t look that hard, does it? But still I’ve wasted my time on many options, among them:

1) Janus Windows Forms Controls for Microsoft .NET. They have an excellent WinForms package with Outlook-style, controls, but their ActiveX package is old and contains only a grid. Also, their prices are a bit high for this project.
2) DevExpress have a .NET and an ActiveX version of their DatePicker, which is also more than adequate. Again, prices are a problem – buying the suite is expensive, and getting only the XPressEditors component is even worse – over $1200 when all we need is a datepicker?
Addendum: The control does NOT work properly on Outlook forms – the dropdown doesn’t.
3) CodeJock have a nice ActiveX Calendar Suite with a datepicker that has good features, but for some reason is implemented as a MonthCalendar display only – no pop-up calendar.
4) NeoComponents have an ActiveX Calendar suite, with a datepicker that crashes and burns when added to an Outlook form.
5) XE Software have a nice little date control too, which unfortunately doesn’t allow None as a valid date choice.
6) *New*  TeamScope have an Outlook Developers Library, including lots of libraries for working with Outlook solutions, and a good ActiveX DatePicker too. The problem? The font for the month name is fixed and unchangeable, and isn’t set to a Hebrew codepage. How silly is that?

After fiddling with those for a while, I decided to try a different approach – extending the basic DateTimePicker control with the None option, or simply wrapping a good .NET control as an ActiveX.

1) Messing with the .NET DateTimePicker is nasty – it calls the API to use the Windows Common Controls for the picker and the calendar, and adding a button there is really annoying – Many calls to SetParent and SetWindowPos and interfering with the WndProc before I could get my button sync’ed in with the calendar, and it still doesn’t look as good as a calendar built for it.

2) Wrapping a .NET control as an ActiveX to be used by Outlook Forms is also problematic, messy and unsupported. Current status, with the help of some good people, can be found on OutlookCode. However, if the Janus suite is chosen for the project (Regardless of the DatePicker) I might have to use this.

Does anyone have a simple, miraculous cure for my problems?

ADDENDUM:
John R. Durant, over at the MSDN Office Developer Center, blogs about the .NET Controls on Outlook Forms problem.