4

I'm trying to make a subclass of QTableView that has an embedded QLineEdit at the top for filtering the results as-you-type. I need my table to have the same API as a normal QTableView, so I want to subclass it rather than subclassing QWidget and adding a QLineEdit and QTableView to it.

I thought I could just re-implement paintEvent(QPaintEvent*), alter the QPaintEvent's rect() to start a bit lower (the height of a QLineEdit, so it draws under it) and then pass it thru to QTableView::paintEvent(), but the QPaintEvent argument only dictates what region needs to be repainted, not the region where the widget should be painted.

Stefan van den Akker
  • 6,661
  • 7
  • 48
  • 63
  • why are you against making a combined widget and go the "hard" way? – Idan K Jun 13 '09 at 21:14
  • Because then the code starts to look like this: public: void setModel(QAbstractItemModel *m){ table->setModel(m); } QWidget* horizontalHeader(){ return table->horizontalHeader(); } QWidget* verticalHeader(){ return table->verticalHeader(); } [snip] All the signals that QTableView emits end up the same way: I would have to map them all to my widget's external interface. –  Jun 13 '09 at 21:20
  • 2
    or you could just make a getter for the QTableView* from your widget. :) – Idan K Jun 13 '09 at 21:53

3 Answers3

7

Anything you do in this regard is going to be hacky and result in just as much work (probably more work) as manually mapping all of the signals and slots to a child widget. You'll need to do a lot more than just change the paint events, you'd also have to adjust all of the mouse events, adjust any update rectangles, etc.

Alternatively you could just take the QTableView class from the Qt source and modify it directly (though that will probably break the LGPL and require you to publish your source if you don't have a commercial license.) But the easiest clean method is going to be implementing a container widget with the QTableView as a child.

Gerald
  • 23,011
  • 10
  • 73
  • 102
1

I have to agree with Daniel: I don't think this is the right approach. You will likely want to create a custom widget with a line edit for performing the filtering. Otherwise, you will be entering into the challenging world of Qt hacking.

If you really need to provide access to the QTableView interface then simply add a public get method that returns a reference to the table.

This is somewhat similar to how Qt provides a QTabWidget class that inherits QWidget but has a private QTabBar that it uses internally. One significant difference is that it provides a protected tabBar() accessor rather than a public one.

Krsna
  • 444
  • 3
  • 9
1

I would try overriding the paintEvent, changing the widget::pos to be abit lower than it is and call QTableView::paintEvent()

shoosh
  • 76,898
  • 55
  • 205
  • 325
  • Calling move() or QTableView::move() within MyTable::paintEvent() simply translates the entire widget (including the QLineEdit member).. I'm not even sure why the QLineEdit is being drawn, since my paintEvent only calls QTableView::paintEvent(), which doesn't explicitly draw any member widgets.. –  Jun 13 '09 at 21:16