I create a window in a view and create a scrollbar control in that window.
The window has edit mode. In edit mode, it will call SetCapture() and all the mouse event messages are sent to the window. So the other windows in that view will be disabled and have no chance for mouse operation in edit mode.
But it causes the following problem:
- In edit mode, mouse operation in Scrollbar makes no response. Because of SetCapture() to parent window.
So how can I SetCapture() a window but make the sub control respond to mouse operation?
SetCapture must not be called outside WM_*BUTTONDOWN. Read the documentation!
Related
The Documentation for QWidget says this:
mouseReleaseEvent() is called when a mouse button is released. A
widget receives mouse release events when it has received the
corresponding mouse press event. This means that if the user presses
the mouse inside your widget, then drags the mouse somewhere else
before releasing the mouse button, your widget receives the release
event. There is one exception: if a popup menu appears while the mouse
button is held down, this popup immediately steals the mouse events.
It also says this:
If you create new widgets in the mousePressEvent() the
mouseReleaseEvent() may not end up where you expect, depending on the
underlying window system (or X11 window manager), the widgets'
location and maybe more
In my programme, the is a context where the user can change the current visible widget by pressing Enter. If they click and hold on a toolbar button and press enter while the mouse is still pressed, they can send the mouse release event to the now hidden widget. This is a problem as the actions in the toolbar of the now hidden page, relate to a state which has been deinitialised when the active widget was changed.
The desired behaviour would be for the changing of active widget to somehow 'cancel' or 'release' the old widget's claim to the coming mouse release event even though it (or one of its children) received the corresponding mouse press event, and for the action in the toolbar not to be triggered.
Is there any way to do this? Or does anyone have any guidance on what I might be looking for?
Thanks
One options is by creating eventFilter function (either in widget itself (if your own) or parent widget), installing it with installEventFilter and then checking for mouse release event type and only accept the event if widget's isVisible() returns true.
Another option (in case you have your own Qt based widget class) is to override mouseReleaseEvent and do the same visibility check in there.
I have some window. User can drag it, resize etc. At some point there can be a message that should be shown in modal window. I'm creating such a window as child and setting parent window to disabled. Everything works ok except the case when I'm dragging a parent window during the child creation. I used spy to see messages and found that in that case my child window doesn't receives WM_ENTERSIZEMOVE message. It seems that parent's WM_ENTERSIZEMOVE blocks one for child. I tried to manually send WM_EXITSIZEMOVE for the parent but unfortunatelly this doesn't works.
Send the WM_CANCELMODE message to your parent window before displaying the dialog box.
Sent to cancel certain modes, such as mouse capture. For example, the
system sends this message to the active window when a dialog box or
message box is displayed. Certain functions also send this message
explicitly to the specified window regardless of whether it is the
active window. For example, the EnableWindow function sends this
message when disabling the specified window
We have an MFC MDI app that during the process of operation can set the focus on a given control, e.g. it might change the active tab if the result of the operation is more appropriate for a different tab.
If the app has focus when the SetFocus occurs this is fine, tab changes and the correct control has focus. However, if the app does not have focus (ie the user has clicked on another app while waiting for the operation to finish) the SetFocus on the child window causes an OnActivate to occur in the parent MDI frame and the app becomes the foreground window.
How do we SetFocus to a child window without the whole app from becoming the foreground window if the user is working in another app.
Did you try to change focus using CDialog::GotoDlgCtrl ?
How would i make a button that will change it's position on MouseMove Event if the cursor is close enough to the center of the button in MFC ?
WM_MOUSEMOVE is not delivered to the button if the cursor is not over it (and is not captured, but you don't want that). So you have to process WM_MOUSEMOVE in the parent dialog. If you want your button to be a self-contained control, you have to subclass the parent window upon button creation.
Subclassing, in this context, means:
- you retrieve and store the parent's window proc address with GetParent()->GetWindowLong(GWL_WNDPROC)
- you set it to your procedure with SetWindowLong()
- in the procedure, you call the parent's previous window proc, after handling WM_MOUSEMOVE the way you want.
The WM_MOUSEMOVE coordinates will be relative to the screen, but you'll probably want to track the button position relative to the window that contains it. Use the ScreenToClient method on the parent window to convert, then you can compare the coordinates to see if it's close. Then use MoveWindow to move the button.
If you track the mouse cursor position you can determine when the cursor gets close to or enters the button window rect. You can then use the SetWindowPos() function to reposition the button window in the parent window client area.
How does one check if the mouse is over a certain HWND? I have tried using the WM_MOUSELEAVE and WM_MOUSEMOVE messages to keep track, but if you click a button and drag the mouse out of the button, it doesn't receive the WM_MOUSELEAVE until the mouse is released, which is too late, because:
When you click a button, the WM_COMMAND message is only sent if:
1. The mouse was originally depressed over the button
2. The mouse is over the button
3. The mouse is released over the button
I need to replicate this functionality.
To duplicate this functionality, just call SetCapture() so that mouse messages are sent to your window even if the mouse leaves it. You can read the current mouse position as it moves and determine if it is still over your window/button (I'm still not 100% sure what you are doing). And, when the mouse button is released, you can call ReleaseCapture() to restore where mouse messages are sent.
EDIT: Oh, and you can use the Windows API function WindowFromPoint() to determine which window the mouse is over.
This is built-in to Windows, it is called 'mouse capture', SetCapture(hWnd). It ensures you get mouse messages even though the mouse has moved outside of the window. You call it on the WM_LBUTTONDOWN message notification.