shahine.com/omar/

homepage | Send mail to the author(s) contact

yet another Microsoft blogger

# Thursday, April 29, 2004

Great Smartphone companion desktop application

Wow, this is something I've always wanted on my PC. Jeyo Mobile Companion lets you send, receive, and generally manage your SMS messages on your Windows Mobile Smartphone. You can also manage your call history I just installed it and it seriously rocks. The only feature it seems to be missing is a notification of sorts when you get a new sms (like the Apple AddressBook). Anyway, the application is very well designed, installs well, and generally meets my bar for being a good windows application.

It advertises the following features:

  • Support any Windows Mobile Smartphone or Pocket PC Phone Edition device
  • Send, receive and search SMS messages from a Windows PC
  • Organize contacts in a Windows Mobile device''s memory or on a SIM card
  • Backup and restore SMS messages or contacts
  • View call history
  • Install applications and homescreen themes on a Windows Mobile device
  • Take screenshots of a Windows Mobile device
  • View a Windows Mobile device''s system information

Posted Thursday, April 29, 2004    Permalink    Comments [0]  View blog reactions

 

Opening Acrobat PDFs in IE

As I just mentioned, there is a way to make Office documents open in their respective apps rather than IE. Since PDFs are quite common on the net I am always getting annoyed when they load in the browser for many of the same reasons I mentioned earlier today.

The double whammy to PDFs loading in IE is that they are not entirely downloaded. So for a multi page PDF file you have to wait a long time to page around and in many cases this freezes IE which makes me extra grumpy (try searching, even worse). There is a preference in Acrobat Reader to both disable the opening of documents in the browser as well as disable the loading “feature” (I'd call it a flaw). Here is how to do it:

  1. Launch Acrobat (why oh why does this take FOREVER!!!)
  2. Go to Edit->Preferences (Adobe should know by now that Windows programs do not have Preference in the Edit menu. That is legacy Mac OS 9 behavior. Please fix this).
  3. Click on Internet
  4. Uncheck Display PDF in browser
  5. Unhceck Allow fast web view

Now quit Acrobat. Problem solved. However, in my attempt to semi automate this I tried to figure out what regkeys control this behavior and failed. It seems that the following regkey controls the browser setting:

[HKEY_CURRENT_USER\Software\Adobe\Acrobat Reader\6.0\Originals]
"bBrowserIntegration"=dword:00000000

However, if you set this it does not actually work until you launch Acrobat and go to Preference and Save them. seems changing the regkey in and of itself does nothing till the prefs somehow get marked dirty. Does anyone have an secrets about making this stick?

While we are on the subject, launching Acrobat is painfully slow. In fact, for a product that is designed to be used to read documents it doesn't really optimize for that scenario (it's very slow, page flipping is slow, and launching is slow). There are some documented ways to speed up Acrobat by quite a bit though. But common, I really shouldn't have to do this. Don't load plugins and code that I'm not ever going to use. Go look at how fast Word, PowerPoint and Excel boot.

I'm also assuming there is good reason why Apple has written their own PDF viewer that ships with the OS. It's far superios to Acrobat Reader for doing the most common scenerio (reading a PDF).

Posted Thursday, April 29, 2004    Permalink    Comments [3]  View blog reactions

 

Office Documents opening in IE

One of my biggest gripes about Windows and Office is that when you click on a word, excel, or PowerPoint doc (or acrobat doc) in Internet Explorer, those documents render in the browser pane. This is one of the biggest usability issues I face with Windows. Since you don't get the Application menus and so on it makes it very difficult to work with the document if you wanted to edit it (which is what I usually do). And if you do edit it, you are presented with a horrible dialog when you try and navigate away (and there is no easy way to do a File->Save As). Further I much prefer to view a PowerPoint slide deck in PowerPoint than use that wacky web way of navigating the slides. Finally, if you are a portable user, not having the document open in the respective Office application make it hard to manage offline.

