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.

[Sam Hobbs]

Originally posted by sephiroth2m
U use functions such as LPtoDP, ClientToScreen... to convert between them

This is confusing, since ClientToScreen is used to convert Client coordinates to Screen coordinates, right? So I can't be sure how relevant the issue is. I am being vague because it is not worth the time to refer back to what has been said to refresh my memory.

Since the subject is text, logical coordinates have little or not relevance. In nearly all relevant situations, the text will be drawn using text mode, which is one-for-one pixels, or however it is said. Regardlous of how it is said, the mapping mode is rarely or never a problem relevant in this context.

[sephiroth2m]

@OReubens: We seem to misunderstand each other. Actually, I think there're not so much things to do with this method (as u said). Consider the folowing:
-Get the window under cursor (by WindowFromPoint, RealChildWindowFromPoint...)
-Invalidate the window that covers the cursor
-If there're some text, the window will call 'textout'
-Maybe many 'textout's will be called, we'll capture all, then verify which is under the cursor
-Get the text in that 'textout'
Again, I don't think this solution works in all cases. But it's quite simply and 'acceptable'
@Sam: In the case of comparing the mouse's co-ord (screen co-ord) with a text's co-ord (logical co-ord), i think those functions are necessary. Anyway, some word-processing apps could change their mapping mode so they could TextOut basing on lines, not on pixels.

[kirants]

I don't think invalidating the window is a good idea. You are needlessly hogging the system.

the solution for this seems to be highly window specific. Probably you will have a handler for each known window class that you need to trap, static, edit, combo, dialog etc...

[Sam Hobbs]

Originally posted by sephiroth2m
some word-processing apps could change their mapping mode so they could TextOut basing on lines, not on pixels.

Yes, certainly. However that is unusual; for example, is that not possible using Word without using tool or component? TextDraw or something like that? So I did not say it does not happen, I am just saying it is unusual. In fact, I think Word does not, as I said, do it; it is the tool or component that does.

[Krishnaa]

Microsoft Active Accesibility can give you the text under mouse cursor, but it wont tell you the exact word.

so if we get the text (actually the text paragraph who has same IAccesible), how to calculate what word is behind the cursor ??