1

I have a service that needs to run an application (lets call it X) that in tern uses Excel automation.

Often application X when automating Excel will have Excel display a dialog. What and why the dialog displays isn't important, unfortunately that is out of my control.

I'd simply like to be able to close that dialog in Excel.

This of course is easily done when the code doesn't run as a service. The problem is that any win32 window call returns 0 for a handle when enumerating the windows to determine if a dialog is up. I understand why this is as the service runs in isolation and the result of 0 is expected.

It's also not possible that the service runs under local system with interactive desktop enabled.

I was hoping to use the GetThreadDesktop on a thread for the Excel process, then open that Desktop to enumerate those windows, however that api also returns 0 when running from a service.

There are plenty of questions regarding this, however most are about wanting to display a dialog from a service for user interaction. I do not want to do that. Merely find and close a dialog.

Is there a clever workaround to this that someone has discovered to enumerate windows and return the captions ?

Notes:

  • Application X is out of my control.
  • I know that office automation is not supported in a non-interactive environment.
  • I'm not trying to interact with a logged-in user's desktop in anyway.
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
inflexibleauthority
  • 11
  • 1
  • 1
    The "clever workaround" is not to write this as a service. Use a regular application. Most people who write Windows services are doing it wrong. This question is a good example. – Cody Gray - on strike Jul 21 '11 at 10:53

2 Answers2

0

I can think of a few workarounds - none of which I've ever tried, and I can't say for sure if they actually work or not...

  1. Create a desktop of your own from the service. Run Application X using CreateProcess, and make it use that newly create desktop. You might find this discussion useful.
  2. Create a small executable that will take care of the dialog. Create a task (in task scheduler) that will run the executable. Have the task store the credentials used by Excel when it is running, so it can access that desktop. Then, have the service run the task via the task scheduler API. Run this way, the small executable will not execute in the context of the system, but in that of the defined user.
  3. Install a thread or system-wide hook, which will let you run in the Excel's process. From there, you'll know what to do. I doubt this will work in your scenario and it's marginally hacking, but you can give it a try.
  4. This is ugly, but might work: create a small executable that will run as a regular exe, on a "real" desktop. Let that executable interact with X - both being on the same desktop, it should have no problem with that. The hard part is for your service to interact with the executable. This could be done with very primitive means such as files or sockets. For instance, have both watch a certain folder, and pass commands and information in files. This is obviously not robust nor elegant, but on some cases might be sufficient.

Again, I'm not sure any of these will work. The barrier you're trying to bypass is there by design.

Oh, and I feel for you, having to deal with Office automation... Have spent too many days trying to solve weird problems automating Word.

Community
  • 1
  • 1
Eran
  • 21,632
  • 6
  • 56
  • 89
  • I've found some useful articles using CreateProcessAsUser; After much prototyping I don't think I'm going to find away around a security hole MS has plugged well good. – inflexibleauthority Jul 21 '11 at 09:41
  • @inflexibleauthority, Well, MS do [state very clearly](http://support.microsoft.com/kb/257757) office is not designed to be automated on a server/service environment... I've added a forth option, which is ugly IMO, but might be used as a last resort. – Eran Jul 21 '11 at 10:49
0

I have attempted this in the past and concluded that it was effectively impossible to achieve successful Office automation from a service.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490