[Interest] Set QTableWidgetItem checkbox when clicking anywhere on QTableWidget's row

[André Somers]

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é