Some unclarities about QAbstractItemModel and dynamic underlying data

[franz]

The QModelIndex should be used directly after being obtained and discarded directly after being used. The way to associate a certain QModelIndex with it's actual data is to use the internal pointer. When you implement the index() function, you provide the caller with the QModelIndex associated with the data you want to get:

return createIndex(row, column);

return createIndex(row, column);

To copy to clipboard, switch view to plain text mode 

You can pass the createIndex function another piece of information, which is the internalId or the internalPointer:

RegItem *item = getItem(row, column, parentItem);
return createIndex(row, column, item);

RegItem *item = getItem(row, column, parentItem);
return createIndex(row, column, item);

To copy to clipboard, switch view to plain text mode 

Using the internal pointer, you can also implement the parent() function.

Have a good look at the Editable Tree Model example.

[gdiepen]

The QModelIndex should be used directly after being obtained and discarded directly after being used. The way to associate a certain QModelIndex with it's actual data is to use the internal pointer. When you implement the index() function, you provide the caller with the QModelIndex associated with the data you want to get:

return createIndex(row, column);

return createIndex(row, column);

To copy to clipboard, switch view to plain text mode 

I have the feeling that I almost understand, but not yet quite (which is really annoying ). If I understand correctly, the way you are using createIndex here, with only row and column as arguments, means that automatically QModelIndex() is used as the parent, which is the main root index, or not?

You can pass the createIndex function another piece of information, which is the internalId or the internalPointer:

RegItem *item = getItem(row, column, parentItem);
return createIndex(row, column, item);

RegItem *item = getItem(row, column, parentItem);
return createIndex(row, column, item);

To copy to clipboard, switch view to plain text mode 

Using the internal pointer, you can also implement the parent() function.

Have a good look at the Editable Tree Model example.

I have looked at the example and one part is particular interesting (i guess):

In the case shown in the diagram, the piece of information represented by a can be obtained using the standard model/view API:

QVariant a = model->index(0, 0, QModelIndex()).data();

QVariant a = model->index(0, 0, QModelIndex()).data();

To copy to clipboard, switch view to plain text mode 

Since each items holds pieces of data for each column in a given row, there can be many model indexes that map to the same TreeItem object. For example, the information represented by b can be obtained using the following code:

QVariant b = model->index(1, 0, QModelIndex()).data();

QVariant b = model->index(1, 0, QModelIndex()).data();

To copy to clipboard, switch view to plain text mode 

The same underlying TreeItem would be accessed to obtain information for the other model indexes in the same row as b.

I understand the above (again, almost ). In my case I would not need the .data() method, but I could just proivde the model->index(......). However, this is only shown for items a and b, which are directly underneath the root node, which can be found with QModelIndex(). However, for me it would be interesting to know what the third line would be, namely accessing the data of c via the model this way (I saw that the data for c is in the second column, but I don't think that part is relevant for my question). What would be the parent you would need to give to the index method?

Is it that if in the RegistryKey object A I want to provide a QModelIndex (that could be used for telling the model, which can tell the view, about upcoming changes), I would have to determine all ancestors up till the root in my underlying data (so all Registrykey objects till the main root), after which in reverse order I use this as parent information for creating the final QModelIndex that refers to my RegistryKey object A?

[gdiepen]

Does anybody have an answer to the question about how to get the QModelIndex for item c?

Furthermore, can anybody confirm that the steps I described in the last two paragraphs are correct?

Kind regards,

Guido Diepen

[gdiepen]

Just wanted to say that with some more reading and looking into the suggested example you gave, everything is working perfectly at the moment.

Initially I had some major problems with my application segfaulting. I think this was because Qt does not like it when I have the following code in the slot connected to the expand signal of the QTreeView:

beginRemoveRows(0,0)
remove fetching node (i.e. the first node)
endRemoveRows()

beginInsertRows(0,x)
insert the actual fetched nodes
endInsertRows()

Whenever I had the above code combined in the slot, every now and then I would get segfaults. If I left the removing of the "Fetching..." node out, everything was working without a problem.

In the current implementation however, this is not a problem anymore, as the fetching is done via another process that is communicated with via Dbus. This means that from the other process I first instruct to remove the Fetching node and after that instruct for the insertion of the fetched data. Because these are two different events, they are handled separately by the eventloop now.

Small demo to show that I really have it working can be found on my website.

Thanks for the help, I think I finally started to understand how the whole thing with QAbstractItemModel and QModelIndex is working.