Hooking ExtTextOut (GDI API)

Hi,

I am hooking the ExtTextOut API for retrieving text in a certain position from any application window (for example the text under the cursor/caret in MS Word). In most cases I am able to retrieve the text from the ExtTextOut function and also its location.

BOOL ExtTextOut(
  __in  HDC hdc,
  __in  int X,
  __in  int Y,
  __in  UINT fuOptions,
  __in  const RECT *lprc,
  __in  LPCTSTR lpString,
  __in  UINT cbCount,
开发者_JAVA百科  __in  const INT *lpDx
);

The location of the text is retrieved by one of these means:

1. It is specified in the ExtTextOut function in the clipping rect parameter (const RECT *lprc - it is an optional parameter)
2. It is specified as the X,Y string position ExtTextOut parametes (relatively to the window client rectangle).

3. Retrivieng the rectangle around the text from the device context using one of the supplied API for clipping regions/paths for example the GetClipBox/GetClipRgn API.

   int GetClipBox( __in HDC hdc, __out LPRECT lprc ); int GetClipRgn( __in HDC hdc, __in HRGN hrgn );

(http://msdn.microsoft.com/en-us/library/dd183435(v=VS.85).aspx)

The problem is that in some applications none of this methods for retrieving the position of the text is working. Moreover, What is more frustrating is that when using some of the APIs to retrieve the region/path from the device context it returns successfully and Indicating that there is no region/path for that device context.

My questions:

1. How could it be that there is no region/path for a device context ?

2. Is there any other way to retrieve the position (or rectangle) of the text since as I understand its position must be specified somewhere in order to draw it finally on screen ?

Any help will be appreciated.

Thanks,

Momico.

---

If an application creates a memory DC and uses these functions you won't be able to see x, y of the text written. Then, you will see a bitblt dumping the memory buffer to the window DC. It's more complicated but you can hook bitblt to see the relative position of the memory DC in the window and you will be able to calculate the position of the text in the bitblt operation.

---

Could the problem be due to programs using double-buffered painting?

i.e. The text may be being rendered into one or more temporary DCs which are then blitted to the "real" DC.

With those you'd get coordinates but they wouldn't always match the final coordinates and the HDCs involved may only exist for a brief moment and not be the ones seen in the window / on the screen.