Gus Perez documents how to fix this. But since I frequently “repave” my Windows boxes and use multiple computers I am loathe to do anything manually. So to save you the time here are the necessary registry settings to make IE behave the way that I expect it to. Save the text below into a notepad file and call it OpenOfficeDocsInOffice.reg and then double click that file. Save it in a place you can access and open it on every machine you use.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Word.Document.8]
@="Microsoft Word Document"
"EditFlags"=dword:00010000
"BrowserFlags"=dword:00000008

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Excel.Sheet.8]
@="Microsoft Excel Worksheet"
"EditFlags"=dword:00010000
"BrowserFlags"=dword:00000008

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\PowerPoint.Show.8]
@="Microsoft PowerPoint Presentation"
"EditFlags"=dword:00010000
"BrowserFlags"=dword:00000008

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Visio.Drawing.6]
@="Microsoft Visio Drawing"
"EditFlags"=dword:00010000
"BrowserFlags"=dword:00000008

 

Posted Thursday, April 29, 2004    Permalink    Comments [5]  View blog reactions

 

# Wednesday, April 28, 2004

iTunes 4.5

iTunes 4.5 is out. Most interesting new features:

  1. Can import WMA files
  2. New format, Apple Lossless

Welcome to the party. I rip all my audio as WMA Lossless cause I don't want no stinkin compression. However, I trancode all my audio to the latest and greatest audio format.

The fact that it can now import WMA is great cause I'll be able to just point it at my WMA collection and suck it in to my iPod.

I really hope they made it so that the iPod batter meter actually does something useful. Right now it's completely worthless. If I charge my iPod all day long and un plug it, the things starts off as half empty. Sheesh, it's almost as bad as the gas gage in my Audi.

Posted Wednesday, April 28, 2004    Permalink    Comments [3]  View blog reactions

 

When COM Registration fails in an MSI (vsdraCOM has no affect)

 Summary

In this weeks’ installment of I hate COM, lets talk about a frustrating problem I’ve been having (turns out I had this problem when I wrote my Media Center Front Panel Display but found a different workaround I mention below). It would be nice if there were a KB article on this topic, but there isn’t and I don’t know why.

Say you are exposing a .NET component as a COM component. Not to uncommon. I already do this in my Outlook2OneNote add-in as well as my Media Center Front Panel Display. In both these cases I am implementing a COM Interface: Extensibility.IDTExtensibility2 for Outlook2OneNote and EHLib.IMediaStatusSink for my Media Center Sink.

In Outlook2OneNote the project structure looks like

  1. Project 1 – contains the guid and COM Inteface
  2. Project 2 – inherits from a class in Project 1 and is marked for COM registration
  3. Setup – Primary Output from Project 2’s Register value is vsdraCOM

In MediaCenterSink the project structure looks like

  1. Project 1 – contains the guid and COM Inteface and marked for COM registration
  2. Project 2 – contains the code for the Sink
  3. Setup – Primary Output from Project 1’s Register value is vsdraCOM

In both cases the MSI does not register the Primary Output for COM Interop. It’s not obvious why this fails, but I spent many hours trying various things (you know how trial and error is when you don’t have an understanding for what is going on or what is broken right?). So you can imagine how frustrating this is. Even more frustrating is when this happens to you twice in the course of a few months.

Approach 1: Custom Action

Well, google had no answers for me except a bunch of other people who were saying “COM Registration during install using MSI is broken…” or “vsdraCOM doesn’t do anything…” etc. The only solution that I found was to write some code in the Primary Output project like so (you need a similar Uninstall and Rollback override as well):

public override void Install(System.Collections.IDictionary stateSaver)
{
    base.Install(stateSaver);

    try
    {
        RegistrationServices regSrv;

        // Register the assembly
        regSrv = new System.Runtime.InteropServices.RegistrationServices();

        if (!regSrv.RegisterAssembly(
            this.GetType().Assembly, AssemblyRegistrationFlags.SetCodeBase))
        {
            throw new InstallException("Failed to register componenet for COM interop");
        }
    }
    catch
    {

    }
}

And then create a Custom Action in your MSI that points to the Primary Output for Install, Uninstall and Rollback. This actually works pretty well, and I was happy with it.

