IOleWindow not working properly for IFileDialog?

383 views Asked by At

I'm working with some code that uses Microsoft.WindowsAPICodePack to provide a C# wrapper of the Vista-style common dialogs (IFileOpenDialog, IFileSaveDialog). I'm wanting to add validation of the selected item in the OnFileOk event callback, and this is mostly working, but one aspect of it is to extract the HWND of the dialog to use as a parent for the message box that is shown. Microsoft provides documentation on how to do this:

The calling process can use the window handle of the dialog itself as the parent of the UI. That handle can be obtained by first calling IOleWindow::QueryInterface and then calling IOleWindow::GetWindow with the handle as shown in this example.

(https://msdn.microsoft.com/en-us/library/windows/desktop/bb776913(v=vs.85).aspx)

I added a definition of the IOleWindow interface to the code:

[ComImport,
Guid(ShellIIDGuid.IOleWindow),
InterfaceType(ComInterfaceType.InterfaceIsIUnknown)]
internal interface IOleWindow
{
    [MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
    void ContextSensitiveHelp(
        [In] bool fEnterMode);

    [MethodImpl(MethodImplOptions.InternalCall, MethodCodeType = MethodCodeType.Runtime)]
    IntPtr GetWindow();
}

...

    internal const string IOleWindow = "00000114-0000-0000-C000-000000000046";

When I cast the IFileDialog passed into OnFileOk to IOleWindow (I haven't done that much work with COM interop recently, but this wraps a call to QueryInterface in the underlying COM world, right?), no error occurs and the IOleWindow reference is not null. But, when I call GetWindow, it seems to always return IntPtr.Zero. I have tried declaring the method with an out parameter instead of a return value, and get the same result: no error, but always IntPtr.Zero.

Does anybody see what I'm doing wrong?? Am I doing nothing wrong, but just sometimes you can't get a window handle??

1

There are 1 answers

0
Jonathan Gilbert On BEST ANSWER

@Hans Passant's reply was on the nose. The order of methods in a COM interface is important, and I had the order wrong, simple as that. I got the order from documentation that was sorted alphabetically, and not from the actual IDL. :-P

Wrong order, for human eyes only:

Right order, the actual IDL:

(I don't know who @tpn on GitHub is, this link may break but if it does then just look up IOleWindow in the file OleIdl.idl from the Windows SDK. :-) )