2

We have a scripting engine (running under Windows) that launches another application several thousand times as we do our work. This other application has a busy user interface (main window pops up, flashes several dialogs, does it's work, then closes). Ideally, we'd like to completely suppress the user interface of the child application so the user can continue working on the workstation.

We don't have any control over the code of the other app, so we need to be able to achieve this result from our external process. We are launching the other process, so our app is the new process' owner, if that helps.

Forcing the main window of the app to be minimized by sending a window message after launch doesn't seem to be a good strategy, because we have the launch the app several thousand times over the course of our run (we could minimize the main window each time, but the experience to the user would, I think, still wind up with the focus changing and interrupting the rest of their work). Also, the app in question seems to intentionally call SW_SHOW, so even if we minimize the app, it comes back.

Does anyone have any creative or clever approaches to this? Maybe some way of pushing the app's UI into a different desktop that won't interfere with the user's regular work? (The problem here is that, I'm pretty sure, Windows doesn't support virtual desktops...).

Note that I'm fine with completely suppressing the UI of the child application.

Kevin Day
  • 16,067
  • 8
  • 44
  • 68
  • Another thought: Many Win apps will start up at the same screen coordinates as the user left them when they last quit. Meaning that if you start it, shove its window's left position to currentscreenwidth + 1, it may well start up there until you move it back, unless the app is smart enough to work out that it's offscren and move itself back. – Steve Rindsberg Jan 14 '12 at 16:16
  • 2
    @Steve It probably assumes focus though and that would be even more confusing if the focus window was offscreen – David Heffernan Jan 14 '12 at 16:23
  • You also can't just move a window to the "current screen width" + 1. Lots of people have multiple monitors now. That was a mistake programmers made back in Windows 95. I would have liked to think that we've moved beyond that now. :-( – Cody Gray - on strike Jan 15 '12 at 07:26
  • Yeah - focus is the primary issue here. I will absolutely be trying the CreateDesktop approach. I need to do some performance testing to see how long it takes to create a desktop like that - if it's relatively quick, it would be best to create and destroy the desktop each time around (otherwise you have to be really, really careful not to leave orphaned desktops laying around) – Kevin Day Jan 16 '12 at 04:48
  • @ David: Lordy. Yes, wouldn't THAT be a mess for the poor user. Good point. – Steve Rindsberg Jan 16 '12 at 23:43

1 Answers1

2

Windows in fact does support virtual desktops. Your proposed solution should work beautifully.

Create a new desktop with CreateDesktop but do not switch to it (obviously). Then when you create the process, specify this desktop in the STARTUPINFO struct that you pass to CreateProcess.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • brilliant - I will give this a shot. – Kevin Day Jan 14 '12 at 17:10
  • An elegant use of virtual desktops to hide mis-behaving applications. I like it. – Cody Gray - on strike Jan 15 '12 at 07:26
  • OK - this only got me part way there - I can get the app to launch in the separate desktop, but I can't seem to interact with it via DDE. I'm going to mark this as the answer and open another question about DDE. If anyone is looking for example code, see http://stackoverflow.com/questions/1395351/createdesktop-with-vista-and-uac-on-c-windows – Kevin Day Feb 03 '12 at 01:57