none
Determining which monitor Excel is displayed on RRS feed

  • Question

  • I have a VSTO application that puts up a Windows Form (dialog) that should appear centred on the Excel application.  However, when I run this in a multiple monitor configuration 50% of the time the dialog appears on the "wrong" monitor.  For example, if I have a left and right monitor then Excel might be maximised on the right monitor and my dialog appears centred on the left monitor.  This is easy to miss and it looks like Excel has just hung for no reason as my dialog is modal.

    Is there any way to determine the Bounds of the Excel application, i.e. where it is being displayed?  This way I can force my dialog to always appear where it will be noticed.  I have tried the various Startup Position options for my Form and none of them work consistently.  I seem to get the best results with "Windows Default Location" but not 100% of the time.

    Thursday, October 13, 2011 9:24 AM

Answers

  • Hi Diksta,

    Actually it is very easy to implement it. We don't need to invoke Windows APIs; we don't need to know which monitor application shows on...

                Form1 dialog = new Form1();
                dialog.StartPosition = System.Windows.Forms.FormStartPosition.CenterParent;
                dialog.ShowDialog();
    

    I hope this helps


    Best Regards, Calvin Gao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Diksta Thursday, October 20, 2011 9:13 AM
    Wednesday, October 19, 2011 7:49 AM
    Moderator

All replies

  • Hi Diksta,

    Hmm...I don't know how to set this exactly. It seems that the Excel window always show in the place where it last closes. But I have successfully set a Form always appears within the Excel Window. You can have a try of following code:

            [DllImport("user32.dll", SetLastError = true)]
            static extern IntPtr SetParent(IntPtr hWndChild, IntPtr hWndNewParent);
    
            [DllImport("user32.dll", SetLastError = true)]
            static extern System.IntPtr FindWindow(string lpClassName, string lpWindowName); 
    
            private void button1_Click(object sender, RibbonControlEventArgs e)
            {
                Form1 f1 = new Form1();           
                IntPtr FormHandler = f1.Handle;
                IntPtr ExcelHandler = FindWindow(null, Globals.ThisAddIn.Application.Caption);
                SetParent(FormHandler, ExcelHandler);
                f1.Show();
            }
    


    The snippet code invokes FindWindow and SetParent API.

    I hope this helps.


    Best Regards, Calvin Gao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, October 14, 2011 7:23 AM
    Moderator
  • Hi Calvin,

    Well thanks for that - it works, sort of.  The problem is this:

    http://support.microsoft.com/kb/253814

    My dialog behaviour changes a lot, the title bar goes weird and the dialog becomes unusable without further changes as by default it can't receive focus for some reason.  So I am probably going to suffer the Excel and Dialog being on different monitors unless there is a better solution out there?

    Friday, October 14, 2011 9:31 AM
  • Hi Diksta,

    Actually it is very easy to implement it. We don't need to invoke Windows APIs; we don't need to know which monitor application shows on...

                Form1 dialog = new Form1();
                dialog.StartPosition = System.Windows.Forms.FormStartPosition.CenterParent;
                dialog.ShowDialog();
    

    I hope this helps


    Best Regards, Calvin Gao [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    • Marked as answer by Diksta Thursday, October 20, 2011 9:13 AM
    Wednesday, October 19, 2011 7:49 AM
    Moderator
  • Yes, that worked perfectly - and no Windows DLLs to reference which has to be an improvement!

    Many thanks for this.

    Thursday, October 20, 2011 9:13 AM