I have a program which is not written by me. I dont have its source and the developer of that program is developing independently. He gives me the HWND
and
OK friends, finally I did some crazy things to make it happen. but its not very efficient, like using DirectX directly for drawing.
What I dis:
(WS_EX_TRANSPARENT | WS_EX_LAYERED | WS_EX_ TOOLWINDOW)
and ()
on CreateWindowEx
(WS_EX_DLGMODALFRAME | WS_EX_CLIENTEDGE | WS_EX_STATICEDGE)
from window styles, and also removed (WS_EX_DLGMODALFRAME | WS_EX_CLIENTEDGE | WS_EX_STATICEDGE | WS_EX_APPWINDOW)
from extended window styles.WM_CLOSE
,WM_DESTROY
, to send the WM_CLOSE
or WM_DESTROY
respectively to my windowWM_SIZE
,WM_MOVE
, to resize and move my window according to the other windowWM_LBUTTONUP
,WM_RBUTTONUP
,WM_MBUTTONUP
, to make my window brought to the top, and still keep focus on the other window, so that my window doesn't get hidden behind the other windowSetWindowRgn()
function.This is working perfectly, the only thing is it's not very good at making things transparent.
And the other issue is giving alpha blending to the drawn objects.
But you can easily set the total alpha (transparency) using the SetLayeredWindowAttributes()
function.
Thanks for all the help you guys gave, all the things you guys told me was used and they guided me, as you can see. :)
The sad thing is we decided not to use this method because of efficiency problems :(
But I learned a lot of things, and it was an awesome experience. And that's all that matters to me :)
Thank You :)
You can make a hole in the parent window using SetWindowRgn
.
Also, just because it is not your window doesn't mean you can't make it a layered window.
http://msdn.microsoft.com/en-us/library/ms997507.aspx
Finally, you can take control of another window by using subclassing - essentially you substitute your Wndproc in place of theirs, to handle the messages you wish to handle, then pass the remainder to their original wndproc.
You can use WS_EX_LAYERED
for child windows from Windows 8 and up.
To support earlier versions of windows, just create a level layered window as a popup (With no chrome) and ensure its positioned over the game window at the appropriate location. Most users don't move the windows they are working with all the time, so, while you will need to monitor for the parent window moving, and re position the HUD, this should not be a show stopper.
Not taking focus (in the case of being a child window) or activation (in the case of being a popup) is more interesting, but still quite do-able:- The operating system does not actually automatically assign either focus, or activation, to a clicked window - the Windows WindowProc always takes focus, or activation, by calling SetFocus
, or some variant of SetActiveWindow
or SetForegroundWindow
on itself. The important thing here is, if you consume all mouse and non client mouse messages without passing them on to DefWindowProc, your HUD will never steal activation or keyboard focus from the Game window as a result of a click.
As a popup window, or a window on another thread, you might have to manually handle any mouse messages that your window proc does get, and post them to the game window. Otherwise, responding to WM_NCHITTEST with HTTRANSPARENT
(a similar effect to that which WS_EX_TRANSPARENT
achieves) can get the system to keep on passing the mouse message down the stack until it finds a target.