Hi,
Op 06/07/2017 om 16:07 schreef Murphy, Sean: > Thanks for the response Andre > >> I'd probably handle this via either a custom delegate or by using an >> event filter. > Can you go into a little more detail on these two approaches? Ok, a little... > > As far as the custom delegate approach, I'm assuming that if I follow the > Spin Box Delegate Example > (http://doc.qt.io/qt-5/qtwidgets-itemviews-spinboxdelegate-example.html) and > just replace the spin box with a checkbox that would get me there? It'd keep it simpler than that. Just create a QStyledItemDelegate subclass, and reimplement editorEvent to handle the mouse events yourself. > > And then with the event filter approach, what would I actually be filtering > on? I'm assuming you're suggesting to filter all clicks on the QTableWidget > and then trying to detect if it's over a checkbox via cursor position, and > then handle the click different based on that? My main sticking point with > that is that a checkable QTableWidgetItem doesn't seem to be an actual > QWidget, so I'm something like qApp->widgetAt(QCursor::pos()) isn't going to > tell me whether I'm over the checkbox, it's going to tell me I'm over the > QTableWidget, right? So I'm not seeing how I tell whether the mouse was over > the check box's pixels or not. Let me know if you meant something else for > this approach. It's similar to the above, only it solves the same problem at a different location in your code. Instead of modifying a delegate, you'd intercept the mouse click and, again, handle the state change yourself. Indeed the widgetApp isn't going to tell you if you're over the checkbox in the item view as the checkbox there is not a widget but rendered by the delegate directly, but you don't need that info either. All you need to know if the mouse is over a row, and which row. QAbstractItemView can tell you that just fine... In both cases, you simply handle the mouse event yourself, and use setData yourself to toggle the state of the checkbox when there is a click *somewhere* on the row. That's what you were after, right? >> P.S. Oh, and get rid of the QTableWidget. Use QTableView instead. > What does that do for me in this case? Nothing to solve this particular issue. Its just a pet-peeve of mine. > My table is very simple, it's basically a read-only table EXCEPT for allowing > the user to check/uncheck items. Maybe I'm wrong in my ideas, but I tend to > view QTableWidget as working pretty nicely for very simple tables like this > but with it you get less control than QTableView. I feel like when I've used > QTableView for situations like this that it takes more code just to get up > and running when compared to creating the QTableWidget. I'm totally willing > to change my views on QTableView vs. QTableWidget if you think I'm wrong! If you must use an item based API, I'd take QStandardItemModel (very wrong name, but ok...) with a standard item view. It provides a much better decoupling of the UI aspects and the data aspects of the application. No need to modify your UI code if you decide your data should come from a different data source in the future, and no need to change your data setup if you decide you want a dropdown instead of table... Also, it makes it easier to introduce things like QSortFilterProxyModel into the stack later on. I think the introduction of the *Widget variants of the views was a mistake that tought Qt users wrong habbits. André _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest