I'm trying to create a popup menu like control that contains custom widgets. I need to capture the mouse, but I need to have the children in the widget still get their mouse messages. It appears the grabMouse sends events only to the widget that grabbed the mouse, not its children.
The popup is simply a series of buttons (using a QGridLayout). The control should work that the user presses the right-mouse button, the popup appears, they move to an item and release the mouse button. Optimally it would work exactly like a QMenu popup but with custom widgets and a custom layout.
How can I achieve this?
It appears that simply specifying attribute Qt::Popup is enough to get the fundamental behaviour required.
Installing an event filter on all children is also necessary. All mouse events, enter/leave/hover events must be captured. QT has a defect with grabMouse so that won't work -- the filter must be used to get expected behaviour.
Related
I want to create QCombobox with tree models support where each child list displayed in new window just like it happens in QMenu (without using QTreeView) but with QListView display features. All is going fine except one small thing: i lose all mouse events for parent widget when child popup is opened. So my question is how to keep taking mouse events during child popup is opened?
In qt basic example Window flags widget with Qt::Popup lose mouse event too. But in QMenu submenu been closed when mouse leave from parent action field. I mean this behaviour is supported by Qt and may be reached from the mox but it's hidden and I can't find a way to give it.
Qt::Tool or Qt::ToolTip modes give me necessary behaviour for parent widget but child widgets do not track mouse events for it's self
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 a modeless CDialog that contains controls, some CButtons and a CScrollbar. The CDialog is parented off of an edit box that I want to keep focus at all times. The problem is that whenever the user uses the controls, clicking a button or on the scrollbar, the control steals focus from the edit box, causing both the parent window to draw without focus (grayed-out header bar), and causing the control to take all the keyboard input. Is there a way for the controls to respond to mouse actions but not steal focus?
The controls and the dialog are all created with WS_CHILD. The controls are parented off the dialog, and the dialog is parented off of the edit box.
I've tried setting focus back after the controls are used, but that causes the parent window to flicker as it loses and then regains focus. Basically I want something that works like a combo box, where the scroll bar can be clicked or dragged around, but keyboard input still goes to the dialog itself, not just the scroll bar, and the whole thing never loses focus.
I haven't done anything like this for a long time, so I'm sure there are a million little details, but I think the starting point is to override the handling of WM_MOUSEACTIVATE.
I am a little confused about child-parent relationship you described.
Can you explain what do you mean by:
The CDialog is parented off of an edit box that I want to keep focus at all times
Any window hosting other windows inside of the client area is a parent of those windows. It is impossible to create window without WS_CHILD that is contained by other window.
Therefore all dialog’s controls are children of this dialog. It is also possible that child window hosts another child window.
CDialog is just an MFC representation of a dialog window; the same applies to other controls. For example CButton is an MFC class that wraps handle of the window’s window that is predefined as window button control.
Dialog never has focus unless is empty (does not have any controls). If dialog contains even one control, this control always has focus.
What focus means is that any given window receives mouse and keyboard messages. Only one control can have focus at any given time. In order for scroll bar to process mouse click or keyboard to move slider, scroll bar must have focus; therefore some other control must give it up.
Combo box drop box (I think this is what you are referring to) is not a child of the dialog. It is a popup window that for the duration has keyboard focus and captures mouse. When it drops down, dialog is deactivated and once dropdown hides, dialog state is changed back to active hence focus never changes, it returns to the control that had focus when dialog was deactivated.
What you are trying to do is probably possible but it would require a lot of coding. Probably hooking messages would do the job but I think it would be going against the stream.
Here is the problem:
The way the GUI system I'm using works is as follows:
A widget can listen to mouse events. The listeners can consume an event they are listening to and as a result, the widget they were listening to will not receive the event, even if it was intended for them, only the listener will have received it.
The problem comes in here:
A scrollpane has a ListBox inside. The listbox can be scrolled. The Scrollpane can also be scrolled. What happens right now is when I mousewheel and the widget under the mouse is the listbox, both the listbox and the scrollpane move. The only solution I see is that the scrollpane consumes all mousewheel events, but then there is no way for the ListBox to ever be scrolled.
The behavior I desire is for the ListBox to scroll when it has focus, but if I did this, it would not work because for example if a radio button inside the scrollpane is focused, I still want the scrollpane to scroll, it is only for widgets with scrollbars such as textbox and listbox where this is not desired.
Thanks
Also, the gui system I'm using is my own which I'm developing.
The usual way to deal with this is that the ListBox only consumes the event if it actually scrolls. If you place the mouse in the listbox and use the scrollwheel the listbox scrolls until it reaches its scroll limit. After that further moves of the wheel cause the scrollpane to scroll.
Obviously there are variants on that - the important thing is to decide what you actually want to happen.
You also need another way of scrolling the scrollpane, so that if the user explicitly wants to scroll it they can, without having to scroll to the end of the ListBox. Scrollbars on the ScrollPane would be one way. You should also make sure there is a way of scrolling the ListBox without using the mouse wheel.
I'm trying to create a custom dropdown for a derivative of CComboBox. The dropdown will be a calendar control plus some 'hotspots', e.g.
So I figure the best way to achieve this is to have a simple CWnd-derived class which acts as the parent to the calendar control, and have it paint the hotspots itself.
The window needs to be a popup window - I think - rather than a child window so that it isn't clipped. But doing this causes the dialog (on which the combobox control is placed) to stop being the topmost (foreground?) window, leading to its frame being drawn differently:
alt text http://img693.imageshack.us/img693/3474/35148785.png
This spoils the illusion that the dropdown is part of the combobox since its acting more like a modal dialog at this point. Any suggestions on how I make the custom dropdown behave like the regular dropdown?
Are there any other pitfalls I need to watch out for, e.g. focus and mouse capture issues?
When you create your popup window, you need to specify its owner. Owned popup windows will activate their owner when you activate them. Not specifying an owner will cause your window to get activated, which causes the change in the owner you're seeing.
Yeah I had this problem once. A quick google makes me suspect I solved this by using CreateWindowEx() and specifying WS_EX_NOACTIVATE. I have some other code that achieves the same effect by making the window with WS_EX_TOOLWINDOW rather than as a popup window, but I'm not sure of why that was done that way, my intuition would say that making it a popup window would be the way to go.
You can find in the following links two sample project that put in the CComboBox dropdown window a CTreeCtrl or a CListCtrl controls ... similar, you can put whatever you need there. Here is the links:
Tree ComboBox Control
and
List ComboBox Control
I hope this help you.