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? 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? 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. > > P.S. Oh, and get rid of the QTableWidget. Use QTableView instead. What does that do for me in this case? 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! Sean _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
