You could probably modify it to do this, yes. It's creating a transparent window that overlays the host window, so you could use the same technique to overlay the desktop with a transparent topmost window.
I've done this before for similar input purposes and the only caveat is that some applications are able to 'push' topmost windows to the bottom - there are some workarounds, though.
You can also do this with raw GDI (if you do the pixel pushing yourself) or with GDI+, since all you need at the base level is an ARGB buffer to feed to the windows compositor.
For example, I wrote an overlay for my dualshock4 driver that would visualize touchpanel inputs at the bottom right corner of the screen and describe the inputs it had synthesized from them.
https://github.com/kg/DS4_PSO2/blob/master/DS4_PSO2/GestureO...
"I've done this before for similar input purposes and the only caveat is that some applications are able to 'push' topmost windows to the bottom - there are some workarounds, though"
Are there? I would think that is a weapons race you cannot win. If you can force your window to the top of all other windows, including those of other applications, so can others.
The only way out of that is if the OS has a notion of "this is the one and only topmost full screen window".
Right, that's why in this case you just periodically push yourself to the top of the stack. If you're not capturing input (and the user opted into it) it's relatively sensible.
Exclusive mode fullscreen applications will crush you anyway since the compositor turns off, but otherwise it seemed to work OK.
At best, I would call that "You win or you lose". Yes, there are all kinds of hacks that might give you a better chance, and you may be able to make it very likely you will get what you want, but to do so you have to be very naughty.
For example, another hack involves removing the real screen from the OS and creating a virtual screen of the same dimensions and bit depth, intercepting calls to the virtual screen, and essentially writing one's own compositor in the video memory of the real screen. If my program does that, your messages to move your window to the top will never work. Your window may end up on top on the virtual screen, but that's not what the user looks at. If you counteract by using the same trick, how do you know that want you think is the real screen isn't already a virtual one created by a program that ran earlier, of that a program running later doesn't enumerate the hardware and figures out where the real memory lies?
I also could try and patch your program when I detect it, patch it in memory to send fewer or no such messages, intercept its messages, or even crash it when I see it, etc.
It remains competition for a scarce resource; because of that, I don't see how two identical copies of such a program could both win, let alone if I run ten of them.
