I have a QScrollArea with a set of custom sliders arranged on it. I have noticed that when trying to scroll through the scroll area, one of the sliders often ends up moving instead, which is not desirable.
To make the custom sliders ignore the scroll wheel, I think I need to override QAbstractSlider::wheelEvent and just call ignore in there. This might be a silly question, but is there a way to get this behavior without deriving yet another slider-related class?
You may install an event filter on each of the sliders. When your filter receives a wheel event, just return true to filter this event out.
Related
I've a QTreeWidget and need to disable the mouse over highlighting on the childItems but not the click selection. The point here is, that I need to set this per Item because some are selectable. I was thinking about the QTreeWidget::itemEntered signal to check if the item should be highlighted or not but I can't get it to work because the description says
QTreeWidget mouse tracking needs to be enabled for this feature to
work.
and I can't figure out how.
So my questions for are: How can I enable mouse tracking?
Is there an easier way to disable the highlighting?
Simply invoke setMouseTracking() to enable mouse tracking for a specific widget.
I ran into this problem (I know this is an old post, but I might as well post my solution, since it can be useful for others).
I could not properly disable the mouse feedback while keeping the mouse tracking enabled, but I could make this feedback invisible. I'm using qss stylesheets, and I set the mousehover feedback color to transparent:
MyTreeWidget::item:hover {
background-color: transparent
}
It did the trick for me. Sadly it makes the feedback invisible all the time, rather than allowing to turn it off and on.
So as a next step, for when I needed it, I implemented my own feedback by using a delegate and overwritting the paint function.
The QTreeView overwrite mouseMoveEvent and sends mouse coordinates to the delegate. This way, the delegate can adapt what it does in paint to this position. It feels pretty heavy, and a bit dirty, but it works. Delegate should also allow to have different behavior for different items.
PS: If you're using a delegate, in most cases, that should be enough without the qss change. In my case it wasn't, because I call QStyledItemDelegate::paint in my overwritten paint method, so I inherited some unwanted behavior.
I have a collection of images, dynamically generated through QGraphicsView widgets, and i'd like my users to choose between them. For that purpose, i would display inside a custom widget available images in some kind of grid and have users click the one they are interested in.
Multiple questions arise :
is there an existing widget that already fits this purpose ?
should i find a way to disable all mouse event handling by QGraphicsView items, or could i add a transparent widget in front of graphic views which would intercept them ?
is there a performance issue displaying many QGraphicsView widgets (up to a few hundreds) ? Should i export them to plain images first ?
First off, no, there's no widget designed specifically for that purpose.
I don't think you are grasping what QGraphicsView is for. It's for displaying a QGraphicsScene, which is meant to hold many QGraphicsItems. Based on your post, I can't see why you would need multiple QGraphicsViews. You can simply have one QGraphicsView and display many images inside of its scene. For example, see QGraphicsPixmapItem.
You definitely should not have hundreds of QGraphicsViews. You probably just want one (although a few could be justified in certain circumstances), in which you display many QGraphicsItems in a QGraphicsScene. You can definitely have hundreds of QGraphicsItems visible at once. In your case, you probably want QGraphicsPixmapItems, which are a subclass of QGraphicsItem. You could even have multiple QGraphicsScenes, and display whichever one is relevant using QGraphicsView::setScene. If you want the user to be able to select an image from a grid, and then work with that image, I would look to the State Pattern.
I can't think of any reason to disable mouse handling in QGraphicsViews, QGraphicsScenes, or QGraphicsItems. Why should these not handle their own mouse events? You can (and should, where necessary) subclass them and reimplement mousePressEvent, mouseMoveEvent, mouseRelease event, etc. to obtain the functionality you want.
Good luck!
Right now, my scrollbar is made up of 3 buttons (its children). The buttons currently consume mouse down, up, click, and drag. The scrollbar then hooks into these 3 buttons and does what it wants them to do. Therefore, I do not use the new bubble-up-the-stack feature of my GUI in this scenario.
I'm still not quite clear on when I should use this and when I should listen to child events.
Is my current technique a good way to do it, or should my button instead not consume these events and receive events intended for the buttons and do stuff based on that?
Thanks
In this case the 3 buttons (I presume up, down, and slider) don't have enough information to do anything on their own; the best they can do is interact with the main scrollbar control and tell it what modifications it should make. In that case it might just be cleaner to have the scrollbar do all the message processing itself. It already needs to deal with things like arrow keys, correct?
For my Gui I want to use the following system:
The way it works is that, if the widget under the mouse does not consume a mouse or kb event, it is passed to that widget's parent until it is consumed or the desktop is reached.
Just one thing puzzles me about it. Does that mean if a Button, for whatever reason has a Label as one of its children. If I click the label, would that not mean that my button, which is under the label would click (since a label does not consume the mouse), which is undesired in this case. Does that mean I'd have to do if(mouseEvent.source == this){do button stuff} ?
Thanks
If the label is a child widget, then yes, the label will attempt to eat the event, fail (as usually the label doesn't have a handler method) and thus pass the event back up to the button.
Chances are the easiest way to do this is to derive a subclass of the Label class, and override the handle function (assuming this is possible in your toolkit - which it should be in any decent toolkit). You can then use your handle function to capture mouse clicks, and pass any other event back up to the button.
Comparing pointers is probably a bad idea and is slightly dependent on the way the toolkit is implemented - for instance, it might deem the source as the button (because that's what it expects), not the label.
Though I find it highly strange that a Label is a widget in itself.....
It looks like you need a special kind of "Label" which consumes mouse events. You should be able to create a customized widget (derived from Label) that consumes mouse events for this specific case.
If that Label widget is from a third party that cannot be derived/subclassed, you should wrap the Label in another widget: A simple widget that consumes mouse events and has only one child, the original Label.
I have a CListBox with custom drawing being used, and need to detect mouse-clicks within each item to perform actions.
I can listen for mouse-clicks on the main control and mess about translating coords into the local space of the RECT for the item under the mouse. But is it possible to register message handlers for clicks on individual list items... are there messages for that?
You can use the LVM_HITTEST message to find out which item was clicked.
Well you could just listen for the LBN_SELCHANGE notification. This will fire every time the user clicks a new item. It won't activate if the already selected item is selected though. This may, or may not, be a problem.
Beyond that I'm pretty sure you'll need to intercept WM_LBUTTONUP messages and transform them to the list box's client space ...
OR You could just use a single columned CListCtrl (ListView) class with headers turned off (LVS_NOCOLUMNHEADER). You can then trap the NM_CLICK message. Personally, I massively prefer CListCtrl to CListBox. It IS a little more complex but way more powerful :)
Edit: Or you could try using http://msdn.microsoft.com/en-us/library/bb761323(VS.85).aspx
I'm not certain I understand why you need to have the XY coordinate inside each item of a Clistbox ?
anyway,
AFAIK, Individual items are not CWnd derived objects.
You could get the mouse position inside the control with OnLButtonDown (or up), it returns a CPoint.
After that, use CListBox::GetItemRect to get the rect of the currently selected item, do a bit of pixel computation and you should be able to get the XY inside the rect of the selected item.
Max.
Use the DPtoLP function to convert device coordinates into logical coordinates.
http://msdn.microsoft.com/en-us/library/dd162474(v=vs.85).aspx