[Qt-interest] QAbstractItemModel::setHeaderData() and headerData()

[j]

> I think this is where your design error is!
> Don't do this please. It is not supported by Qt to inherit from QObject
> twice. Furthermore,  you are confusing the different roles the
> components play. A model is something very different from a view. If you
> want to combine them in a single class, you should a has-a instead of an
> is-a relation.

hmm, yes, well.. I'm implementing a specific view on a specific model,
so I felt in this case it made sense to have this is-a relation.
But I followed your advice, and now I have a working pattern.
Would you agree on this :

I have my own dataModel, call it MyModel.

A ModelBridge class inherits both QAbstractTableModel and MyModel
and implements ao headerData

Any class that wants to expose various data to the gui then
inherits from ModelBridge.

a MyTableView class that inherits QTableView and
implements a setModelBridge function as follows:

void MyTableView ::setModelBridge( ModelBridge * bridge ){
     m_bridge = bridge;
     QTableView::setModel( m_bridge );
}

par example:

class SceneGraph : public ModelBridge {
     SceneGraph(){
         MyModel::setProperty( "number_of_nodes", 15 );
     }	
     ...
     QVariant headerData(int s, Qt::Orientation ori, int r) const;
     ...
};

class SceneGraphTableView : public MyTableView {
     SceneGraphTableView( SceneGraph * graph ){
         MyTableView::setModelBridge( graph );
     }
};

Thanks for any comments,

jonathan




>
>> that has an
>> initialisation function in which I call
>> ...
>> setHeaderData( 0, Qt::Horizontal, QObject::tr("property") );
>> ...
>> I did not implement the headerData function.
>>
> QAbstractItemModel does not store anything by default. It is up to you
> to implement these functions to do something useful. In this case, you
> probably should have implemenented the headerData function. After you
> fix the mistake above, of course. Or, perhaps you should use a less
> basic class than QAbstractItemModel?
>> unfortunately, the header shows '0' in section 0,
>> where I expect it to display 'property'.
>>
>> when I do implement headerData like this:
>>
>> QVariant A::headerData( int section,
>>       Qt::Orientation orientation,
>>       int role ) const
>> {
>>       if( role == Qt::DisplayRole )
>>       {
>>           switch( section )
>>           {
>>                   case 0: return( QString( "property" ) );
>>                   case 1: return( QString( "type" ) );
>>                   case 2: return( QString( "value" ) );
>>           }
>>       }
>>       return QAbstractItemModel::headerData( section, orientation, role );
>> }
>>
>> and omit the setHeaderData call in the initialisation routine,
>> all is fine, and the header displays what I expect.
>>
>> what's going on ?
>>
> QAbstractItemModel is, just like the name suggests and the documentation
> states, an *abstract* interface. It needs implementation by you (or one
> of the standard subclasses) to do anything useful! The implementation
> above looks like a reasonable start.
>
> Andr?
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 29 Jan 2010 14:42:30 +0000
> From: Sean Harmer<sean.harmer at maps-technology.com>
> Subject: Re: [Qt-interest] Documentation on Mutex, 	Semaphore and
> 	Critical Section with Qt?
> To: qt-interest at trolltech.com
> Message-ID:<201001291442.31027.sean.harmer at maps-technology.com>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On Friday 29 January 2010 14:33:50 Matthias Pospiech wrote:
>> Sean Harmer schrieb:
>>>> My reinitialization it would look like this
>>>>
>>>> reinit()
>>>> {
>>>>      lock.lockForWrite();
>>>>      if (device) {
>>>>          delete device;
>>>>      }
>>>>      device = new DeviceClass;
>>>>      lock.unlock();
>>>> }
>>>
>>> Or even better use QWriteLocker locker(&mutex ) that way you are covered
>>> at every possible exit point from your function including throwing
>>> exceptions.
>>>
>>>> an in all accessing functions I would write:
>>>>
>>>> access()
>>>> {
>>>>      lock.lockForRead();
>>>>      device->doSomething();
>>>>      lock.unlock();
>>>> }
>>>
>>> Again, I would prefer to use QReadLocker.
>>
>> I do not see the difference between QReadWriteLock and a combination of
>> QWriteLocker and QReadLocker,
>> especially because in your approach it would be two different lockers
>> which have nothing to do with each other?
>
> I think you are missing the point. You use QReadLocker or QWriteLocker object
> as a convenient way of locking a QReadWriteLock not instead of one.
>
> Sean
>
>
> ------------------------------
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>
> End of Qt-interest Digest, Vol 14, Issue 184
> ********************************************