Well when this problem happened for the second time just this week when I switched my Outlook2OneNote project structure from being a simple Project that had all the logic to one that inherited from another class in another project I started wondering and thinking this has to be a bug. Well using my super hero powers I tracked this problem down and found a better work around.

Additionally, I've been told that custom actions should be avoided for a number of reasons. One good reason is that if you ever use the MSI in the future to upgrade your assembly, it will fail.

Approach 2: Simple workaround for bug

Rather than adding the Primary Output of the project that needs to be registered for COM Interop, do the following:

  1. In your setup project remove the Primary output from <Project Name>.
  2. Select your setup project, right click, select Add->Assembly
  3. Navigate to the bin/Release directory of your Primary project and select your dll
  4. Select the Assembly in the setup project and set the Register value to vsdraCOM

Summary

By adding your assembly directly to the MSI and not relying on the Custom Action workaround mentioned above, you can rely on the MSI to register your component for COM Interop.

BTW – IMHO, developing .NET components and exposing them as COM components is a nasty business and one that I NO LONGER ENJOY!!! I am writing this because it’s a bit therapeutic and I hope it helps someone else who is having this problem (rather than hurl my laptop against the wall).

update: I made some corrections to this post based on some feedback from Rob Mensching.

Posted Wednesday, April 28, 2004    Permalink    Comments [10]  View blog reactions

 

# Monday, April 26, 2004

Send to OneNote from Outlook PowerToy

At long last, my PowerToy is live! Send to OneNote from Outlook lets you send Mail, Post items and Sticky Notes to OneNote (note, this was previously called Outlook2OneNote).

While you are there I also recommend Send to OneNote from Internet Explorer.

Both of these use the OneNoteImporter that Donovan created.

A lot of folks at Microsoft were instrumental in dogfooding the product as well as answering my never ending questions about managed programmability in Office 2003. Special thanks to Siew Moi Khor and Misha Shneerson for showing me the light.

Note, if you install this PowerToy and you do not see the toolbar icons in your Outlook standard toolbar this is because the Outlook 2003 .NET Programmability Support is not enabled. To fix this you must:

  1. Uninstall the PowerToy if you have already installed it
  2. From the Start menu, select Control Panel, and click Add/Remove programs.
  3. Select Microsoft Office Professional Edition 2003, and then select Change.
  4. Select Add or Remove Features and click Next.
  5. Click Chose advanced customization of applications.
  6. Expand Microsoft Office Outlook, and confirm .NET Programmability Support is set to Run from My Computer.

Posted Tuesday, April 27, 2004    Permalink    Comments [13]  View blog reactions

 

# Sunday, April 25, 2004

Programming for Outlook using managed code is hard

Background

Programming for Outlook using managed code is hard. I take that back. Programming for Outlook is relatively easy if you can figure out where to stick your code. Working out the problems you’ll encounter is hard (and I’m still working on them). I’ll try and give you some best practices. There will actually be some follow up to this specifically on:

  1. How to keep your objects from going out of scope
  2. How to prevent the dreaded security pop-up in Outlook from appearing.

You aren't the only managed add-in

The hardest part to getting your addin to work is to be enlightened. You see, your add-in may work very well if it's the only add-in installed. However, if there are any other add-ins installed, and there are many excellent add-ins, your add-in may fail to load. Some of the reasons your add-in may fail to load are:

  1. Another add-in is installing the Office 2003 Primary Interop Assemblies in their own application directory.
  2. Another add-in is using a private version of the Office XP Primary Interop Assemblies that conflicts with the version that you are loading. Depending on an number of factors, your assumption that the set of assemblies you targeted will not be loaded.
  3. Another add-in installed a version of the Office PIAs in the GAC that are incompatible with yours, or, are getting loaded in place of the assemblies you targeted.
  4. Another add-in is calling Release COM Object and you are getting hosed (see http://blogs.officezealot.com/whitechapel/ for even more info on the subject).
  5. Some other reason that I am sure exists and I am not aware of.

You have no control

So, given these things it seems to me that it's really difficult to have a lot of control over your deployment given the eco system for managed add-ins out there. Bottom line, other products and add-ins can invariable affect you whether you like it or not. The only sure way to protect yourself is to implement a shim as outlined in this article. I've forgone the shim route because I find it overly complicated and to me it taints the whole .NET developer experience I've grown to love. Everything else is so darn simple and elegant why does this have to be so hard? That article is about 14 pages and the other 15 pages of reading to get your own AppDomain. Not to mention C++ code (I don't do C++). It's wonderful that we publish a documentation on how to get your own AppDomain but I don't currently know what my own AppDomain will buy me.

