the situation is as follows:
I have the handle for a window (which i got with the function FindWindowEx() ) and that window has 3 buttons. I would like to know how I can get the handle for 1 of the 3 buttons. I mean I know ppl can use spy++, but I am sure there have to be functions that can do it for me, so my questions are:
Question::
What function or functions can I use to get the handle of a button of a window (already knowing the handle for the window)?
Question2::
How do I get the Button's ID???
You can loop through children of that window with EnumChildWindow.
It lets you define a callback function to be called for every child of the window.
In the callback, you can check if the current child is the button you need.
For example, if you dinamically want to press an OK button, you can check if the window text equals OK. You can get the window text with GetWindowText.
If you know the position in the parent window you can use ChildWindowFromPoint.
For this to work you will probably have to check the windows status first (maximazed or current width-height) to be sure the button is right where you want.
An easy way may also be getting his position relative to another child of the window that's easier to retrieve. For example, if the button is always to the right of a text-box control, you can get coordinates of the text-box and use ChildWindowFromPoint passing those coordinates with something added in the x direction.
Related
we have one desktop(1st screen) to display the image and another touchscreen(2nd screen) for the control, we wrote a virtual keyboard(html&javascript) on touchscreen, ideally when we touch the keys on the touchscreen, we could input text in editbox(in an input dialog window) in the 1st desktop. Now the problem is the mouse is lost(originally it is in a input dialog in 1st desktop) when we touch the touchscreen, so we have to create a global window in C++ program, and manually copy each possible input dialog window to this global window when it is in use, also we need to set focus for each possible editbox in this input dialog window. please see this:
for each possible input dialog, we add
extern HWND activeInputWindow;
activeInputWindow=m_Edit_Name.m_hWnd;
also for each possible input box in this window we have to add
activeInputWindow=GetDlgItem(IDC_EDIT_TEST)->m_hWnd;
then the program always do this to get back the original window after clicking the touchscreen(2nd window)
extern HWND activeInputWindow;
if(IsWindow(activeInputWindow))
::SetFocus(activeInputWindow);
suppose we have 10 input window and 10 input boxes in each window,then I need to code 100 places! There must have some simple ways, windows osk.exe (virtual keyboard) have no problem for this but we have to use our own virtual keyboard.... I tried GetTopWindow() and GetForegroundWindow() but not working.. Many thanks for the help
This is trying to solve the problem using the wrong tools. What you really want is a window that receives input, but rejects activation. To achieve this, handle the WM_MOUSEACTIVATE message by returning MA_NOACTIVATE. This also works for touch input.
See How can I have a window that rejects activation but still receives pointer input? for all the ins and outs.
The problem is that your virtual keyboard is stealing the focus of the edit control. You'll need to prevent this.
Try to set the flag WS_EX_NOACTIVATE for a window's style or other approaches from this or this answers.
I have a CTreeListCtrl in my MFC application.What I need to do is add a button in a particular column of a node when a particular condition is satisfied(type is changed to reference).
In the image I have edited and added a blue rounded oval to mark the place of desired button.What I want to do is to invoke a dialog on clicking it.But I don't have any clue whether it is possible or not.If yes then pls give me some suggesions.
This is no normal tree control. It is already customized to use multiple columns and I am sure it uses some kid of owner draw. For me it seams more like a list control with tree Features... I know some similar code from Codepproject..
Creating a "real" button (window) isn't wise/good. because it is another window inside the list control...
Change your code to "Draw a button. You can use DrawFrameControl.
Just intercept the left mouse click. Check the range if this area is cliecked. Fire a user defined message to the parent window.
Using C++, I am making a Tic-Tac-Toe game using the Win32 API. To mark a square (X or O) I want the player to click the square which then changes to an X or O.
What I am doing right now is having a button click event which turns a static text box to X or O. However, when I place the button on top of the text box and make it not visible, I can't click it.
What I really need is an invisible button that still functions. So it's not set WS_VISIBLE, but you can still click it.
Is this possible or is there another way around this problem?
I can see a couple of reasonable possibilities here.
The first and most obvious would be to skip using a button at all, and just have the underlying window process the WM_LBUTTONDOWN message, and set the "X" or "O" in the correct location. For this, you don't even need static controls -- you can just detect the mouse clicks directly on the parent window, and draw your "X" or "O" in the corresponding square.
Another possibility would be a button that's marked as "visible", but happens to be transparent. IMO, this is a fairly poor choice though. To do it, you'd need to either create a transparent button control on your own, or subclass a button control to disable its drawing.
At least IMO, the obvious route would be to skip using the static control at all. Instead, just use the buttons directly -- a button normally has a caption. Start with that caption as an empty string. When the button is clicked, change its caption to "X" or "O" as appropriate. It should probably also disable itself in response to the button click, so clicking it again won't have any further effect.
There's no way to make an invisible button that still functions. Imagine all of the ways that could be abused if it were possible! Not to mention how confusing to have invisible, yet functional, UI.
What Mark Ransom posted is exactly right: you need to get your existing control to respond to mouse click events, just like a button does. Then you can do whatever you want in response to clicks. You don't need a button just to be clickable.
You say that you have a "static text box", but I'm not really sure what that is. There are text boxes (which are not static), and then there are static controls (which can display text). I'm going to assume that you have the latter.
In that case, you don't need to handle the WM_LBUTTONDOWN and WM_LBUTTONUP messages directly, which would require that you subclass the control. Although that's probably the best approach design-wise (separation of responsibilities and all that), it's also a lot more trouble.
Instead, you can handle the click events from the parent's window procedure by setting the SS_NOTIFY style for your static control (you can do this either in the Dialog Editor or in your call to CreateWindow, depending on how you create the control). This causes the control to notify its parent in four cases: when it is clicked (STN_CLICKED), when it is double-clicked (STN_DBLCLK), when it is enabled (STN_ENABLE), and when it is disabled (STN_DISABLE).
So at the parent, you need to process WM_COMMAND messages. The message you're looking for will have a HIWORD(wParam) of STN_CLICKED (indicating that a static control with the SS_NOTIFY style has been clicked), a LOWORD(wParam) corresponding to your static control's ID (set either in the Dialog Editor or specified as the hMenu parameter in your call to CreateWindow), and an lParam containing a handle to your static control.
If you use SW_HIDE, it doesn't just make the window invisible but makes it behave like that too. What you really wanted is probably just make the button transparent. I never did that, you may find this or this helpful.
You may just scrap the textbox just use the button, i mean a button-looking checkbox with ownerdraw or bitmaps. Or scrapping the button and handle the mouse events Like Mark suggests.
I want to create a Window like when a context menu pops up or clicking the menubar. I want a Window that will be like this and that I can take over its paint event. Sort of like what is created when you select a sub tool in Photoshop.
EDIT:I want to know how to create controls like the one that comes when you select a sub tool in Photoshop, these do not seem to have a parent window. Those little description popups are a good example of this type of window, and menu items, those rectangles have no parent window.
Thanks
EDIT2: see this: http://cdn-viper.demandvideo.com/media/CB3C805F-421E-45AE-8359-39D59D8F0165/jpeg/20412728-192C-462A-AF8E-1F30BA77AE05_2.jpg
You will notice the window for the sub tools, it is not constrained to a parent window.
But how do they get a nice shadow
around it, and how does it still stay
with the main window without a parent?
That's your real question.
There are several ways of getting the shadow. One is that the window is actually two windows, the "shadow" plus the "main" window.
When you create the flyout window (that's what it's called), you position it near the toolbar. If the toolbar gets a WM_MOVE message, it's your responsibility to call MoveWindow() on the flyout to keep it lined up.
Edited to add
The dwExStyle parameter of CreateWindowEx() should include WS_EX_LAYERED and probably WS_EX_TRANSPARENT, because the 'shadow' will use alpha blending. The hWndParent parameter is the application's main window. The x and y parameters must be calculated as an offset of whatever button the window is to be associated with.
For one of my projects, I need to create a function that will return a handle to a window when the user click on it (any window displayed on screen, and anywhere inside that window).
I know it is possible to use a global hook, but I think there must be a more simple way of doing that, without using any DLL injection.
In fact, I could intercept the left mouse click or intercept when a window is activated.
Can I use one of those 2 solutions without any DLL injection?
You could use a LowLevelMouseProc hook to intercept the click, and then use WindowFromPoint to determine the window. (I haven't actually tried this.)
Call SetCapture. When you do that, all subsequent mouse events will go to your own window. When you get a click event, call ReleaseCapture, and then WindowFromPoint to find out what window resides at the point where you got the click event. The coordinates you get in the click event will be relative to the window you passed to SetCapture, to remember to convert them to screen coordinates first. Use ClientToScreen.