0

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??

Jonathan Gilbert
  • 3,526
  • 20
  • 28
  • 1
    A usable IOleWindow declaration is [available here](https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/UnsafeNativeMethods.cs,1edd0ef1d9063485). Getting the methods is the wrong order is quite fatal. – Hans Passant Nov 20 '18 at 23:23
  • Thanks very much! Trying it now. – Jonathan Gilbert Nov 20 '18 at 23:25
  • As I'm sure you already knew, that was the problem exactly. If you feel like submitting an answer, even as little as "The order of methods in a COM interface is important, and the order in your IOleWindow declaration is wrong", I'll be happy to mark it as the answer. :-) – Jonathan Gilbert Nov 21 '18 at 00:06

1 Answers1

1

@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. :-) )

Jonathan Gilbert
  • 3,526
  • 20
  • 28