However, even if you go the shim route, there is nothing preventing another application from messing with the Interop Assemblies and horking your assumptions about what you've targeted.

Office XP PIAs, Office 2003 PIAs Oh My!

To make things even more complicated, you are only supposed to use the Office 2003 PIAs for Office 2003, and the XP PIAs for Office 2000 and Office XP. If you read this article, you'll find this statement:

"Microsoft does not guarantee that the Office PIAs will be backwardly compatible or that the Office XP PIAs and the Office 2003 PIAs can be run side-by-side in the same instance of an Office application. Office XP managed code add-ins must be built against the Office XP PIAs. The Office 2003 managed code add-ins must be built against the Office 2003 PIAs. Therefore, if you build an add-in solution that you intend to use with both versions of Office, Microsoft recommends that you build a version of your add-in for each version of Office that you intend to support."

So, what this basically means to me is that if my add-in fails to load because I'm using the Office 2003 PIAs and Application Y is using the Office XP PIAs, my only recourse is to convince the developer of Application Y to stop doing this. Meanwhile the developer of Application Y is like, huh? You mean I have to target and test against two different versions of the PIAs for 3 different versions of Office? And to make matters worse, it's actually more like Developer A, B, C, D, E, F and G and so on. From what I can tell there are very few add-ins that target or install the Office 2003 PIAs... although I know of at least two. Finally it seems that if one add-in loads the 2003 PIAs and one loads the XP PIAs bad things can happen.

I started building my add-in by creating the Shared Add-in project in VS.NET 2003. By default, if you are using Office 2003, the PIAs will get added to your setup and installed in your App directory. This is a No-No and to make matters worse, you can really mess things up for other add-ins when your add-in is uninstalled. When I stopped installing the PIAs (after a few dozen people installed my add-in) problems started to ensue. I spent many days with Kent Compton as my willing guinea pig tracking down (Thanks Kent!). I also spent some time discussing this with many fine folks who work on this stuff in Office. The end result was that the only way I could get Kent's issues resolved (as well as some I was having) was to remove my dependency on the Office 2003 PIAs and instead rely on the Office XP PIAs (I found this out after 40 or so hours of trial and error and lots of head scratching as well as some conversations I've had with Mike who works on Lookout). So far (knock on wood) this works well for him and I'm able to use Lookout, and Newsgator without any problems. However, this solution is not a silver bullet and not something I plan on doing long term. I will go the shim route and load my add-in into it's own AppDomain and link to the Office 2003 PIAs.

What to do?

So where does this leave the managed Office add-in developer? I just close my eyes and hope for the best. To me the managed add-in eco system is a bit like a public swimming pool. There are a set of posted rules, but there is no one really there to "police" the rules being enforced... anyone can swim in the pool and not everyone will be barred from entering the pool because they didn't shower before hand. This is a far cry from doing Windows Forms programming or ASP.NET development.

How it should work

Based on what I've learned, and my limited knowledge of COM and the Office Object Model, if I could change this here is what I would do:

  1. Give each add-in it's own AppDomain
  2. Ship a set of PIAs for Office that go into the GAC during the default installation that work against Office 2000, Office XP and Office 2003 (as well as the next version of Office). Don't make me worry about installing any necessary Interop Assemblies or what version of Office is installed.
  3. Make this as easy as developing a Windows Forms app, Class library or Console App.
  4. Add better intellisense for the Office properties, methods, and classes (as well as integrated VS.NET help) - I just had to throw this one in there ;-).

