0

In my WPF application, I have multiple classes each of which implements a message loop. All of these message loops then run in parallel when I create objects of these classes. These objects may show a dialog box at times. The main application thread must keep an eye on these objects and make sure none of them is stuck with the dialog (and press Cancel (Escape key) if it determines such cases). What is the correct way to determine the active foreground window of a thread? I know there is a GetForegroundWindow() API, but it appears as if it works at system level and not thread level.

Community
  • 1
  • 1
dotNET
  • 33,414
  • 24
  • 162
  • 251
  • Could you explain a bit more about "The main application thread must keep an eye on these objects and make sure none of them is stuck with the dialog (and press Cancel (Escape key) if it determines such cases)." – Emond Apr 02 '14 at 05:48
  • Without context that seems to be an bad solution. Why would you need more than one message loop, especially since those loops seem to do user-interaction? – nvoigt Apr 02 '14 at 05:48
  • This is basically a automated-testing scenario. Each of these classes contain a `WebBrowser` that opens a specific page of our ASP.NET website and fills the forms on those pages. Some of the pages can show `OpenFileDialog` at times that we want to get rid of (or provide values at times). – dotNET Apr 02 '14 at 05:52
  • @dotNET There is only one GUI thread, so this means that all open windows belong to that thread, meaning GetForegroundWindow is the same both at process level and thread level. This is to the best of my knowledge. – o_weisman Apr 02 '14 at 06:02
  • @o_weisman: That's not entirely correct. Each of my classes has this in it: `thread = new Thread(() => { Application.Run(); });` in it (see Hans Passant's answer that I have linked), so there can possibly be more than one dialog box showing at the same time in my app. Though this is only my theory and could be wrong. – dotNET Apr 02 '14 at 06:06
  • @dotNET I see, so each of your threads is basically an application on its own? How about using Application.Current.GetActiveWindow()? – o_weisman Apr 02 '14 at 06:15
  • @o_weisman: Thanks. Hold on. I'll give this and David's answer a go. – dotNET Apr 02 '14 at 06:32

1 Answers1

2

There's no such thing as the per-thread active foreground window. So what you are explicitly asking for does not have an answer.

Probably the right way to go here, using Win32 at least, is to enumerate top-level windows with EnumWindows. Then use GetWindowThreadProcessId to identify that the window is associated with one of your threads. Finally use GetClassName to identify that the window is a file dialog. Then feel free to do whatever dastardly thing it is you want to do to the window!

On the other hand, this sounds like a perfect candidate for UIAutomation. You are automating testing of UI. UIAutomation will be able to find these file dialog windows and press buttons on them.

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
  • Thanks a bunch. I'll give this a go. UIAutomation sounds appealing. Link (Google brought up many results, but all of them have a space between UI and Automation)? – dotNET Apr 02 '14 at 06:33