Accessing text from the client area of a win32 window other than EditControl type windows

[glyfyx]

MSDN tells me only EditControl class windows provide the means to manipulate text strings displayed in their client area. EG, EM_SETSEL, EM_REPLACESEL, messages. Which is fine, but I need a more general solution. I need to access a text string displayed in a non-EditControl type window's client area. It's obvious such code exists, because if I double-click text string T in a text-enabled but non-EditControl class window A of arbitrary app A, T will be highlighted in most if not all cases. When I press Ctrl-C, T will be copied to the clipboard. Some code, no doubt Windows code, located the string of highlighted characters, grabbed a copy of it, and stuck it onto the clipboard. My question is: What do I need to know in order to write code that does the same thing under my control of my pgm? Or is such code available somewhere that I could adapt, and if so, how can I acquire it? Sometimes there are undocumented Windows routines that are available - maybe something I can use? What do you think? Is there a simple answer I'm too inexperienced to realize - possibly as I'm a win32 intermediate newbie at best. I've looked and looked but can't find anything helpful. Any information, suggestions, clues, references, etc, will be very much appreciated. Big thanks! /glyfyx

[David Crow]

Are you looking for the WM_GETTEXT message?

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

[Mark Salsbery]

There's no built in Windows code to get text from a window AFAIK (maybe some specialized APIs that do OCR, I thought I saw one mentioned once but I could have dreamed it). For your non-edit control window text example, there's code written which is called by the window procedure for the window to handle the double click message, draw the text highlighted, handle the keystroke messages for ctrl-c, and place the selected text on the clipboard. That's the same for an edit control.  The edit control's window procedure code just happens to be written for you. Once text is on the screen, it's just pixels, unless the software that rendered the text tracks what text is where, or you use OCR to convert those pixels back to text. Mark

Mark Salsbery Microsoft MVP - Visual C++ :java:

[glyfyx]

Thanks a lot Mark! I understand what you're saying - that once text is onscreen, it's just pixels. I still wonder how, for example, context sensitive help works. Suppose I have 50 pages of source code available onscreen in my IDE and I place the caret on a string *anywhere* in the code and press F1. I will get help related to the string near/on the caret. The F1 support code must somehow obtain the ansi/unicode/whatever equivalent of the onscreen string in order to lookup and return information related to the string. The only way I imagine F1 support code can accomplish this is either: 1 - to maintain an internal text copy of the entire source code and use the caret's x,y point to map into its text-copy to the exact text equivalent of the screen's image of the string; 2 - or as you suggest, the F1 code must ocr the pixels in the immediate vicinity of the caret to decifer its string equivalent. Somehow, neither sounds very appealing. Especially alternative 1 - wow - can you imagine having to keep the internal copy in synch with the myriad screen operations possible? Your ocr suggestion seems more reasonable (in comparison.) Could it be that the text-entry part of an IDE is the client area of an EditControl class window, permitting F1 code to use EM_* msgs? What about all the other text-oriented applications, text editors, WPs, publishing apps, IDEs, spreadsheets, email, etc, are they all EditContol client areas? Hmm.. maybe I should write some code to find out what are the various window classes currently running in my machine. I assume there are API calls that'll supply this information? There must be one that does that. At any rate, I'm very happy to receive your answers even if they're not ones I'd been hoping for - much appreciated! glyfyx

[glyfyx]

Thanks for the response David. But doesn't WM_GETTEXT only return the text of the windows title - that is, for non-EditControl class windows? glyfyx

[Mark Salsbery]

glyfyx wrote:

1 - to maintain an internal text copy of the entire source code and use the caret's x,y point to map into its text-copy to the exact text equivalent of the screen's image of the string;

Doesn't sound appealing but that's pretty much always the way it's done.  Even the edit control does it that way. With a fixed-pitch font, it's pretty simple.  But try developing a word processor like Microsoft Word! Just moving the caret through a variable-pitch font could be quite a programming task. Luckily, the system provides some help with functions like GetGlyphOutline(), GetTextExtentPoint(), GetCharABCWidths() etc. See Font and Text Functions[^] Speaking of Microsoft Word....almost all the functionality of Word is available in the later versions of the Rich Edit Control, which is available for us to use :) Mark

Mark Salsbery Microsoft MVP - Visual C++ :java: