Detect and close a dialog when it opens?

This topic contains 5 replies, has 4 voices, and was last updated by Profile photo of Daniel Krebs Daniel Krebs 2 years, 2 months ago.

  • Author
    Posts
  • #19243
    Profile photo of Aurock
    Aurock
    Participant

    We have a program that routes all of it's printing through a 'helper' app. The helper app formats the data into print ready output and sends it to the appropriate print queue on the server. Through some flaw in either the app or the print driver, periodically a standard windows "Print" dialog will come up, allowing for choice of printer or changing settings for the job. When this happens, all subsequent print jobs are held up until someone logs onto the server and clicks "Cancel" on the dialog. (If you click print, it causes future jobs to print using incorrect settings.)

    For various reasons, the helper app runs under a local account on the server with administrator rights. This means when staff notice a problem printing, they call the helpdesk, who notifies a tech or server admin, who logs onto the existing session with the local account, cancels the print dialog, and then the session. (We just hired a new helpdesk person a month or so ago. If I can't find another workaround for this issue, they may eventually get the credentials to log onto this server so they can cancel the print dialog without involving anyone else, but not yet.)

    Would it be possible for a powershell script either running in the background, or run as a scheduled task every 1-2 minutes, to look for an open print dialog in this local user's session and cancel it automatically? How could I go about detecting the open window, and sending a cancel to it?

    * I realize that I may well be trying to drive a screw in with a hammer here. . . if there's a better tool to use for this than powershell, I'm open to suggestions.

  • #19248
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    You'd be better off finding and fixing the bug that's causing this situation in the first place. Writing scripts that interact with the GUI is possible, but when you start talking about combining that with services or scheduled tasks, it can become either difficult or outright impossible.

  • #19255
    Profile photo of Aurock
    Aurock
    Participant

    Thanks for the reply. I don't know where to even begin tracing down an issue of this nature, so I was hoping to just automate the "workaround" that we've been using. I've contacted the software vendor about this before, but they've never seen this issue before and blame some unnamed problem with the print driver or OS. I can't rule the print driver out, but the server only has 2 print drivers in use, both very common printers.

    I know putting something in place to automatically close the dialog window is not a pretty solution, not a solution at all really, but it would at least make the problem less of a pain to deal with.

  • #19257
    Profile photo of Rob Simmers
    Rob Simmers
    Participant

    To determine what is causing the popup, install ProcMon and when the dialog appears, there is a little crosshair button that you can click then click the dialog and it will show you the process tree for that dialog to help you determine what is actually prompting the popup.

  • #19260
    Profile photo of Aurock
    Aurock
    Participant

    I'll be out of the office through next week, I might give that a try when I get back. I guess I assumed that since it's the system print dialog it would be tied to the spooler, but if not, that might be useful.

  • #19261
    Profile photo of Daniel Krebs
    Daniel Krebs
    Participant

    Hi Aurock,

    I agree with Dave on attempting to find the root cause. If that is not successful I would check if AutoHotkey works for you instead of coding this in PowerShell.

    http://www.autohotkey.com/

    Best,
    Daniel

You must be logged in to reply to this topic.