Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
suggestions for repeating display views
Well, I suggest you convert
QStringbefore you pass it to
This post is deleted!
VRonin last edited by VRonin
'QVariant::QVariant(void*)' is private
That is a "safeguard" operator to avoid people using pointers to non-
QObjects into a
macAddris of type
dwill still own the data into
d.macAddrand will delete it when it goes out of scope.
QVariantneeds to own the data and know how to delete it. you should be able to hack your way around it by using a smart pointer but it's probably much easier to store it in a Qt container like
m_model->setData(m_model->index(row, DEV_MACADDR), QByteArray(d.macAddr,sizeof(d.macAddr));
If the compiler complains about signed/unsigned you can use:
@VRonin ah that explains it (in fact, that's exactly what I was trying to do).
I like your idea of changing my char array into QByteArray, but there's a snag - I'm attempting to use the same C struct for my target device as my host app, which restricts me to C++11 types.
JonB last edited by
But @VRonin is only asking you to make a copy into a
QByteArrayfor passing to
m_model->setData(); you're not changing what is actually in your
struct d. So how does that affect your use of the
structin the two apps?
Aargh - I still get confused about using setdata() (and in fact the whole model/view paradigm). Let me play with this, and I'll get back with more confusion in a bit.
JonB last edited by
Maybe it's me who's misunderstanding you:
I'm attempting to use the same C struct for my target device as my host app, which restricts me to C++11 types
I am taking that as you have two, separate programs which wish to share a
.hfile, so you'd like the actual declaration & content to be accessible from a non-Qt program. Maybe you mean something quite different?!
Yes, you got it exactly. I'm kind of a fanatic when it comes to not duplicating data structures (not because I'm lazy, but because I'm afraid of updating one of them, but forgetting to update the other, down the road). This philosophy has occasionally caused headaches during initial implementation, but usually repays itself in simplified maintenance.
OK, I've been grinding through this stuff, and I understand it at least a little better now. My worker receives a message, converts it from XML into a struct, and passes the struct to the object containing the model. My model object then does stuff like this:
mac_itoa(d.macAddr, macStr); m_model->setData(m_model->index(row, DEV_MACADDR), macStr);
So, my summary information in the display widget updates automatically. But, as I mentioned, I have a details area. How do I go about updating the values in this area? I can't do a setModel, as they're just edit boxes, not lists, tables or trees.
You have 2 options:
Do it manually:
connect(view->selectionModel(),&QItemSelectionModel::selectionChangedand fill your widgets with data
QDataWidgetMapperlike explained here: http://doc.qt.io/qt-5/qdatawidgetmapper.html#setCurrentModelIndex
mzimmers last edited by mzimmers
@VRonin thanks for the link. I looked at one of the mapper examples (simplewidgetmapper), and I think this is the way to go for me.
In fact, I'm thinking about changing the entire UI. Instead of separate summary/detail areas, I could provide the user with two lists: one for the MAC address, and one for the device name. When the user makes a selection, all the details area (contained in a grid like the simplewidgetmapper example) would update. The user could then edit the details and press a "commit" button.
How does this sound so far?
So, I've begun an in-place conversion from QTableView to using individual widgets (and QDataWidgetMapper). (I've only implemented 2 fields so far.) I think I must be missing a step, because the fields don't initialize on startup the way they did with the table view.
mapper = new QDataWidgetMapper(this); mapper->setModel(d->getModel()); mapper->addMapping(ui->comboBoxMacAddr, 0); mapper->addMapping(ui->deviceName, 1); ui->gridLayout->addWidget(ui->labelMacAddr, 0, 0, 1, 1); ui->gridLayout->addWidget(ui->comboBoxMacAddr, 0, 1, 1, 1); ui->gridLayout->addWidget(ui->labelDevName, 1, 0, 1, 1); ui->gridLayout->addWidget(ui->deviceName, 1, 1, 1, 1);
Have I indeed left out a step? It may be noteworthy that, once I select a row in my table (I still have the table active), the update properly affects these fields.
the fields don't initialize on startup
What would the expected behaviour be?
I was expecting that the widgets that I mapped to the model would be automatically updated with the model data. (This is how the view table worked.) Could the problem be that I have multiple views setting on the same model? (I still have my view table active.)
If it looks like I misunderstood the correct use of the mapper, please let me know and I'll make whatever changes necessary.
VRonin last edited by VRonin
You just missed the connection.
like explained here: http://doc.qt.io/qt-5/qdatawidgetmapper.html#setCurrentModelIndex
I actually have that connection, and it handles updating the fields once a row is changed. What's missing is the initial setting of the fields before the user selects a row.
In production, this app is going to be collecting data from remote devices all the time. When it gets the first message (no matter from which device), I'd like to populate the MAC address and device name fields with the information from that message, as it does the view table.
You can call
view->selectionModel()->setCurrentIndex(view->model()->index(0,0));when you insert the first row to populate the linked widgets
@VRonin: this solution seems to require the table view. I was hoping to eliminate the table view once I got my individually mapped widgets working. Am I barking up the wrong tree here?
How would you select which device to show details for?
Hi VRonin - I was thinking to use a combo box for the MAC address.
I'm getting the impression that this isn't a great idea, though, so perhaps I'll keep the table after all. The summary area (above the fold) will be read-only, and the details area will permit editing (and a commit).
I was thinking to use a combo box for the MAC address.
Then it's just a small change to the connect statement: