How to track window changes ?

Hi,

I need to have a user application receive some notification
whenever it's visibility changes. For example, I need to know when
the window becomes partially or completely covered up, when something that
had obscured part of the window is removed making more of the window visible,
or when the window is destroyed, etc.

I'm using windows XP / XP embedded.

I am also writing a KMDF driver for a device that is display-related, but
I am not writing, nor can I modify the display driver itself.

Here is the original approach:
The user app could pass the window handle to the driver. The driver could
call EngCreateWnd, and specify a WNDOBJCHANGEPROC callback that would get
invoked
when GDI changes the window visibility. The driver could pass a list of
visible rectangles back to the user app.

The problem with this approach is that I don't have access to any of the
SURFOBJ information
that is needed by the EngCreateWnd call to create the window object.

I have also considered the method identified in "Tracking Window Changes"
http://msdn2.microsoft.com/en-us/library/ms797870.aspx
but the application's ExtEscape call needs a device context. From what I
can tell,
this "Device Context" is different from a device context which I define for
my device. That makes me think that the DrvEscape will be invoked in the
display driver, not my driver.


Does anyone know how a driver can get the needed information to do this ?

Or better yet, is there possibly something we are missing in the user
mode interface that can notify an application when when window visibility
changes?
(This would be more that just a Paint Event)

Thanks in advance,
Jay

Ivan
Mon Mar 12 20:36:24 CDT 2007

WNDOBJ tracking via EngCreateWnd is the correct approach
to track visible region changes in a display driver.
In order to succesfully use that in combination with an existing
display driver, you need to create a mirror driver.
Then, from a controller applicaiton, you can load the mirror driver
(via ChangeDisplaySettingsEx), and, start tracking windows
via a call to ExtEscape, using the DC of the mirror display driver.

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"jrb1400" <jrb1400@discussions.microsoft.com> wrote in message
news:0F7150C3-AD0C-4648-875B-32875A8EA61A@microsoft.com...
> Hi,
>
> I need to have a user application receive some notification
> whenever it's visibility changes. For example, I need to know when
> the window becomes partially or completely covered up, when something that
> had obscured part of the window is removed making more of the window
> visible,
> or when the window is destroyed, etc.
>
> I'm using windows XP / XP embedded.
>
> I am also writing a KMDF driver for a device that is display-related, but
> I am not writing, nor can I modify the display driver itself.
>
> Here is the original approach:
> The user app could pass the window handle to the driver. The driver
> could
> call EngCreateWnd, and specify a WNDOBJCHANGEPROC callback that would get
> invoked
> when GDI changes the window visibility. The driver could pass a list of
> visible rectangles back to the user app.
>
> The problem with this approach is that I don't have access to any of the
> SURFOBJ information
> that is needed by the EngCreateWnd call to create the window object.
>
> I have also considered the method identified in "Tracking Window Changes"
> http://msdn2.microsoft.com/en-us/library/ms797870.aspx
> but the application's ExtEscape call needs a device context. From what I
> can tell,
> this "Device Context" is different from a device context which I define
> for
> my device. That makes me think that the DrvEscape will be invoked in the
> display driver, not my driver.
>
>
> Does anyone know how a driver can get the needed information to do this ?
>
> Or better yet, is there possibly something we are missing in the user
> mode interface that can notify an application when when window visibility
> changes?
> (This would be more that just a Paint Event)
>
> Thanks in advance,
> Jay
>

Maxim
Mon Mar 26 04:52:40 CDT 2007

> Here is the original approach:
> The user app could pass the window handle to the driver. The driver could
> call EngCreateWnd

No, KMDF driver cannot call EngCreateWnd. Sorry.

The solution is to remove all display code from the KMDF driver and do all
drawing from the user app.

> The problem with this approach is that I don't have access to any of the
> SURFOBJ information
> that is needed by the EngCreateWnd call to create the window object.

Correct, and this is impossible for KMDF driver.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com

jrb1400
Tue Mar 27 19:52:10 CDT 2007

Ivan and Maxim,

Thank you very much for your responses. It looks like the Mirror Driver
approach is going to work for me. Using ExtEscape/DrvExcape, I have been
able to pass back region lists to the user-mode application that creates the
window, and print out the lists.

I have noticed one unexpected thing. The region list is dumped out during
the WNDOBJCHANGEPROC callback. The call:
ulRet = WNDOBJ_cEnumStart(pwo, CT_RECTANGLES, CD_ANY, 1000);
will usually return the number of rectangles in the window's region list.
However, if there are 10 or more rectangles in the window's region list, the
return value is 0xFFFFFFFF.

However, if I just ignore the return value, and continue on to call
bMore = WNDOBJ_bEnum(pwo, sizeof(enumRects), &enumRects.c);
all is as it should be. The count value in enumRects.c is correct, and
the rectangles returned appear to be valid. In my testing I have overlapped
the tracking window so there were up to 166 rectangles. Everything looks
good except for the return value mentioned above.

Since the documentation does not say that the 0xFFFFFFFF return value is an
error condition, it seems OK to go ahead and proceed as I am doing.

I'm using Windows XP.

Thanks for your help,
Jay

Ivan
Wed Mar 28 00:50:40 CDT 2007

try something like


BOOL bMore;
ULONG ulTotalRects = 0;
ENUMRECTS rectTmp.
WNDOBJ_cEnumStart(pwo, CT_RECTANGLES, CD_LEFTDOWN, (ULONG)-1);
do {
rectTmp.c = 0;
bMore = WNDOBJ_bEnum(pwo, sizeof(rectTmp), &(rectTmp.c));
ulTotalRects += rectTmp.rects.c;
} while (bMore);

--
--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"jrb1400" <jrb1400@discussions.microsoft.com> wrote in message
news:ED351ACE-E88F-4D84-ADA4-5A4EBF49856F@microsoft.com...
> Ivan and Maxim,
>
> Thank you very much for your responses. It looks like the Mirror Driver
> approach is going to work for me. Using ExtEscape/DrvExcape, I have been
> able to pass back region lists to the user-mode application that creates
> the
> window, and print out the lists.
>
> I have noticed one unexpected thing. The region list is dumped out during
> the WNDOBJCHANGEPROC callback. The call:
> ulRet = WNDOBJ_cEnumStart(pwo, CT_RECTANGLES, CD_ANY, 1000);
> will usually return the number of rectangles in the window's region list.
> However, if there are 10 or more rectangles in the window's region list,
> the
> return value is 0xFFFFFFFF.
>
> However, if I just ignore the return value, and continue on to call
> bMore = WNDOBJ_bEnum(pwo, sizeof(enumRects), &enumRects.c);
> all is as it should be. The count value in enumRects.c is correct, and
> the rectangles returned appear to be valid. In my testing I have
> overlapped
> the tracking window so there were up to 166 rectangles. Everything looks
> good except for the return value mentioned above.
>
> Since the documentation does not say that the 0xFFFFFFFF return value is
> an
> error condition, it seems OK to go ahead and proceed as I am doing.
>
> I'm using Windows XP.
>
> Thanks for your help,
> Jay
>