IOleWindow not working properly for IFileDialog?
up vote
0
down vote
favorite
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??
c# com common-dialog
add a comment |
up vote
0
down vote
favorite
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??
c# com common-dialog
A usable IOleWindow declaration is available here. Getting the methods is the wrong order is quite fatal.
– Hans Passant
2 days ago
Thanks very much! Trying it now.
– Jonathan Gilbert
2 days ago
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
2 days ago
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
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??
c# com common-dialog
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??
c# com common-dialog
c# com common-dialog
asked 2 days ago
Jonathan Gilbert
2,5291320
2,5291320
A usable IOleWindow declaration is available here. Getting the methods is the wrong order is quite fatal.
– Hans Passant
2 days ago
Thanks very much! Trying it now.
– Jonathan Gilbert
2 days ago
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
2 days ago
add a comment |
A usable IOleWindow declaration is available here. Getting the methods is the wrong order is quite fatal.
– Hans Passant
2 days ago
Thanks very much! Trying it now.
– Jonathan Gilbert
2 days ago
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
2 days ago
A usable IOleWindow declaration is available here. Getting the methods is the wrong order is quite fatal.
– Hans Passant
2 days ago
A usable IOleWindow declaration is available here. Getting the methods is the wrong order is quite fatal.
– Hans Passant
2 days ago
Thanks very much! Trying it now.
– Jonathan Gilbert
2 days ago
Thanks very much! Trying it now.
– Jonathan Gilbert
2 days ago
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
2 days ago
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
2 days ago
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53402466%2fiolewindow-not-working-properly-for-ifiledialog%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
A usable IOleWindow declaration is available here. Getting the methods is the wrong order is quite fatal.
– Hans Passant
2 days ago
Thanks very much! Trying it now.
– Jonathan Gilbert
2 days ago
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
2 days ago