Results 1 to 2 of 2

Thread: Best practice for QItemDelegate (paint() needs underlying data)

  1. #1
    Join Date
    Jan 2007
    Posts
    29
    Thanks
    3

    Default Re: Best practice for QItemDelegate (paint() needs underlying data)

    Hi. I have a rather complex model derived from QAbstractTableModel. I also use a QSortFilterProxyModel for filtering. I'm able to "make it work" but I think I'm going against the Model/View paradigm. Generally, when my custom delegate's paint() routine is called, it really doesn't know how to paint that index b/c it needs information from another index. Imagine a structure that has 5 columns, and I want to paint a row red if column 0 is blank. By the time paint() is called with the index pointing to 0,1, I need to check back to the value of 0,0. Since the QModelIndex provided in paint() returns a pointer to the model, I could do this if my model were so simple. Unfortunately, it's not. There's quite a few checks that happen. As such, I need not the value of some other cell, but I need a pointer to the data structure that is represented by that cell.

    Try 1: What I've been doing until now is, is giving the delegate a pointer to the underlying model & a pointer to the underlying proxy. It will communicate with both of the two to figure out exactly how that index should be handled.

    Caveat 1: The delegate is expecting both a model & a proxy. Not great for a view that is just a straight view of the model (w/ no filtering). I could probably make paint() work and just ignore the proxy if it's NULL, but this still doesn't feel right.

    Try 2: the QModelIndex in paint( int, const QStyleOptionViewItem, const QModelIndex ) provides a pointer to the underlying model. I can cast this to either my derived model, or my derived proxy. I still need to know which though, which doesn't make

    Caveat 2: Once again, I need to know whether I'm using a proxy or not, to know what to cast it to. Thought about a super class which my model and proxy would derive from, but then this pulls in double-inheritance stuff which is no bueno.

    I was thinking of making my own class which simply contains both a derived QAbstractItemModel & derived QSortFilterProxy, but only acts as one. Paint might cast it to my_own_class*, and my_own_class could have a function to retrieve a pointer to the underlying data structure in the model... but would get it via the proxy in the case it was acting as a proxy.

    ...or maybe I'm missing the boat altogether?


    Added after 1 21 minutes:


    After careful thought, I think I'm attacking this wrong.

    paint() should just get data from QAbstractItemModel... Delegate should have some type of foreknowledge of how to paint which rows & columns differently, me thinks.
    Last edited by kiss-o-matic; 24th January 2013 at 06:35.

  2. #2
    Join Date
    Jan 2006
    Location
    Germany
    Posts
    4,380
    Thanks
    19
    Thanked 1,005 Times in 913 Posts
    Qt products
    Qt4
    Platforms
    Unix/X11 Windows Symbian S60
    Wiki edits
    5

    Default Re: Best practice for QItemDelegate (paint() needs underlying data)

    What's about QModelIndex::sibling()?
    Qt Code:
    1. QVariant valueOfCol0 = index.sibling(index.row(), 0).data();
    To copy to clipboard, switch view to plain text mode 

Similar Threads

  1. Reimplement paint() in QItemDelegate
    By john_erlandsson in forum Newbie
    Replies: 4
    Last Post: 19th January 2012, 21:37
  2. Replies: 1
    Last Post: 3rd October 2011, 16:40
  3. QItemDelegate paint() is not called
    By Cortex in forum Qt Programming
    Replies: 2
    Last Post: 10th January 2010, 21:03
  4. Replies: 4
    Last Post: 4th September 2009, 09:33
  5. Drawing a widget in QItemDelegate's paint method
    By darkadept in forum Qt Programming
    Replies: 17
    Last Post: 11th August 2009, 06:15

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Digia, Qt and their respective logos are trademarks of Digia Plc in Finland and/or other countries worldwide.