Why this matters to me

You may wonder why I care about all this stuff. Well I am working on an Add-in for OneNote called Outlook2OneNote. This add-in will allow you to copy items from Outlook such as e-mail, notes and post items into OneNote for annotating and archiving or whatever. I am also working on a simple Office Button SDK with Dan Crevier that will allow you to easily create buttons, popup buttons and combo boxes in Office toolbars that react to the Click event allowing you to do all sorts of nifty things.

BTW, here are a list of managed Outlook Add-ins that I know of:

  • Newsgator - RSS Aggregator
    • Office XP PIA installed in GAC (thanks for the correction Greg!)
  • DataLens - nifty calendar view
    • Office 2003 PIA installed in GAC
  • Tablet Enhancement Pack for Outlook - use your pen to create tasks, appointments and contacts
    • Office 2003 PIA not installed in GAC
  • Lookout - fast search tool for Outlook
    • Latest version: Office XP PIA installed in GAC
    • Current version: Office XP PIA not installed in GAC

I have a few more things to try to feel sure that my add-in will work in the real world. Preliminary results indicate that ditching the Office 2003 PIA for the XP PIA was the ticket, but I have something else to try before I can be confident. Also, I've had cases where things worked, failed and then worked on my own machine and I don't have any explanation for why. I'm going to have to mess around with Virtual PC to test out some theories of mine as my current machines aren't good "testing" environments any more!

update: while using the Office XP Interop Assemblies seemed like a silver bullet, it's not the "right solution". The right solution is to use the 2003 PIAs and write a Shim that will give me my own AppDomain and insulate me from other add-ins. See this post on the my thoughts on creating and using a Shim for Outlook2OneNote.

Posted Monday, April 26, 2004    Permalink    Comments [5]  View blog reactions

 

# Saturday, April 24, 2004

SeaTac sucks

SeaTac has the lamest TSA of any airport I've been to (BOS, JFK, DFW, IAD, SFO, SJC, ORD) recently. For the past two weeks I have returned from SeaTac on a Friday (both afternoon and evening). Both times the lines were 30+ minutes and they were operating less than half the scanners. Unbelievable. I don't understand why that airport is so freaking inefficient. Oh, and Dennis agrees.

I'll also add that there is no good food joint inside the security area. Mickey Mouse airport if you ask me. If they ever move the rental car area outside the main terminal area (like having to take a bus to the cars etc) then I'll just stop going ;-).

Posted Sunday, April 25, 2004    Permalink    Comments [9]  View blog reactions

 

AssemblyVersion build and revision number

The other day I was wondering where the AssemblyVersion build and revision numbers come from if you use the default synax in your AssemblyInfo files:

//
// Version information for an assembly consists of the following four values:
//
// Major Version
// Minor Version
// Revision
// Build Number
//
// You can specify all the value or you can default the Revision and Build Numbers
// by using the '*' as shown below:

[assembly: AssemblyVersion("1.0.*")]

Well it turns out that the build number is set to the number of days since a
random, designated start date, and the revision based on the number of
seconds since midnight.

It's interesting that it took 15 or so minutes on google to find this post that has this little nugget.

Posted Sunday, April 25, 2004    Permalink    Comments [1]  View blog reactions

 

# Tuesday, April 20, 2004

OneNote SP1 Preview Rocks

Chris Pratley has a write up on OneNote SP1 Preview. This is a huge upgrade and has lots and lots of new features. I've been running it for a few months now and love it.

Here are my favorites:

  1. Capture Screen Shots and Snippets.
  2. Scratch Out Gesture for Ink.
  3. Password Protection of Sections.
  4. Insert Meeting details from Outlook.
  5. Data Import API (I am writing two of the PowerToys that Chris talks about) ;-) and collaborating on a nice .NET managed API that hooks into OneNote's API.
  6. Lots and lots of Inking improvements. Inking feels much more natural.
  7. Insert pictures and documents.

