BeginResetModel() not working
-
[quote author="Andre" date="1348651988"]And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.[/quote]
It strictly follows from the docs
-
[quote author="peppe" date="1348652004"]
[quote author="deisik" date="1348651720"]
That's what I am talking about. The model is inconsistent WITHIN begin/end methods, so no view may query data. And as it turns out the methods don't guarantee this
[/quote]The fact that your application is single threaded DOES guarantee this.
[/quote]
Well, except if you return to the eventloop, spin a new one or otherwise start processing events somewhere between calling the beginResetModel() and endResetModel(), of course... Which seems to be exactly what happened here. -
[quote author="deisik" date="1348652087"][quote author="Andre" date="1348651988"]And it seems that you were (are still?) assuming that beginResetModel() would (should?) somehow enforce that, no matter what you did before calling endResetModel(). That assumption turns out to be wrong.[/quote]
It strictly follows from the docs
[/quote]
Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed. -
[quote author="peppe" date="1348652004"]The fact that your application is single threaded DOES guarantee this[/quote]
Data queries by the views happen within beginResetModel/endResetModel block. The fact that the application is single threaded guarantees that query won't happen simultaneously with a single command which makes some data change in this block but this query still happens inside this block (interrupts it)
-
[quote author="Andre" date="1348652298"]Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed.[/quote]
I told "follows", do you get the difference? It's written at the beginning of the thread (no pun intended)
-
[quote author="deisik" date="1348652600"][quote author="Andre" date="1348652298"]Could you then please point to the part of the docs that tell you that, specifically? Because that's simply not how I read it here. However, if a section is multi-interprettable, then maybe that should at least be fixed.[/quote]
I told "follows", do you get the difference? It's written at the beginning of the post
[/quote]
Ok, so let met get that back into fresh memory here:
[quote author="deisik" date="1328354153"]As per documentation, "you must call this function before resetting any internal data structures in your model or proxy model" and regarding its counterpart, endResetModel(), "you must call this function after resetting any internal data structure in your model or proxy model". Rational reasoning tells me that by beginResetModel() you declare your data being no longer valid (read unavailable) and by endResetModel() being valid again while changing it somewhere in between so that any views getting data from the model should shrink from quering data which is not yet ready. Everything seems consistent and coherent in this simple logic, right?[/quote]
There are a lot of assumptions in your reasoning above, that just are not valid. Yes, sure, it would be nice if Qt would somehow enforce all the above automaticaly (patches welcome, I think), but it doesn't, and the docs don't tell you that it does protect you from that.
I will agree with you that the issues with spinning an eventloop are not clearly documented, nor is the real function of the beginResetModel() function itself. Also, it isn't immediately clear that a progress dialog even does spin an eventloop or how it otherwise processess events. It clearly does (otherwise, it would not be able to update itself), but again: there is no documentation to warn you against side effects of that. I too would have expected the beginResetModel() method to do more work than it does. However, nowhere there is a promise in the docs that you are protected against queries in the way you seem to be deducing from the docs.
[quote author="deisik" date="1348652495"][quote author="peppe" date="1348652004"]The fact that your application is single threaded DOES guarantee this[/quote]
Data queries by the views happen within beginResetModel/endResetModel block. The fact that the application is single threaded guarantees that query won't happen simultaneously with a single command which makes some data change in this block but this query still happens inside this block (interrupts it)[/quote]
Sorry, but no. There are no "interrups" happening in Qt. It must be caused by some call made by you between the begin/end calls that triggers processing events or something like that. My bet (again: not checked against sources or tested myself): your calls to update your progress dialog are the culprit. -
There is very SIMPLE reasoning behind my assumptions. Views should in NO case query invalidated data from the model being reset, not even because the data has changed but because this may easily crash the program (e.g. you already deleted some rows/columns, but have not yet updated the variables holding their number). And this is what is meant by docs when you read that “you must call this function before resetting any internal data structures in your model or proxy model”
I don't really see why you don't understand these things
-
[quote author="Andre" date="1348653224"]Sorry, but no. There are no "interrups" happening in Qt. It must be caused by some call made by you between the begin/end calls that triggers processing events or something like that. My bet (again: not checked against sources or tested myself): your calls to update your progress dialog are the culprit.[/quote]
This is no secret. The problem is that the views should be FORBIDDEN to query invalidated data in ANY case (unless explicitly called to do so, of course). And beginResetModel tells views just that (which views don't follow). If you don't understand this, it's beyond my power to explain you this
-
I tried my best to explain you how I see this, and how I diagnose the problem, and where the problem in your reasoning is. For naught, clearly. It seems we won't get to an understanding on this issue. Like I said: I guess patches are welcome, to the documentation and/or the views.
Edit:
Interesting quote from the [[doc:QProcessDialog]] docs:
[quote] warning If the progress dialog is modal (see QProgressDialog::QProgressDialog()), setValue() calls Application::processEvents(), so take care that this does not cause undesirable re-entrancy in your code. For example,don't use a QProgressDialog inside a paintEvent()![/quote]
