Retrieve a word at mouse current position?

[OReubens]

There're many ways to know if the text is still there, even if u want, the tooltip won't have the chance to show. Anyway, I think there're not many tooltips which like to overlap its text.

A tooltip is just an easy example, but I can think up many more cases where different texts would just be overwritten one on top of the other.

How about a progress bar with a text-control that just overwrites the previous progress step. It would be very complicated to keep track of which texts are no longer applicable.

There's no need to aware of focus, u get the necessary window just by one or two functions. If there're several windows at an identical locations, only the topmost can receive the invalidate region, that means, triggers 'textout'.

A window does not need to be topmost to be able to get a textout (or even have any of it's area visible for that matter). Note that not all programs are optimized to ONLY repaint the invalidated regions, but just repaint everything the clipping Windows takes care of making sure those programs don't paint on another windows' canvas.
Many programs also don't just paint as a response to WM_PAINT messages, but do painting at the moment an event occurs, and rely on clipping to take care of everything.

At the very least, you would need to track every textout, and pair it up with the window it's painted on. And even then things get hairy as there's still transparency to deal with.

Text always has a relative co-ordinate, called logical co-ord. And u can convert this to screen co-ord very easily.

You don't understand me I'm afraid. I'm not talking about using the scrollbars to change the offset of the window inside it's 'container'.
There are DC functions to scroll the contents of a window without changing any of the coordinates.
It's essentially the same as doing a blit from videomemory to another location in videomemory. However most accelerated Videocards have explicit support for this, making a scroll faster than a blit. See MSDN for ScrollDC()

It's possible coz before blitting to the video, it must 'textout' its off-screen buffer first.

True, I wasn't trying to imply that it didn't need a textout.
But it makes things an order of magnitude more complicated. I was just trying to show that ONLY tracking all the textouts (and any of the other forms of drawing text) isn't going to be enough.

U don't have to store any string, GDI functions did that. Really, if u draw a bunch of text, it will be divided into smaller sections, so no 'textout' function draws more than one line.

GDI functions took a string, converted it to a bunch of pixels rendered to screen. Once that's done, GDI no longer is aware of the strings it painted. If you need to be able to analyze what string is at the cursor location, the program is going to need to store these strings itself before/after actually calling the GDI function to do the drawing.

Of coz, this solution doesn't work in all cases. But it will work in almost case. Beside, u don't need to care about the processing time, the OCR algo, not much about the font... I think OCR solution is a good solution too, but it won't work in all case, either

I think you fail to see the complexity of how everything ends up on the screen.

The OCR solution is NOT all solving either, I'm aware of that. Reviewing my post I seem to have implied that it does, but indeed it doesn't. But the solution of trying to track down, analyze and store all the GDI calls is in my eyes a near impossible task.

If it indeed were ONLY a matter of tracking the TextOuts it were somewhat feasible, but there's a whole other things to be converned about.

1) You need to track all forms of outputting text.
TextOut, TextOutEx, DrawText, ...
You would need to store the coordinates, the actual string, fonttype, size, alignment, orientation
And you would need to be able to reverse a coordinate that lies within the painted area into the word of the entire string.

2) You would have to be aware of what window the text was output to.

3) You would need some form of 'garbage collection' to remove the 'stale' data. Strings that got overwritten with something else, windows that got destroyed etc.

4) You would need to handle blits and scrolls and work out which parts of previously painted text they are moving (or copied) to another location.
This moving/copying around of portions of videomemory happens A LOT !!! It's not something that's used by only a small amount of programs.
It's the single thing that would make this entire scheme fall in the water.

5) You would also need to be aware of clipping regions active when either the textout or blit/scrolling was called.

6) Going into somewhat more extreme, you would also need to handle transparency, but I'll agree to the fact that this particular feature is somewhat less frequently used.