Re: Window transparency dilemma

Sir:

Marty wrote:
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.

Have you tried calling wpRefresh with hab of the desktop?
--
Bill
Thanks a Million!
.

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
    ... 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, 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. ...
    (comp.os.os2.programmer.misc)
  • Re: Progmatically minimizing an application
    ... Yes thanks Paul, I have tried your suggestion but it doesn't seem to mimic ... the minimize functionality. ... Calling Hidein the Activated event does not mimic the Minimize ... it doesn't seem to hide the actual Window, ...
    (microsoft.public.dotnet.framework.compactframework)
Loading