Thread: RE: [GD-Windows] Finding HWND of the current thread
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-windows
|
From: Mat N. \(BUNGIE\) <mat...@mi...> - 2004-07-15 17:14:17
|
Useful functions: EnumThreadWindows GetConsoleWindow And for a brute force window search: GetWindowThreadProcessId MSN -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Brian Hook Sent: Thursday, July 15, 2004 9:38 AM To: gam...@li... Subject: [GD-Windows] Finding HWND of the current thread For my simple audio library I'm stuck doing something a little gross,=20 and that's passing an HWND to the library upon initialization, only=20 because IDirectSound::SetCooperativeLevel() needs an HWND. Now, you CAN use GetDesktopWindow() and NULL, but that's not the=20 correct way and there are supposedly some failure cases when you use=20 those (e.g. multiple instances using GetDesktopWindow()), and God=20 knows what the HWND is really used for in DirectSound and what can=20 happen if you do something like create a hidden window and bind DS to=20 that instead of to your real application window. Anyway, that aside, instead of passing in HWND, I was thinking it=20 might be possible to find the window of the current thread by=20 enumerating all windows in the system and comparing their owner=20 threads with the current thread and using that. Is there anything glaringly wrong with that, other than the potential=20 situation that there is none (e.g. console application) and having to=20 fallback at that point. Brian ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id=10040&op=3Dick _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5 |
|
From: Andrew G. <ag...@cl...> - 2004-07-15 17:14:51
|
Couldn't you just create a simple hidden window and pass that handle in? Really though if this is a library wouldn't you want to allow the user to pass in a handle and handle the case of being a console app at a higher level... Andy -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Brian Hook Sent: 15 July 2004 17:38 To: gam...@li... Subject: [GD-Windows] Finding HWND of the current thread For my simple audio library I'm stuck doing something a little gross, and that's passing an HWND to the library upon initialization, only because IDirectSound::SetCooperativeLevel() needs an HWND. Now, you CAN use GetDesktopWindow() and NULL, but that's not the correct way and there are supposedly some failure cases when you use those (e.g. multiple instances using GetDesktopWindow()), and God knows what the HWND is really used for in DirectSound and what can happen if you do something like create a hidden window and bind DS to that instead of to your real application window. Anyway, that aside, instead of passing in HWND, I was thinking it might be possible to find the window of the current thread by enumerating all windows in the system and comparing their owner threads with the current thread and using that. Is there anything glaringly wrong with that, other than the potential situation that there is none (e.g. console application) and having to fallback at that point. Brian ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21&alloc_id040&op=click _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5 |
|
From: Brian H. <ho...@bo...> - 2004-07-15 18:21:47
|
> Couldn't you just create a simple hidden window and pass that > handle in? You could, but that's not really the right thing to do, e.g. to handle minimization automatically. DirectSound really wants to have a handle to the application window, not just any handle. > Really though if this is a library wouldn't you want to allow the > user to pass in a handle and handle the case of being a console app > at a higher level... Yes, but expressing that portability is kind of gross. It's what I'm doing right now, in fact, but I don't like it, and if there was a way to isolate the user from this, that would be ideal. Brian |
|
From: Donavon K. <kei...@ea...> - 2004-07-15 19:41:55
|
Actually both windows would get WM_ACTIVATEAPP, even if they're different window classes, so let me change my bet... :-) Perhaps it's sufficient that the window be top-level? Donavon Keithley -----Original Message----- From: Donavon Keithley [mailto:kei...@ea...] Sent: Thursday, July 15, 2004 2:30 PM To: 'gam...@li...' Subject: RE: [GD-Windows] Finding HWND of the current thread > God knows what the HWND is really used for in DirectSound and > what can happen if you do something like create a hidden window > and bind DS to that instead of to your real application window. I would imagine that it's subclassing the window and sniffing for deactivation while in exclusive mode, as D3D does with the "focus" window. That would imply that it needs to be top-level and that the choice of window is quite significant. For instance in a D3D app, it should be the same window as the D3D focus window. As an experiment, I'd create a test app with two top-level windows. Give one to D3D and the other to DSound, go exclusive on both, and see what happens when you Alt-Tab away. Will DSound realize that it should relinquish? I don't have a lot of experience with DSound, but my chips are on "no". Donavon Keithley |
|
From: Brian H. <ho...@bo...> - 2004-07-15 18:19:56
|
> GetConsoleWindow As a library, I won't know if it's a console window or not. > EnumThreadWindows > GetWindowThreadProcessId Right, that's what I was thinking might be the most robust way to do it for non-console apps (and for console apps, creating a dummy window). Brian |
|
From: Jan W. <ur...@st...> - 2004-07-28 08:45:09
|
On Thu, 15 Jul 2004 14:19:49 -0400, Brian Hook <ho...@bo...> wrote: >> GetConsoleWindow > As a library, I won't know if it's a console window or not. You can check the Subsystem field of the PE "optional" header (always present): if it's equal IMAGE_SUBSYSTEM_WINDOWS_CUI (3), you've got a console app. void* base = (void*)0x400000 (or GetModuleHandle(0)) IMAGE_NT_HEADERS* h = ImageNtHeader(base) h->OptionalHeader.Subsystem == 3? Disclaimer: off the top of my head and ugly to boot ;) |
|
From: Jon W. <hp...@mi...> - 2004-07-29 08:05:24
|
May I suggest that you're not guaranteed that GetModuleHandle() returns a pointer to your executable header, and you're not guaranteed that your executable loads at 0x400000 ? They might have a hard time changing this behavior for existing apps, especially because of hacky code like the posted code, but you never know about future versions. If you want the header, use GetModuleFileName() on the main module, and read the header yourself. Then check whether the header is actually a "PE" header, and just assume you're not console if it isn't. At least, that won't CRASH when you port your code, or some new version of Windows comes out. Cheers, / h+ -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Jan Wassenberg Sent: Wednesday, July 28, 2004 1:45 AM To: gam...@li... Subject: Re: [GD-Windows] Finding HWND of the current thread On Thu, 15 Jul 2004 14:19:49 -0400, Brian Hook <ho...@bo...> wrote: >> GetConsoleWindow > As a library, I won't know if it's a console window or not. You can check the Subsystem field of the PE "optional" header (always present): if it's equal IMAGE_SUBSYSTEM_WINDOWS_CUI (3), you've got a console app. void* base = (void*)0x400000 (or GetModuleHandle(0)) IMAGE_NT_HEADERS* h = ImageNtHeader(base) h->OptionalHeader.Subsystem == 3? Disclaimer: off the top of my head and ugly to boot ;) ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
|
From: Jan W. <ur...@st...> - 2004-07-30 18:27:51
|
On Thu, 29 Jul 2004 01:04:04 -0700, Jon Watte <hp...@mi...> wrote: > May I suggest that you're not guaranteed that GetModuleHandle() returns a > pointer to your executable header, and you're not guaranteed that your > executable loads at 0x400000 ? They might have a hard time changing this > behavior for existing apps, especially because of hacky code like the > posted code, but you never know about future versions. > > If you want the header, use GetModuleFileName() on the main module, and > read the header yourself. Then check whether the header is actually a > "PE" header, and just assume you're not console if it isn't. At least, > that won't CRASH when you port your code, or some new version of > Windows comes out. That would be the more correct way of going about things :) However, I don't think these assumptions can ever be broken (famous last words). The app load address must stay the same, since PE relocation info is no longer generated (because 0x400000 is guaranteed). GetModuleHandle has to return a pointer, since crt0 currently uses it as such (checking if the app is managed). Now if they're willing to break every single (not recompileable) program in existence with future versions, all bets are off. Best Regards Jan |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X