Posted Tuesday, April 20, 2004    Permalink    Comments [1]  View blog reactions

 

# Friday, April 16, 2004

Creating Managed Outlook Buttons with Icons

I've been working on an Outlook Add-in in C# using the Visual Studio Shared Add-in project. I referenced this article on how to create a custom icon for your button: Custom Button Faces in a Managed Code Add-in for the Microsoft Office System

In addition to this article, most of the information I've seen on the internet and msdn discusses how to set the icon of a button (CustomFace) using the clipboard and calling CommandBarButton.PaseFace(). How ugly. Furthermore, if you do this then you cannot avoid the problems of the mask not getting applied (which looks really ugly, see the screenshot from the MSDN article).

You also  have to deal with issues such as saving and restoring the clipboard contents so that the user does not lose data.

If you are using Outlook 2003 there is a much better way. Here is how you do it:

Create Project

This article assumes you've created a Shared Add-in project already. For a good overview of this see http://blogs.msdn.com/dancre/archive/2004/03/21/93712.aspx

Create Bitmaps of Icons

  1. Using your favorite bitmap editor (I just use mspaint.exe) create a bitmap that is 16x16 px and paste in the icon you wish to use.
  2. Again, using the same bitmap editor create a second bitmap for the mask. This bitmap should contain white for any region that you want to appear transparent, and use RGB (0,255,0) for any area that you want to appear in the CommandBarButton.

    For example, say we want to use the Bold icon. You would create a bitmap like this:

    And the mask would look like:

     

  3. Save both the bitmap as "bold.bmp" and "bold_mask.bmp".

Create Resource Files

Now we want to add these two bitmaps to a resource file that we can embed in our assembly. I used the instructions on Custom Button Faces in a Managed Code Add-in for the Microsoft Office System with some modifications.

Build the Resource Editor that ships with Visual Studio

  1. Go to localdrive:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Samples\Tutorials\resourcesandlocalization\reseditor
  2. Run build.bat

To add items to a resource file by using the Resource Editor:

  1. In the Resource Editor, in the Add section, select System.Drawing.Bitmap as the type of item to add to the resource file from the drop-down list.
  2. In the text box to the right of the Add section, type bold as the name of the first item to add. This enables the Add button.
  3. Click Add.
  4. Type bold_mask as the name of second item to add and then click Add.
  5. Next, click File and then click Save As. . .
  6. Type IconResource.resX as the name for the project and browse to the parent directory of the sample add-in project.
  7. In the Save as type list, select ResX Files (*.resX) and then click Save to save the resource file
  8. Close the Resource Editor.

Add the resource file to your project, and set the Build Action to Embedded Resource.

Create the Buttons and set the Picture and Mask properties

Now we can create the buttons and set the Picture and Mask properties of the CommandBar. However, you cannot just use this code:

object missing = Missing.Value;
 
CommandBarButton outlookButton = (
CommandBarButton)commandBars["Standard"].Controls.Add(
MsoControlType.msoControlButton, missing, missing, missing, true);

toolbarButton.Style = button.ButtonStyle; try { ResourceManager rm = new ResourceManager( this.GetType().Namespace + ".IconResource", this.GetType().Assembly); using (Bitmap bmp = (Bitmap)rm.GetObject("bold")) { if (bmp != null) outlookButton.Picture = bmp; } using (Bitmap bmp = (Bitmap)rm.GetObject("bold_mask")) { if (bmp != null) outlookButton.Mask= bmp; } } catch { }

You see CommandBar.Picture and CommandBar.Mask do not accept bitmaps, but an instance of stdole.IPictureDisp. Great, so how does one create such an object? Not so easy. Thanks to this article though there is a solution. First you need to create this class:

using System;
using System.Drawing;
using System.Windows.Forms;
using stdole;
public class AxHost2 : AxHost
{
    public AxHost2() : base(null)
    {
    }
    public new static IPictureDisp GetIPictureDispFromPicture(Image image)
    {
        return (IPictureDisp)AxHost.GetIPictureDispFromPicture(image);
    }
}

