Ticklish Techs

I’m using a Lenovo laptop and I’m a big fan of the Trackpoint mouse replacement. That is this small red thing in the middle of the keyboard some notebooks are equipped with instead of a touchpad. In fact my notebook does not even has a touchpad.

You can use the Trackpoint for scrolling like a mouse wheel when pressing the middle button and moving the Trackpoint up or down. Everybody using it will know what I’m talking about, anybody else does not need to read to the end.

But in some applications the scrolling does not work at all what is very annoying. I had the most trouble with Thunderbird and iTunes – just no scrolling.

And here is a fix for that issue. There is a file (C:\Program Files\Lenovo\ TrackPoint\tp4table.dat) on your machine when you have installed the Trackpoint software from Lenovo. Just edit that file and add some additional rows for the application with broken scrolling.

; Apple ITunes
*,*,itunes.exe,*,*,*,WheelStd,0,9

; Mozilla Thunderbird
*,*,thunderbird.exe,*,*,*,WheelStd,0,9

Remember to open the file with an editor as Administrator otherwise it would not work. I had to reboot my machine after that change. I just tested this change on a Windows 7 64 bit machine but it should work on 32 bit or other versions of Windows as well. Maybe the same fix applies also to non-Lenovo notebooks but I cannot tell. If someone out there tested it, please comment.

More on this topic and templates for some more applications (Picasa, Safar, Windows Live Mail, Windows Live Writer) can be found at http://forums.lenovo.com/t5/X-Series-ThinkPad-Laptops/Fixing-Trackpoint-Scroll-for-ITunes-Picasa-Safari-Windows-Live/m-p/124378

When building applications that mix WPF and Winforms windows (e.g. because you are using a Winforms dialog within a WPF application) you will sometimes need a System.Windows.Forms.IWin32Window interface from an WPF System.Windows.Window. This will be useful when using the WinForms OpenFileDialog and wanting to provide a parent window to the ShowDialog() method that only accepts IWin32Window as parent.

The IWin32Window interface declares only one read-only property named Handle that must be provided by the WPF Window.

Implementing the Interface

It is very simple to just add this interface to an existing WPF Window and implementing the single property:

public partial class Window1 : Window, IWin32Window
{
   public IntPtr Handle
   {
      get
      {
         var interopHelper = new WindowInteropHelper(this);
         return interopHelper.Handle;
      }
   }
}

Using a wrapper class

It does not look as a very good solution to add such an interface to each and every Window in you whole application only to be able to be the parent of a dialog. So instead of implementing the interface directly you could build a wrapper class that implements this interface and use this wrapper when opening a dialog:

public class Wpf32Window : IWin32Window
{
    public IntPtr Handle { get; private set; }

    public Wpf32Window(Window wpfWindow)
    {
        Handle = new WindowInteropHelper(wpfWindow).Handle;
    }
}

Opening the dialog will now look like:

d.ShowDialog( new Wpf32Window(this) );

The grand solution to this problem

I like the wrapper solution more than implementing an interface to each and every window but I do not like the changed ShowDialog() call. It just does not look natural any more. To solve this I created an extension Method to be used with the wrapper class:

public static class CommonDialogExtensions
{
    public static DialogResult ShowDialog
                               (this CommonDialog dialog, 
                                     Window parent)
    {
        return dialog.ShowDialog(new Wpf32Window(parent));
    }
}

Now the call to open a WinForms dialog with an WPF parent looks as it should look like:

d.ShowDialog(this);

In fact one OpenFileDialog is enough but the .net framework provides two of them:

1. System.Windows.Forms.OpenFileDialog in System.Windows.Forms.dll
2. Microsoft.Win32.OpenFileDialog in PresentationFramework.dll (that is WPF)

With such a setup one would use the first for WinForms applications and the second for WPF apps. In fact if you create a WPF application and just type in OpenFileDialog you will get number 2.

But the 2nd one (even if it is part of the newer part of the framework) is an old dialog where the 1st will use the new and shiny Windows 7 dialog on Win7. Just look at the following screenshots.

Only the first class uses the Windows 7 dialog and comes with proper support for Libraries etc. Even if the second shows the Libraries in its left part it does not fully support this new Windows 7 feature.

I have no idea why the WPF class uses the old windows API but it does. For best compatibility with all Windows versions (including 7) you should always use the Winforms Dialog even when building WPF apps! It does not hurt to reference the System.Windows.Forms.dll (it is installed an every machine running the .net framework) and you can use that dialog from WPF without any trouble.

You should only know about one little disadvantage when using the WinForms dialog. It only accepts WinForms as a parent window no WPF windows. To overcome this limitation please read my other article about the IWin32Window interface and how to implement / provide it in WPF at http://www.ticklishtechs.net/2009/12/22/how-to-get-a-iwin32window-from-a-wpf-window/