I'm still struggling with model/view

[mrjj]

Hi
its just because you store data in UserRole.
The default delegate takes/show EditRole/DisplayRole
so
myItem.setData(QVariant (1.0), Qt::EditRole); ( or Qt::DisplayRole)
will be more fun.

UserRole is your own data and unless you make delegate to use it, its just ignored.

Also, as a note.
You actually only give it one item, even a row is 3 cols.
So col 2,3, is NULL items. So if you click on them and have slot connected the item u get wil be NULL.

Often , you want to do something like

  QList<QStandardItem*> OneRow;
  OneRow << &myItem << new QStandardItem("100")  << new QStandardItem("100");
  myModel.appendRow(OneRow);

so you actually have items in all cols for a row.

That fooled me a bit in the beginning as the cell is shown but, it can/will be a NULL item
unless you gave it an item for that cell.

if you need sample
http://www.bogotobogo.com/Qt/Qt5_QTableView_QItemDelegate_ModelView_MVC.php

update: ( for later readers )
OneRow << &myItem is bad idea. you should always new QStandardItem

[mzimmers]

Ah, thank you for that. Now, let's say that in my program, my data is represented by a struct:

struct DeviceDetails
{
    string macAddr;
    string devName;
    string latestTimestamp;
};
DeviceDetails tableData[100]; // I won't really do it this way.

And I'm going to have a bunch of these to display (therefore using a table). What's the cleanest way to map my array to the myModel variable?

Thanks...

[mrjj]

@mzimmers
Hi
Will you need to write them back to the struct in the list?
as in user will edit info.

[mzimmers]

My final UI will have two parts: the summary table which I've described above, and a details area. The user will select a row from the table, and this will populate the details area (with more information than just the three strings). (SGaist suggested the books example, which I like and want to emulate.) So, yes, the structure array must be updated from time to time.

[mrjj]

@mzimmers
Ok. well the Address Book Example uses an QAbstractTableModel
subclass that handles the data
the real data lives in QList<Contact> contacts;
Which is similar to your DeviceDetails
so it should lead you on the right track.
You can reuse most of the code as is, and only change the function accessing
Contact to use your DeviceDetails instead. Rest is the same.

[mzimmers]

So, in your opinion, I should go ahead and use QAbstractTableModel instead of QStandardItemModel?

[mrjj]

@mzimmers
well the sample uses it, so it would be natural when you need full editing also.
Also since most of the code will be 100% the same , except other data structure.

However, if you were suggested to use QStandardItemModel, there must been a reason for that.
Maybe to cut down on the details one must handle.
Since DeviceDetails is flat, using a QStandardItemModel is less code and would work just as fine.

But im not sure how the write back would e made. Were you suggested to use QStandardItemModel directly
or to subclass it ?

[mzimmers]

To make sure I'm not misquoting anyone, here's where it was first suggested:

https://forum.qt.io/topic/90985/use-of-model-view-programming/23

I don't really care too strongly which way I go, as long as it works and is maintainable. I don't even need to use the struct I mentioned above; I can store the data elsewhere if it simplifies the programming.

[mrjj]

Hi
ah, QStandardItemModel was suggested over QAbstractTableModel
since its more complex to handle. (as you might have noticed)
with QStandardItemModel , you just give it items and overall its
less involving than QAbstractTableModel where you will have to juggle ModelIndex() and
call begin/end at right times etc.

However, it does sounds like your requirements are very close to Address Book Example
so you could reuse its model from there with very little change.
Also, it already filters i same way as you will need.
User click Contact, details are shown.
User click Device, details are shown.

But it sounded like you already copied the example and its not working 100% for you ?

[mzimmers]

No, I didn't copy the example yet...I actually started this application before being introduced to model/view. I'm now trying to retrofit whatever makes the most sense.

In looking at the books example, I'm struck by the automation that the classes provide. I don't think there's a single instance of a "connect" command in the source code, for example. This is impressive, but it's also hard to use as an example. I'm reading the (long) page on Qt model/view and hope that will help out a bit.

Edit: correction: there is indeed one connect. Still pretty impressive.

[mrjj]

@mzimmers
Well the tablemodel class handles most of that internally and the views already automatically connect to
the signals they need from model.
You should be able to directly use tablemodel.cpp/.h and
only replace Contact with your struct and fix the places where its members are used.
Then it should be working with no extra code.

Its a good idea to read the docs on this topic. Model & Views are a bit involved but
also provides many benefits.

[VRonin]

Subclassing models is a minefield. That's why I suggested using QStandardItemModel instead. The idea was that you can store

struct DeviceDetails
{
    QString macAddr;
    QString devName;
    QString latestTimestamp;
};

as:

enum DeviceRoles{
macAddr = Qt::UserRole
, devName
, latestTimestamp
};
auto item = new QStandardItem;
item->setData(/*...*/,DeviceRoles::macAddr);
item->setData(/*...*/,DeviceRoles::devName);
item->setData(/*...*/,DeviceRoles::latestTimestamp);
myModel.appendRow(item);

The model subclass is probably the most correct way but before embarking into it, please read the chapter of Advanced Qt programming I linked in the previous thread and run your custom model through the Model Test

P.S.
Allocating QStandardItem on the stack is problematic. QStandardItemModel will take ownership of the item and try to delete it. That means that if you declare the item before the model

QStandardItem myItem;
QStandardItemModel myModel;

You'll get a crash as well as if you try to remove that row you'll get a crash

[mzimmers]

@VRonin OK, that makes a lot more sense. So, is the missing field in your setData() examples a pointer to my structure element? Is that how the model keeps track of changes to that data?

[VRonin]

No, my example was using QStandardItemModel. the missing argument is the actual value you want to save in the model, something like item->setData(QStringLiteral("00:A0:C9:14:C8:29"),DeviceRoles::macAddr);

[mzimmers]

Oh, I see. So, am I then responsible for manually updating the item when data changes?

[VRonin]

@mzimmers said in I'm still struggling with model/view:

am I then responsible for manually updating the item when data changes?

Correct, but that would always be the case. if you subclass QAbstractItemModel it's your responsibility to signal changes of data emitting the dataChanged signal

[mzimmers]

So, if I understand this, the general program flow would be:

1. the worker thread receives updates from the various devices
2. the worker passes the updates (via a signal) to the model
3. the model then either adds rows or modifies existing rows
4. the UI automatically reflects the change to the model.

That about right?

One thing I'm still not clear on, is how to modify data in existing rows, for example, changing the timestamp on a device that's already been added.

[VRonin]

@mzimmers said in I'm still struggling with model/view:

That about right?

What workflow did you decide to adopt?

• Use QStandardItemModel
• or subclass QAbstractItemModel

[mzimmers]

I'm now trying to use QStandardItemModel. Unfortunately, the data isn't showing up in the QTableView yet, so I'll have to work through to see where it's failing.

[VRonin]

I'm now trying to use QStandardItemModel

Then:

1. the worker thread receives updates from the various devices
2. the worker passes the updates (via a signal) to a QObject in the main thread that owns the model
3. the object inserts/removes/updates the model
4. the UI automatically reflects the change to the model.