Re: Window transparency dilemma

Rich Walsh wrote:
On Sat, 29 Dec 2007 05:38:32 UTC, Marty <net@xxxxxxxxxxxxxxxxxxx> wrote:

The only other possibility that I see is to somehow map out the windows that are underneath me, find their window handles, and explicitly invalidate them and call their WM_PAINT routines for those affected areas. Sounds like really messy business though.

It really needn't be. After calling WinBeginEnumWindows(HWND_DESKTOP),
you'd cycle through each one, calling WinQueryWindowPos() & WinIntersectRect().
If the latter returns TRUE, it will provide you with a rect you can pass
to WinInvalidateRect(). When done, a call to WinUpdateWindow(HWND_DESKTOP)
should complete the process. If that causes the screen to "blink" because
too much is being repainted, you can make individual calls inside your loop.
Since the updates *will* be handled asynchronously, I'd use DosSleep(1) to
guarantee that the calling thread yields.

This has turned into a personal vendetta for me now. I implemented the enumeration, intersection, and updates as you describe here. Unfortunately, it visibly made no difference from my best pass with my previous method. What's worse is that it's not behaving consistently (in any attempts I made). Sometimes it will clean itself up, but most of the time it won't. Using WinSendMsg to make these windows draw (against your better advice earlier) doesn't make a difference at all either.

My drawing glitch is happening at a time when I can't understand why I'm even getting a message too. My transparent window has the desktop as its parent/owner. When a completely different window from within the same process, with the desktop also as its parent/owner loses the window focus by the user clicking on the desktop, I get a WM_VRNDISABLE/ENABLE pair of messages to my transparent window. When this happens, I hide my transparent window (taking care to avoid the infinite recursion with a window ULONG flag), beg the windows underneath to draw themselves, do the DosSleep, and then capture the bitmap where my window used to be and draw the transparent window again. All windows other than the desktop itself will heed my suggestion and redraw themselves. But I'm left with a shadow of the old transparent window (the part that was on top of the desktop itself) being captured in my bitmap, and incorporated into my new trasparent window.

I just can't convince the desktop window itself to redraw. I even tried a nasty and cheap trick of using CS_SAVEBITS just to put SOMETHING there when my window hides which resembles what the desktop should look like, and it visibly made no difference.

Any ideas on another angle that I can attack this? I refuse to believe that what I'm trying to do is not possible in OS/2. I know that I'll never be able to update based on changes that happen under my window, but I should at least be able to handle other cases without drawing glitches.

--
[Reverse the parts of the e-mail address to reply.]
.

Relevant Pages

  • Re: Is it possible to force a covered window to repaint itself ?
    ... One possibility would be to take a screenshot of the entire screen, ... this onto a fullscreen window that you have created. ... Everything is OK with the transparent window design, ... covered window beneath it can repaint itself, stylus events are ...
    (microsoft.public.pocketpc.developer)
  • Window transparency dilemma
    ... I'm seeing some strange PM behavior that I can't quite understand, apparently relating to whether or not a window was created in a given process. ... I've been able to re-capture the bitmap underneath the window by triggering off of when my window's visible region changes ... My logic here is that if the user changes the Z-order of a window underneath my transparent window, my transparent window's visible region will change. ... WinSetVisibleRegionNotify(myWin, TRUE); ...
    (comp.os.os2.programmer.misc)
  • Re: Redraw Transparent Window
    ... I listed the main points and styles of my transparent window here: ... you should only get the underlying window to redraw ... BitBlt from a memory device context (i.e., get the underlying window to draw ...
    (microsoft.public.win32.programmer.ui)
  • Re: Window transparency dilemma
    ... After calling WinBeginEnumWindows, ... My transparent window has the desktop as ... pair of messages to my transparent window. ... window ULONG flag), beg the windows underneath to draw themselves, do ...
    (comp.os.os2.programmer.misc)
  • Re: Drawing shapes above all other windows (like a volume indicator)
    ... You might want to create a transparent window and then draw on that, ... window to be a tool window, which should keep it on top. ...
    (microsoft.public.dotnet.languages.csharp)