0

So there is a beautiful technique for acquiring a COM pointer cross-process (same machine) from an Excel.exe session if you know its Hwnd using the Accessibility API. The specific Windows API function is AccessibleObjectFromWindow; if called with parameter of OBJID_NATIVEOM then Excel.exe marshals back a COM pointer to an Excel.Window object. Very cool.

So I was wondering if developers can implement the same technique for their own applications. The answer is yes, they respond to a certain message, WM_GETOBJECT, in their message pump code. Whilst this is doable for a C++ application, I am puzzled as how to do this for a C# application.

I'm presuming the answer is to do something to get access to the message pump handling code and alter it. It maybe the case that some magic attribute could be used. I'm open to either technique so long as it works.

Here is the code that acquires COM pointer from Excel

    [DllImport("user32.dll", SetLastError = true)]
    static extern IntPtr FindWindowEx(IntPtr hwndParent, IntPtr hwndChildAfter, string lpszClass, string lpszWindow);


    [DllImport("oleacc.dll", SetLastError = true)]
    internal static extern int AccessibleObjectFromWindow(IntPtr hwnd, uint id, ref Guid iid,
                                                [In, Out, MarshalAs(UnmanagedType.IUnknown)] ref object ppvObject);

    bool IXlMoniker.GetExcelByHwnd(int lhwndApp2, ref object appRetVal)
    {
        bool bRetVal = false;

        IntPtr lhwndApp = (IntPtr)lhwndApp2;

        IntPtr lHwndDesk = FindWindowEx(lhwndApp, IntPtr.Zero, "XLDESK", "");
        if (lHwndDesk != IntPtr.Zero)
        {

            IntPtr lHwndExcel7 = FindWindowEx(lHwndDesk, IntPtr.Zero, "EXCEL7", null);
            if (lHwndExcel7 != IntPtr.Zero)
            {
                Guid IID_IDispatch = new Guid("{00020400-0000-0000-C000-000000000046}");
                const uint OBJID_NATIVEOM = 0xFFFFFFF0;
                object app = null;
                if (AccessibleObjectFromWindow(lHwndExcel7, OBJID_NATIVEOM, ref IID_IDispatch, ref app) == 0)
                {
                    dynamic appWindow = app;
                    appRetVal = appWindow.Application;
                    return true;
                }
            }
        }
        return bRetVal;
    }

This looks promising Return an IOleCommandTarget from processing WM_GETOBJECT in a NativeWindow

S Meaden
  • 8,050
  • 3
  • 34
  • 65
  • The GUI class library you use matters. For a Winforms app override the main form's WndProc() method. Marshal.GetIUnknownForObject() to generate the interface pointer. But .NET does not support an out-of-process server well, you can't tell that another process is still using the interface pointer that you give back so letting your app terminate is risky. – Hans Passant Oct 30 '18 at 15:49
  • @HansPassant : ok. thanks. – S Meaden Oct 30 '18 at 15:50
  • The WinForm Control Class has an [implementation for handling WmGetObject](https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/Control.cs,ecce3140106ed690). If the control receives an ObjectID other than OBJID_CLIENT or OBJID_WINDOW, it will call the Control.GetAccessibilityObjectById(Int32) Method(https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.control.getaccessibilityobjectbyid?view=netframework-4.7.2) that you could override to provide your own implementation. You can also override the Control.CreateAccessibilityInstance Method. – TnTinMn Oct 31 '18 at 15:16
  • If the end-game is to expose a .Net method to COM, I would suggest just using the techniques already exposed by .net instead of hacking the accessibility mechanism. As a starting point, see: [Example COM Class (C# Programming Guide)](https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/interop/example-com-class). – TnTinMn Oct 31 '18 at 15:21

0 Answers0