none
How do I activate the Word window RRS feed

  • Question

  • I have a VSTO addin that opens a custom dialog form.

    [Edit: Windows 7, Office 2010, Visual Studio 2015.]

    When I open the form from a Toolbar (in a test function) it works well; the form opens, gets the focus, the user clicks a button, focus come back to Word, and the user can continue to type.

    But when I open the form from a keyscanning code I have running (hooked to WH_KEYBOARD), focus is not restored to the Word document when the form closes. The user has to click in the Word name list to start typing.

    That is weird in itself since the call to open the form is made in exactly the same way, with the exact same arguments, and if anyone has a suggestion for that issue it would interesting to hear that as well. But I digress - back to the issue at hand.

    I've been trying to fix the issue by activating the Word window with

    Globals.ThisAddIn.Application.Activate()

    , but it makes no difference. In a way I understand that, because the window name list looks like the application is already active. On the other hand, it works if the user manually clicks the name list - does that do anything else except activate Word?

    I have tried adding

    Globals.ThisAddIn.Application.Documents(1).Activate()

    as well (yes, I realize Documents(1) is not a longterm solution but in testing I only have one document open) but it makes no difference.

    After googling a bit, I've found the advice to use DoEvents, so I've tried adding

    System.Windows.Forms.Application.DoEvents()

    with no luck. Do I need to activate the application and/or document window differently? Set focus to something?

    [Edit: Oh yeah, this question is kind of a duplicate of https://social.msdn.microsoft.com/Forums/office/en-US/62d03be0-f4f5-49eb-9da2-63a8bd1b2a3f/how-do-i-make-the-word-window-active?forum=worddev#cdc371c1-be3a-4d01-9ca3-105677efb6b6 but that never got resolved, so...]

    Monday, December 14, 2015 5:07 PM

Answers

  • Hi Peter,

    >>But when I open the form from a keyscanning code I have running (hooked to WH_KEYBOARD), focus is not restored to the Word document when the form closes. The user has to click in the Word name list to start typing.<<

    Did you mean that you were developing with Windows API in the Office VSTO solution? If I understood correctly, this is not recommend. Would you mind sharing more detail about this scenario so that we can provide a alternative solution or a workaround?

    To set the focus for the Word document window, we can use Window.SetFocus method. And there are lots of shortcuts in Word, if the shortcuts is helpful to set the focus back into the document, we can also use SendKey to as a workaround.

    Keyboard shortcuts for Microsoft Word

    In addition, if you have problem about developing Windows API, I suggest that you reopen a new thread in General Windows Desktop Development Issues forum.

    Hope it is helpful.

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, December 15, 2015 3:16 AM
    Moderator
  • Did you mean that you were developing with Windows API in the Office VSTO solution?
    >If I understood correctly, this is not recommend. Would you mind sharing more detail
    >about this scenario so that we can provide a alternative solution or a workaround?

    Absolutely. I need to read the keyboard from VSTO; I'm building a solution not unlike Autocorrect, but with a user interface that optionally pops up and lets the user select from a set of words to replace the "wrong" one. And there's no keyboard events from Word. This is a fairly well discussed issue on the 'net, everyone seems to land at hooking into WH_KEYBOARD (or WH_KEYBOARD_LL), but any ideas are more than welcome.

    I understand why it's not recommended, I continue to hit stumbling blocks the whole time, but it seems to be the only way. And so far I managed to get out of all situations (knock on wood).

    And there are lots of shortcuts in Word, if the shortcuts is helpful to set the focus back
    > into the document, we can also use SendKey to as a workaround. 

    As you can see above, I already tried that (with Alt-Alt), but the keypresses did not go to Word.

    >To set the focus for the Word document window, we can use Window.SetFocus method.

    Thanks, this did indeed work, more specifically

    Globals.ThisAddIn.Application.ActiveWindow.SetFocus()
    > In addition, if you have problem about developing Windows API, I suggest that you
    > reopen a new thread in 
    General Windows Desktop Development Issues forum.

    Point taken. However, there is a huge difference between what members and methods are available from Globals.ThisAddIn.Application and what's available from the general Application object, and thus answers from general windows development people tend to not work in VSTO far too often, hence asking here. But I'm new to the forums, so I'm sure I'll learn to find my way around better eventually.

    Tuesday, December 15, 2015 9:01 AM

All replies

  • I found a "solution"; the following code works, with or without the Application.Activate():

    Dim state As Word.WdWindowState
    state = Application.ActiveWindow.WindowState
    Application.ActiveWindow.WindowState = Microsoft.Office.Interop.Word.WdWindowState.wdWindowStateMaximize
    Application.ActiveWindow.WindowState = state

    However, this flashes the Word windows quickly to Maximized and then back to Normal - this is NOT an acceptable solution, but it might be a hint to anyone else thinking about the problem? Also, if Word is already maximized, it does not work, although I'm sure it would "work" to minimize and then maximize back.

    Monday, December 14, 2015 5:34 PM
  • Here's another interesting effect, and maybe another clue? The user can activate the Word window by pressing Alt (which pops up the little "Alt-letters" in the menu), and then Alt again. That could be areasonable temporary workaround - at least the windows are not jumping about as they are with WindowState. However, sending two Alt keypresses from the addin using

    SendKeys.Send("{%}")
    SendKeys.Send("{%}")
    does not work. Maybe it would work to use another way to send keypresses to the Word window? Maybe using SendWindowMessage or something?
    Monday, December 14, 2015 8:03 PM
  • Hi Peter,

    >>But when I open the form from a keyscanning code I have running (hooked to WH_KEYBOARD), focus is not restored to the Word document when the form closes. The user has to click in the Word name list to start typing.<<

    Did you mean that you were developing with Windows API in the Office VSTO solution? If I understood correctly, this is not recommend. Would you mind sharing more detail about this scenario so that we can provide a alternative solution or a workaround?

    To set the focus for the Word document window, we can use Window.SetFocus method. And there are lots of shortcuts in Word, if the shortcuts is helpful to set the focus back into the document, we can also use SendKey to as a workaround.

    Keyboard shortcuts for Microsoft Word

    In addition, if you have problem about developing Windows API, I suggest that you reopen a new thread in General Windows Desktop Development Issues forum.

    Hope it is helpful.

    Regards & Fei


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, December 15, 2015 3:16 AM
    Moderator
  • Did you mean that you were developing with Windows API in the Office VSTO solution?
    >If I understood correctly, this is not recommend. Would you mind sharing more detail
    >about this scenario so that we can provide a alternative solution or a workaround?

    Absolutely. I need to read the keyboard from VSTO; I'm building a solution not unlike Autocorrect, but with a user interface that optionally pops up and lets the user select from a set of words to replace the "wrong" one. And there's no keyboard events from Word. This is a fairly well discussed issue on the 'net, everyone seems to land at hooking into WH_KEYBOARD (or WH_KEYBOARD_LL), but any ideas are more than welcome.

    I understand why it's not recommended, I continue to hit stumbling blocks the whole time, but it seems to be the only way. And so far I managed to get out of all situations (knock on wood).

    And there are lots of shortcuts in Word, if the shortcuts is helpful to set the focus back
    > into the document, we can also use SendKey to as a workaround. 

    As you can see above, I already tried that (with Alt-Alt), but the keypresses did not go to Word.

    >To set the focus for the Word document window, we can use Window.SetFocus method.

    Thanks, this did indeed work, more specifically

    Globals.ThisAddIn.Application.ActiveWindow.SetFocus()
    > In addition, if you have problem about developing Windows API, I suggest that you
    > reopen a new thread in 
    General Windows Desktop Development Issues forum.

    Point taken. However, there is a huge difference between what members and methods are available from Globals.ThisAddIn.Application and what's available from the general Application object, and thus answers from general windows development people tend to not work in VSTO far too often, hence asking here. But I'm new to the forums, so I'm sure I'll learn to find my way around better eventually.

    Tuesday, December 15, 2015 9:01 AM