none
Outlook 2010 plugin wrong 32770 window RRS feed

  • Question

  • I'm developing a custom address dialog for Outlook 2010, following the sample of Helmut Oberdan published here

    http://www.codeproject.com/Articles/21288/Customize-the-built-in-Outlook-Select-Names-dialog

    I've migrated the project to VS2015 with framework 4.5 but I'm in trouble with the findwindow function

    IntPtr hBuiltInDialog = WinApiProvider.FindWindow("#32770", "");

    on some computer (mine) works well and on some other (customer) it doesn't. It seems that the function finds another 32770 window that is not the Outlook's one, I've tryed to enumerate all the 32770 windows but when the InspectorWrapper_Deactivate function fires up, my 32770 window is not present in the list. A strange behavior occurs, if I put a messagebox in the deactivate function it pops up twice and after the second time the right window gets catched and my custom dialog opens.

    Here is the InspectorWrapper_Deactivate function

    <code>

    void InspectorWrapper_Deactivate()
    {
        _showOwnDialogOnActivate = false;
        // If there is an invisible ghost Window out there - close it
        if (_hWndInvisibleWindow != IntPtr.Zero) WinApiProvider.SendMessage(_hWndInvisibleWindow, WinApiProvider.WM_SYSCOMMAND, WinApiProvider.SC_CLOSE, 0);

        IntPtr hBuiltInDialog = WinApiProvider.FindWindow("#32770", "");
        if (hBuiltInDialog != IntPtr.Zero)
        {
            // ok, found one
            // let's see what childwindows are there
            List<IntPtr> childWindows = WinApiProvider.EnumChildWindows(hBuiltInDialog);
            // Let's get a list of captions for the child windows
            List<string> childWindowNames = WinApiProvider.GetWindowNames(childWindows);

            //MessageBox.Show("Contact");

            // now check some criteria to identify the build in dialog..
            int languageId = Inspector.Application.LanguageSettings.get_LanguageID(Microsoft.Office.Core.MsoAppLanguageID.msoLanguageIDUI);
            switch (languageId)
            {
                case 1040:
                    // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
                    // !!! This part is only valid for italian Outlook 2007 Version !!!
                    // !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
                    if (!childWindowNames.Contains("Solo n&ome")) return;
                    if (!childWindowNames.Contains("Altre &colonne")) return;
                    if (!childWindowNames.Contains("R&ubrica")) return;
                    break;
                default:
                    return;
            }
            // OK - we have the built in Recipient Dialog
            // Create a new invisible window
            _hWndInvisibleWindow = WinApiProvider.CreateWindowEx(0, "Static", "BriaSOFT", 0, 0, 0, 0, 0, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero, IntPtr.Zero); 

            // use this window as new Parent for the original Dialog
            WinApiProvider.SetParent(hBuiltInDialog, _hWndInvisibleWindow);

            WinApiProvider.SendMessage(hBuiltInDialog, WinApiProvider.WM_SYSCOMMAND, WinApiProvider.SC_CLOSE, 0);
            // When our INspector becomes active again, we should show our own Dialog
            _showOwnDialogOnActivate = true;
        }
    }

    </code>

    any suggestion will be really appreciate. Thanks Flavio

    Saturday, August 6, 2016 7:32 AM

Answers

  • Thanks for your suggestion, the customer wants a behavior like the standard Outlook one, but with a different dialog for choosing the contact, with more filters and columns.

    I've tryed the solution with a background thread, started from the inspector, and auto terminated once the window is found and seems that this solution works fine.

    Thanks

    Bianchi Flavio

    • Proposed as answer by David_JunFeng Thursday, August 11, 2016 2:00 PM
    • Marked as answer by David_JunFeng Wednesday, August 31, 2016 9:53 AM
    Monday, August 8, 2016 8:46 AM

All replies

  • #32770 is the Windows class for a dialog box.  Perhaps the Outlook dialog that you are hoping to find has not been created when you call FindWindow.  It could be a timing issue.  The design assumes that the Outlook dialog will already exist when the add-in receives the Deactivate event.  Perhaps you can figure out a way to definitively know when that Outlook dialog is created.

    None of this  "hacking into Outlook", as the codeproject author described it, is supported by Microsoft.

    • Edited by RLWA32 Saturday, August 6, 2016 2:07 PM
    Saturday, August 6, 2016 11:26 AM
  • Thank you very much for the answer, I think you are right, I'm trying to find the window while it is not available yet. Can you suggest me a different way to substitute the standard outlook address window supported by microsoft?

    Thanks again

    Bianchi Flavio

    Sunday, August 7, 2016 7:27 AM
  • My first suggestion is to consider moving away from the idea of "replacing or substituting" the standard Outlook address window.  If you want to provide additional functionality you can place a button on the Inspector's ribbon that invokes your add-in's address dialog. That would avoid all of the unsupported and fragile techniques necessary to work around standard Outlook behavior.

    If you still want to substitute dialogs then one possibility would be to use a background thread to do the searching for the standard Outlook address dialog instead off of relying on the timing of Outlook events .  When the thread finds the dialog it could notify the add-in which would take the necessary steps to perform the substitution. Of course you would have to ensure that the background thread doesn't run indefinitely if it fails to find the Outlook dialog within some reasonable limits that you set.

    • Proposed as answer by David_JunFeng Thursday, August 11, 2016 1:59 PM
    Sunday, August 7, 2016 10:07 AM
  • Thanks for your suggestion, the customer wants a behavior like the standard Outlook one, but with a different dialog for choosing the contact, with more filters and columns.

    I've tryed the solution with a background thread, started from the inspector, and auto terminated once the window is found and seems that this solution works fine.

    Thanks

    Bianchi Flavio

    • Proposed as answer by David_JunFeng Thursday, August 11, 2016 2:00 PM
    • Marked as answer by David_JunFeng Wednesday, August 31, 2016 9:53 AM
    Monday, August 8, 2016 8:46 AM
  • Thanks for your suggestion, the customer wants a behavior like the standard Outlook one, but with a different dialog for choosing the contact, with more filters and columns.

    I've tryed the solution with a background thread, started from the inspector, and auto terminated once the window is found and seems that this solution works fine.


    You're welcome.  I'm glad that the background thread idea worked for you.
    Monday, August 8, 2016 9:32 AM