0

I have an InnoSetup installer script that attempts to close any open Word windows before continuing installation by looking for top-level windows with the OpusApp class name. The script inadvertently also detects and closes Outlook compose windows because these open hidden Word windows which also has the OpusApp class name. (I use the WinLister utility to examine the open windows' class names.)

Is there any way I can distinguish between a "real" Word window and an Outlook compose window with a hidden Word window? If it involves invoking an extra tool from my installer script, I could probably handle that.

Hidden Word windows opened by Outlook, as seen by WinLister

By the way, when I let my installer close the OpusApp windows, an Outlook mail compose window will crash (i.e., the user cannot see and edit the text any more, but the text is not lost) -- quite an undesirable side effect of installing a Word add-in!

bovender
  • 1,838
  • 15
  • 31
  • 1
    Attemtping to close an open application is not a good idea. Even if it works with Word 2016, it may not work with Word 2017 because the window class name may then be "OpusApp2". I'd just detect if Word is open and ask the user to close Word before continuing. Many installers do it this way. – Jabberwocky Apr 05 '16 at 12:58
  • @MichaelWalz Point well taken, I'll think about it. On a side note: Office windows class names don't seem to change over the years, except for PowerPoint. But of course you're right, MS could decide to change it any time. – bovender Apr 05 '16 at 13:22
  • Why do you even need that? If the Word has some files locked, Inno Setup will detect that and close Word automatically. – Martin Prikryl Apr 05 '16 at 15:19
  • I agree with what Michael said, but... Check the title bar. A Word window will have the document name and "Microsoft Word" in it. (Of course, that, too could change in the future.) – Cindy Meister Apr 05 '16 at 17:27
  • @MartinPrikryl I'm installing a VSTO add-in. If the add-in registry keys are being set while the target Office application is running, the add-in will not be loaded the next time the application is started, and this confuses users. They expect the add-in to be active after installation (and restart of the Office application). – bovender Apr 06 '16 at 12:12
  • @CindyMeister Yes, checking the the title bar is one alternative... Unless some other VSTO add-in has changed `Application.Caption` already. – bovender Apr 06 '16 at 12:14
  • @MichaelWalz One more thought: If the installer only asks the user to shut down Word, but will continue installation despite the presence of `OpusApp` windows, the installation may fail in that the add-in that is being installed won't be loaded by Word. – bovender Apr 06 '16 at 12:17
  • @bovender see answer below, and you should proabably also check for the outlook process running (I don't know what the process name is). – Jabberwocky Apr 06 '16 at 12:20
  • @bovender to detect of word/ outlook are running, see [here](http://www.swissdelphicenter.ch/torry/showcode.php?id=294), it's Delphi, but translation to c/c++ shouldn't be a big deal. – Jabberwocky Apr 06 '16 at 12:22

2 Answers2

2

Look for the winword.exe processes instead of looking for a window with a particular caption or class name.

Dmitry Streblechenko
  • 62,942
  • 4
  • 53
  • 78
0

use FindWindow tool of Microsoft Spy++. Get latest documentation from https://learn.microsoft.com/en-us/visualstudio/debugger/introducing-spy-increment?view=vs-2022 for finding specific ClassName and Window Caption.

NIRMAL BISHT
  • 21
  • 4