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

[Murphy, Sean]

> > And then with the event filter approach, what would I actually be filtering
> on? 
  <snip>
> 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?

That is what I was after, yes. Just to be clear, in the event filter method, the 
event filter would intercept the click before it gets to the checkbox correct? 
And then I would be able to explicitly set the checkbox's state in my handler 
and avoid the double-toggle that I was experiencing previously? 

Sorry, I'm too lazy to try it this second, but I think I get where you're going!

> 
> >> 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.

Yeah, I get why the view/model approach is far more flexible if things need to 
change down the road. But in this case, I'm like 95% sure we won't change 
how we're presenting this data. It's not like my manager is going to change
his mind a week from now, right? ;)

Thanks for the help, I'll give your suggestions a try shortly
Sean