0

I have a program that opens a window (a video game, actually) on Windows 8.1. That program then calls an "extension" in the form of a C++ .DLL that I compiled. Within that DLL, I need to get a handle to the window of the program (the video game) that is calling the DLL. I can do this using the FindWindow command combined with the name of the video game window. However, I sometimes need to have 2 copies of it open at once, both with the same window name. This means that using FindWindow(windowName) is not guaranteed to select the window that I actually want. Is there a way to get a handle to the window that is the same application that is calling the C++ code, without having to specify the name?

Jordan
  • 3,998
  • 9
  • 45
  • 81
  • 2
    Why can't you just pass the window handle to the dll from the game? – Rudolfs Bundulis Jul 14 '15 at 14:54
  • The title of the post is confusing – Alexander Balabin Jul 14 '15 at 15:02
  • Yeah, sorry about the title there. Should have proof read that first. I can't pass the window handle to the DLL from inside the game because the game uses a special scripting language that can call functions in external DLLs but can't call any standard language code from inside the game script itself. – Jordan Jul 14 '15 at 18:56
  • @Jordan does the scripting language provide access to the window handle in any opaque way (w/o calling WinAPI), like, for example, Qt does? If so you could just pass it as a `void*` and cast it to `HWND`. If not, there is also a chance that the scripting language is executed inside the event loop of the application - if so, you can try calling `GetActiveWindow()` https://msdn.microsoft.com/en-us/library/windows/desktop/ms646292(v=vs.85).aspx in the DLL, if it is called from the message loop it will get your window:) – Rudolfs Bundulis Jul 14 '15 at 20:14

2 Answers2

1

For each window you get from EnumWindow that matches the windowName you can check HWND's process and pick one that belongs to the process you're running in. That can be done using GetWindowThreadProcessId function - it will give you the PID of the process the window belongs to and you can compare it to your own PID from GetCurrentProcessId.

Alexander Balabin
  • 2,055
  • 11
  • 13
  • How would you get multiple results with `FindWindow()`? – Rudolfs Bundulis Jul 14 '15 at 15:02
  • Indeed, I obviously meant EnumWindows (and possibly a check of title). I'll edit – Alexander Balabin Jul 14 '15 at 15:06
  • I don't think there is an issue with the title - the OP simply used `FindWindow` before and was not aware you can't do what he wants with `FindWindow`. – Rudolfs Bundulis Jul 14 '15 at 15:14
  • 1
    Ok, so I went with this method to attempt a solution. I am able to grab the game window by iterating through EnumWindow and checking the classname with GetClassName(). However, the window has a different process ID than the "current process" does. In my last experiment, I was getting a WindowID = 20056 and a CurrentID = 9816. Maybe the game is running separate processes for display and code or something? – Jordan Jul 14 '15 at 19:37
  • That might be the case but it is easy to check with ProcessExplorer, it has a function to find a process by window and also function of finding processes that loaded a specific DLL, see if you end up with the same process or not. – Alexander Balabin Jul 14 '15 at 19:57
  • @AlexanderBalabin I just tried ProcessExplorer to check it out. GetCurrentProcessId is returning the expected ID that ProcessExplorer is showing the game as having. The ID that GetWindowThreadProcessId is returning for that window, though, doesn't even show up in ProcessExplorer. It's finding an ID that doesn't seem to exist... – Jordan Jul 14 '15 at 21:32
  • @Jordan, are you looking at the return value of the GetWindowThreadProcesId or the output param? The return value is thread id of the window's thread and the process id is put into the last output parameter of the function. – Alexander Balabin Jul 14 '15 at 21:37
  • Ah, I figured it out. I was reading the return value of GetWindowThreadProcessId() instead of passing it a DWORD pointer. It works now. Thanks! – Jordan Jul 14 '15 at 21:37
1

You can combine FindWindowEx to enumerate all the windows with the given name (set hwndParent to NULL to use desktop as the parent and just pass the previous result as the hwndChildAfter when you search the second time, and so on) with GetWindowThreadProcessId and GetCurrentProcessId to find out which of the windows belongs the the same thread you are being called from.

But then again - why not just pass the window handle to the dll directly?

Rudolfs Bundulis
  • 11,636
  • 6
  • 33
  • 71