I would like, if for no other reason that an academic exercise, to be able to read text written to a form on a Windows Application. The program appears to be written in non-.NET, but in .NET terms, I think you would describe the program as having a Form with a Label and I would like to read the text from that label.
I believe I can see that text being written to the screen with the User32!TextOut (and in other areas User32!DrawString) function. However, it would be nice if I didn't have to hook that function to get the information I'm looking for, but instead if I could just read it from the form directly.
So, given a handle to a Window, is it possible to read the text that has been written to that window with functions like TextOut and DrawString using some similar API or other clever means?
Or am I going about this the wrong way? Should I just hook the function and look for the text in every call and pray?
Thanks!
If the text is stored in the standard way on the control you can use SendMessage
Win32.SendMessage(controlHandle, Win32.WM_GETTEXTLENGTH, 0, null);
If the control was written with security in mind, the text is almost certainly not stored in a format that can be queried through the Windows API.
I used to use a program called Snadboy Revelation to grab forgotten passwords out of programs (that were just displaying as *****). Revelation uses the same technique. However, most modern software hides the text of password and similar fields so this is not of as much use these days.
UPDATE:
Found source code for a Windows Spy app.
Related
I want the user to enter text in a text box (such as a login text box on some site).
I tried to search in text() bibliography and other similar functions.
This guy seems to have figured it out: http://www.sojamo.de/libraries/controlP5/. Look for the textArea control.
If you don't like this, I read that the g4p library had something like an inputbox. Otherwise you will have to draw it yourself (which would be a nice exercise) using keyboard inputs and the like.
What you're describing is called a graphical user interface, or GUI. There are many ways to approach this problem:
Code it yourself. Use something like the rect() function to draw a text box, and the keyPressed() function to detect key presses.
Use a library. The Processing libraries page lists several GUI libraries. Try each of them out and see which one you like best.
Use a more general GUI library. If you're deploying as Java, then you might use Swing or JavaFX. If you're deploying as JavaScript, then you might use HTML elements.
Any of the above might work, and which approach you choose depends more on you, your context, and your preferences. We can't tell you which is best, because it's all up to what you prefer.
My goal is to screen-scrape a portion of a program which constantly updates with new text. I have tried OCR with Tesseract but I believe it would be much more efficient to somehow intercept the text if possible. I have attempted using the GetWindowText() function, but it only returns the window title. Using Window Detective I have determined that whenever the window updates in the way I wish to capture, a WM_PAINT message is reliably sent to the window.
I have looked a bit into Windows API Hooks, but it seems that most of these techniques involving DLL injection are intended at sending new messages, not accessing the content of already sent messages.
How should I approach this problem?
When you say 'screen-scrape', is that what you really mean? Reading your post, it sounds like you actually want to get at the text in the child window or control in question - as text, and not just as a bitmap. To do that, you will need to:
Determine which child window or control actually contains the text you want to get at. It sounds like you may have already done that but if not, the tool of choice is generally Spy++. (Please note: the version of Spy that you use must match the 'bitness' of your application.)
Then, firstly, try to figure out whether the text in that window can be retrieved somehow. If it's a standard Windows control (specifically EDIT or RICHEDIT) then there are documented ways to do that, see MSDN.
If that doesn't pan out, you might have some success hooking calls to ExtTextOut(), although that's not a pleasant proposition and I think you might struggle to achieve it. That said, I believe the accepted way (in some sense of the word 'accepted') is here.
With reference to point 3, even if you achieve it, how would you know whether any particular call to ExtTextOut() was drawing to the window you're interested in? Answer, most likely, HWND WindowFromDC().
I hope that helps a little. Please don't come back at me with a bunch of detailed questions about how this might apply to your particular use-case. I'm not really interested in that, these are just intended as a few signposts.
I am making a program called "BasicSys". It is a BASIC System simulator that uses a textbox for the console. So far I have everything working great but I need to have the text box act like a command prompt window. It needs to be able to ask for input and retreive the value without allowing the user to modify anything outside of the prompt space (the space where the user should only be able to type is after a ":" or a ">"). Some feilds are password feilds that require either no echoing or having the chartacters replaced by *'s. Is it possible to make a console out of a textbox?
P.S. I also want to know if there are any small BASIC v2 compilers for Win32 so BasicSys can compile and run BASIC programs.
Depending on how realistic you want it to be you can use the API to open a real console window and interact with it. There are many examples available that you can find by searching such as this one. My suggestion though would be to fake it with a multi-line textbox. It would not be very tricky. Set an index every time you draw the prompt, then as long as the cursor is positioned after the index the textbox is read / write. If the user scrolls backwards make the textbox read only. It should be fairly simple using the KeyDown event and setting the ReadOnly property True / False to get a passable "command" window.
Babylon dictionary and a couple of other dictionaries allow to click on any word in any windows program
and automatically recognize the word under the cursor, and at once open the dictionary window while searching for that word in installed dictionaries.
You can on the other hand open your dictionary, type in your word and press Enter, the result will be the same.
There's a Delphi form, containing a text label, for example with the word "Automaton".
My question is:
How to send a word from my Delphi application right into the dictionary window, as if you typed it manually and pressed Enter?
The best solution is to send some message through the Windows mechanism, but if it is too complicated, there's another solution, and so the second answer: as I described, we need to model a [Ctrl+left mouse] click on a form where this word is displayed on a form [ a visual label on the screen of my Delphi application], to be exact, on some central pixel of this label.
Could you kindly give an advice how to do one thing or another in Delphi ?
** edit:
The problem with AppActivate is this: Babylon dict has a daemon part that seats in the tray.
In the task manager a real window where the text should be input also is named 'Babylon'.
So AppActivate('Babylon') tries to bring to front the non-visual part of the application.
Do you have any suggestion how to determine the windows handle or something of a real visual part of the application? In the task manager, I repeat both visual and non-visual parts are named 'Babylon'.
I cannot offer an answer so much as some insight and advice...
There are certain applications which "intercept" keyboard and mouse instructions, and essentially "nullify" them if they are being immitated by software. Generally-speaking, you'd only see this in proper AntiVirus software such as Kaspersky by design... however:
The way some (not many, but some) programs hook keyboard and mouse inputs, as a side-effect, behave the same way. If you have attempted all of the advice given as comments above, and cannot get Babylon to trigger an action as a result, it is likely Babylon behaves as I have described.
If what I suspect is true, then the method you are attempting is simply not possible (at least, not using any simple Pascal code on its own... ASM might be able to do it but that's beyond my knowledge).
A better solution may be to do a little research to see if any of the following options are available to you:
1) Does Babylon have a Pipeline or API you can use to interface your application(s) with it?
2) Is the particular functionality you require of Babylon accessible through one (or more) DLL files distributed as part of Babylon?
3) Is there an alternative to using Babylon for your needs?
I know it's not an answer as such (certainly not one you'd want to hear), but it may point you in a better direction.
Answers.com has a taskbar application that when you ALT + mouse-click on a word in any program it will pop up a window with information pulled from their website.
My question is-- what are the actual programming mechanics and APIs used to do something like this? I don't have Windows application programming experience and am trying to figure out where to start. How do you access the current word pointed to by the mouse?
Anyone aware of any examples or open source software that does anything like this?
It's been a while and the last time I did something like this it was within my own wysiwyg editor so I had full access to all font characteristics needed to calculate which word was clicked by the mouse.
Maybe there's a n easy way to do this if all your apps are .NET or com or share some other framework which provides a way to retrieve this directly.
Via the API, I would look into hooking the keyboard and mouse messages so that your app can pre-process every mouse click on other applications - start with SetWindowsHookEx and read everything you can about hooking messages.
After getting your app to pre-process the messages, you then need to grab the text being clicked. Since text can be painted onto a device context in many different ways, you may be best off doing a screen scrape of the clicked area because the text may only exist as a bitmap. If this is the case, you have to perform some OCR to translate the scraped bitmap back into text. In other cases, the text may reside in the window as text - the WM_GETTEXT message may return this text from some types of windows (e.g. textboxes, buttons, etc.) but for normal windows, this message only return the title in the caption bar.
Sorry I don't have any definite answer, but this may get you started in the right direction.