Detect and close a dialog when it opens?

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.

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.

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.

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.

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.

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.