{"id":2280,"date":"2016-05-02T09:00:33","date_gmt":"2016-05-02T16:00:33","guid":{"rendered":"http:\/\/www.coretechnologies.com\/blog\/?p=2280"},"modified":"2022-04-19T22:10:17","modified_gmt":"2022-04-20T05:10:17","slug":"dismiss-popups-dialog-boxes","status":"publish","type":"post","link":"https:\/\/www.coretechnologies.com\/blog\/windows-services\/dismiss-popups-dialog-boxes\/","title":{"rendered":"How to Automatically Dismiss Popups from a Windows Service"},"content":{"rendered":"
\"Outlook<\/div>\n

Why Windows Services Should Avoid Showing Popups\/Dialog Boxes<\/b><\/h2>\n

Unlike a regular application (like Microsoft Word) that you launch from a desktop icon and actively work with to accomplish a specific task, a Windows Service is designed to start when your computer boots and run entirely in the background — even if you never log on.<\/p>\n

Yet despite this design philosophy, there is no restriction that actually prevents a Windows Service from displaying windows and trying to interact with users logged on to the PC. Indeed, such “Interactive Services” were encouraged in Windows XP and Windows Server 2003, but Microsoft changed their tune in Windows Vista. In our opinion, a couple of glaring problems caused the folks in Redmond to reverse course and actively discourage Windows Services from trying to get the desktop user’s attention:<\/p>\n

    \n
  1. \n

    What happens when no one is logged on?<\/h3>\n

    It is unclear what should happen when a Windows Service shows a prompt and no user is there to answer it. Holding up the action while waiting for someone to log on and click a button can be problematic for tasks designed to perform important tasks, 24\/7.<\/p>\n<\/li>\n

  2. \n

    What happens when several users are logged on?<\/h3>\n

    When a service throws up a prompt, which of the multiple users logged on should be allowed to respond to that window? One? All?<\/p>\n<\/li>\n<\/ol>\n

    These thorny issues should discourage anyone from writing an interactive service today!<\/p>\n

    But what is you have inherited a legacy service implemented under the more permissive Windows XP or Server 2003 rules? What if commercial realities force you to run an interactive application as a windows service with a service wrapper like AlwaysUp<\/a>? How do you keep those services running without interruption, getting around annoying prompts that would otherwise stall an important process?<\/p>\n

    Three Ways to Automatically Dismiss Dialog Boxes and Popups<\/b><\/h2>\n
      \n
    1. \n

      Write a Custom AutoIt Script<\/h3>\n

      \nAutoIt<\/a> is a free scripting language designed for automating the Windows GUI. With this powerful tool, you can easily write scripts to activate windows, click buttons, check boxes, enter text and much more.\n<\/p>\n

      \nFor example, this AutoIt script clicks the “OK” button on a window named “OCR Error”:\n<\/p>\n

      <\/p>\n

      \n
      ; Try to bring the window to the top, to\r\n; prepare it for input.\r\nWinActivate<\/span>("OCR Error"<\/span>);\r\n \r\n; Click the OK button in the window.\r\nControlClick<\/span>("OCR Error"<\/span>, "OK"<\/span>, ""<\/span>);\r\n<\/pre>\n<\/div>\n
      \nNote that an AutoIt script can be compiled into an executable to run on any machine — even those without AutoIt installed.\n<\/p>\n<\/li>\n
    2. \n
      Buy Buzof, the “Annoying Windows Eliminator”<\/h3>\n
      \nBuzof<\/a> is a commercial utility that makes it easy for non-programmers to automatically answer Windows prompts. Its point and click interface enables you to “train” the software to take the appropriate action on those annoying popups. Here is what Buzof looks like when configured to watch for four popups, clicking the “Yes” or “No” buttons:\n<\/p>\n
      \"Buzof\"<\/div>\n
      \nNote that Buzof is really meant for clicking buttons and other simple actions. More complex situations, such as checking a box and subsequently clicking a button or typing in a user name, are beyond its abilities.\n<\/p>\n<\/li>\n
    3. \n
      Develop your own Windows GUI Utility<\/h3>\n
      \nIf you are an experienced Windows programmer, then it won’t be too difficult to create your own solution. This may be a good investment of your time if using AutoIt or purchasing Buzof are not viable options.\n<\/p>\n<\/li>\n<\/ol>\n
      How to Run your Automated Solution on the Isolated Session 0 Desktop<\/b><\/h2>\n
      \nOnce you have settled on a method to automatically dispatch the dialog boxes and popups, you must now set it up to run on the desktop where Windows Services run — in Session 0<\/a>. There are a couple of ways to achieve this:\n<\/p>\n
        \n
      1. \n
        Run your Utility as a Windows Service<\/h3>\n
        We recommend using our AlwaysUp application to run your chosen utility as a Windows Service. If you are using an AutoIt script, set it up to run periodically, perhaps once every minute<\/a>. For Buzof, which should be started once and kept running continuously, any service wrapper (such as Microsoft’s Srvany<\/a>) will perform the basic job.<\/p>\n<\/li>\n
      2. \n
        Run your Utility with the Task Scheduler<\/h3>\n
        Setup a basic scheduled task to start your solution. It will run entirely in Session 0.<\/p>\n<\/li>\n<\/ol>\n
        Note that you can also launch your utility manually in Session 0 using Microsoft’s PsExec<\/a> command line tool.\n<\/p>\n
        Best of luck keeping your Windows Services operating 24×7, without annoying interruptions!<\/b><\/p>\n