This class inherits from System.Windows.Forms.AxHost which has a protected member GetIPictureDispFromPicture which will return an IPictureDisp  from an Image. So now that we have this class, we can modify the code above to read like so:

using (Bitmap bmp = (Bitmap)rm.GetObject("bold"))
{
    if (bmp != null) outlookButton.Picture = 
     (IPictureDisp)AxHost2.GetIPictureDispFromPicture(bmp);
}
using (Bitmap bmp = (Bitmap)rm.GetObject("bold_mask"))
{
    if (bmp != null) outlookButton.Mask= 
     (IPictureDisp)AxHost2.GetIPictureDispFromPicture(bmp);
}

And that's it. Now you don't have to use the Cliboard and PasteFace to create your icons.

Posted Saturday, April 17, 2004    Permalink    Comments [8]  View blog reactions

 

Bay Area real time traffic

http://www.zipdash.com/map/?city=94043

Posted Friday, April 16, 2004    Permalink    Comments [0]  View blog reactions

 

Office 2003 Primary Interop Assemblies Installation

I'm working on a cool Outlook .NET Add-in that target the Office 2003 PIAs. I just read this post from Brad Abrams that points to this new article which discusses designing Office XP add-ins and Office 2003 add-ins by using the .NET Framework.

Well imagine my horror when I read this:

You may redistribute Office XP PIAs. When you redistribute an Office XP PIA, you must install the Office XP PIA in the GAC. However, you must not deploy an Office 2003 PIA. When you build an add-in that targets Office 2003, you must exclude the Office 2003 PIAs from the Setup project. When the add-in loads in the target Office 2003 application, the add-in will correctly use the PIAs in the GAC at runtime. The add-in will correctly fail if the PIAs are not found in the GAC. The add-in will not fall back to load any other version of the PIA.

Crap! I thought. Correctly fail? Gee how nice. Can't I make it easy for my users to use my add-in? You see the PIAs are not installed by default when you do a typical setup of Office 2003. I don't really understand why they aren't, *but* it appears that they will get installed on-demand. Assuming that you have you local cab installation files for Office 2003 cached, or easy access to the CD or share where the files are located, Outlook will go and install the PIAs when your add-in loads for the first time.

I need to double check this on a clean machine (will use Virtual PC for that) and make sure that this is correct. If it is then I'm psyched. If not, then I'll be pretty pissed cause it's quite a pain to install them and telling end users to do that is just a headache.

Posted Friday, April 16, 2004    Permalink    Comments [2]  View blog reactions

 

# Wednesday, April 14, 2004

Dictionary Tool update and source

I've been meaning to get to this for a long time, and finally did.

I created a GDN Workspace for Dictionary Tool for Tablet PC. This is a Tablet PC PowerToy that I released last year. It was the first .NET code I had ever written and a few months ago I went back in there and fixed a few bugs, and ported it to C# from VB.NET. It's amazing how much I've learned in that time so I re-wrote a bunch of silly things (looking at your old code is funny some times).

Anyway, the most notable changes are:

  • Supports importing of txt files that have non ASCII characters correctly.
  • Support Backup of your custom user dictionary.
  • Support Restore of your backup to the user dictionary.
  • The UI looks like an XP App (back then I didn't know about Application.EnableVisualStyles();
  • Only works with .NET Framework 1.1 (sorry, no time to test on 1.0).
  • Resizing and non standard Windows resolutions should be fixed.
  • Fixed a bug when entering an empty string into the add text field.

I haven't tested the app extensively, but it seems to work just fine ;-). If you have any problems with it please let me know or file a bug in the workspace.

You can download 1.0.1 from here.

Posted Thursday, April 15, 2004    Permalink    Comments [0]  View blog reactions

 

# Tuesday, April 13, 2004

NewsGator for Media Center

I've been using this for a few weeks and it's dammed cool. Check your RSS feeds while being a couch potato using Windows Media Center 2004. It even streams videos from feeds such as Channel 9.

Posted Tuesday, April 13, 2004    Permalink    Comments [0]  View blog reactions