Re: Crash with endResetModel
Quote:
Is there something wrong with this code that I don't see?
Aside from the fact that you do absolutely no error checking to ensure that "record" is valid or that either of the values returned by "record.at()" are valid? No.
Quote:
getDataList() << QPair<QString, int>(record.at(0).toString(), record.at(1).toInt());
Re: Crash with endResetModel
There's no need for that, I always get two values in there, and it ONLY crashes on a single machine with exactly the same data. I wonder if it's not some obscure bug in Qt that is triggered by some weird stuff on his Windows.
I found a workaround that works everywhere, but I don't really like it:
Code:
getDataList().clear();
{
getDataList() << QPair<QString, int>(record.value(0).toString(), record.value(1).toInt());
}
emit dataChanged(topLeft, topLeft);
Re: Crash with endResetModel
Quote:
There's no need for that, I always get two values in there
Yeah, what's the point of checking for errors if you know your code will ALWAYS work. Except on some other dude's machine, and then you can just blame it on Qt or some weird stuff on Windows.
Re: Crash with endResetModel
Quote:
Originally Posted by
Carlsberg
I always get two values in there[/CODE]
Except when you don't and you do not notice... Refusing to add a check is contrary to trying to resolve the problem.
Re: Crash with endResetModel
It's not the data for sure, don't make me elaborate why I'm so sure, just be a believer. :rolleyes:
There's something else though, this model is used in multiple combo boxes and the crash happens on a combo box hat is being refilled when another combo box using the same model emits currentIndexChanged(), like this:
Code:
void QueryPanel::onArticleChanged(int index)
{
QString articleName
= articleComboBox
->currentText
();
if (articleName.isEmpty() && articleComboBox->count() > 0)
{
articleComboBox->setCurrentIndex(0);
}
else
{
versionComboBoxModel->refresh(articleName);
}
versionComboBox->setCurrentIndex(0);
}
So it crashes on
Code:
versionComboBoxModel->refresh(articleName);
which goes through the initial code up until endResetModel.
The weird thing is that I use beginResetModel and endResetModel in some table models much more complicated and I have no problem there...
PS. If you want to know how I'm so sure about data, it's because
1) I made sure it always get 2 values - "lol" some would say
2) If 1) is not true, then it would crash everywhere on the same input data, unless SQLite or Qt are garbage, which they are not
3) I've seen with my own eyes (literally) that the dude runs the same thing (run on my side, ok, pack, send over, unpack, run, crash) - it's not like I believe what people say
4) I've added debug logs that show the list is fine and it stops right before endResetModel :cool:
Re: Crash with endResetModel
Quote:
It's not the data for sure, don't make me elaborate why I'm so sure, just be a believer.
OK, fine, I believe you. But what your most recent comments indicate is that there are bugs in your code around handling the data. Something is becoming corrupted that on your partner's machine results in a crash in that piece of code. Maybe his machine has a different configuration - more memory, less memory, different run time DLLs, something that causes the bug to appear where it does on his machine but not on yours.
The fact that you can get it to work by causing Qt to take a different path through the code (dataChanged() vs. endModelReset()) is a big clue that something has gone wrong elsewhere that just happens to show up here.
The fact that you have been able to determine that the problem occurs when one part of the UI is still attempting to process the invalid model is another big clue. Either that part of the UI isn't listening for the modelAboutToBeReset() signal or the signal is received -after- it has already emitted its currentIndexChanged() signal. I would examine slots that are connected to that signal to see what is happening there.