Using pure Win32 API, how can I get the handle to the control that currently has the focus? And then how can I determine if it's a Text Box / Rich Text Box?
I'm trying to write a small macro keys program which will allow user to register new hot keys using the RegisterHotKey() function. Everything is working fine except that I don't want to violently call SetWindowText() or SendMessage(hWnd, WM_SETTEXT, 0, TEXT("Something")) without knowing whether the control is a text box or not.
Be noted that I want a handle to the control that currently has the focus, not the whole window the user is working on.
Related
I'm working with 3d party application. Changing a text in Edit control using
SendMessageW(m_edit_handle,WM_SETTEXT,0,str_address);
And it works fine.. It changes visually in the window. But once I click a button (also programmatically) it works as there is a default value but not the one I set with SendMessageW.
Just wondering if after changing the text in Edit window I have to call some other method to force Windows to update the actual value in the field?
Depending on how the target app is coded, you may need to issue an EN_CHANGE notification to the Edit's parent window. Sending WM_SETTEXT will not send that notification, as it is meant to be sent when the user makes changes to the Edit's content, not when code does.
SendMessageW(m_edit_handle, WM_SETTEXT, 0, str_address);
SendMessageW(GetParent(m_edit_handle), WM_COMMAND, MAKEWPARAM(GetDlgCtrlID(m_edit_handle), EN_CHANGE), LPARAM(m_edit_handle));
I have a Windows 7 system, a regular monitor as the primary display (serving as a desktop, etc.), and an additional screen attached to the same graphics card.
I want to write a program that takes control of the secondary display and uses it for fullscreen OpenGL rendering. I tried to enumerate displays with EnumDisplaySettings, pick the secondary display, create a device context associated with the display, set the pixel format on the DC, and create a WGL context associated with it. I can get this far without errors, but then the call to wglMakeCurrent fails for no apparent reason (return value is 0, GetLastError() is 0, and OpenGL does not function.)
The only way I could get it to work is to extend the desktop onto the secondary display (manually, from Windows display settings), create a window and move it onto the secondary display. Which is tolerable but undesirable (I don't want the secondary display to interfere with the desktop. For example, in this setup, I can move the mouse cursor from the desktop into the secondary display.) Is there a way to avoid this?
More generally, in order to get OpenGL to work on a display, do I need (1) to have the display attached to the desktop (or "a" desktop?), and/or (2) to have a window of my own on that display?
P.S. It seems that I might be able to get this to work with a third-party library such as glfw3, but I don't want extra baggage (I don't need 90% of functionality of glfw3) and I'd prefer to get this done directly through native API calls if possible.
Unfortunately the Windows graphics driver model does not allow to use displays independently. You will have to extend the desktop to the second display and create a fullscreen window on it. When it comes to constraining the mouse, the usual way is to hook into the system mouse events and whenever the mouse pointer is moved into the secondary screen remove it back to the primary screen.
I have a windows application which has several sub-forms. i have to navigate through 5 or 6 forms to reach the form i need. this is time consuming since i have to open it several times through the day and i do it daily.
my need: i dont have the source project for this application, i got it as an executable program, but i need to create some application that does these steps for me automatically. In other words i need to find a way to automatically click the buttons that navigate through the forms and opens the form i need from step one.
is there any way i can do this ?
There is indeed, though generic solutions already exist to perform just this kind of function to arbitrary programs.
You can use Spy++ or a resource-editor, like ResHack or ResEdit to look at the program and get the control ids of the navigation buttons.
Once done, you can get a handle to the program itself and then send messages to it's WindowProcedure that would be generated if the user clicked the controls with a mouse,
Another alternative, is to get the position of the running target application, after you've got it's HWND, by using the GetWindowRect function. You could then use this position along with vert/horiz distances to generate mouse events.
The two have more-or-less the same result, though some applications won't work with approach #1.
In one instance, you need to use Spy++ to get the control IDs.
In the other instance, you need to use an image editor to get the pixel offsets of the controls.
In both instances, you'll need to use FindWindow, along with the window's title-text in order to get a HWND handle.
You could use a combination of the two - asking the program itself with GetDlgItem for the handle of the controls you need to click. You could then query the control for its position, before using mouse_event to position the mouse above it and again to click it.
Quite a few ways to skin this cat, actually.
Pre-existing solutions like AutoIt are said to be very easy to use and will be much easier than coding a new program for each target.
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.
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.