table.selectRow no doing anything

SGaist

Then please provide a minimal runnable code example that shows the issue.

PeterB74

I've done some more debugging and it looks like the database stuff is a red herring. First of all, I have the same warnings on my machine, and they don't affect the row selection.

Also, I now had the user execute the following code after the database has been unloaded and reloaded, and the model and the table have been completely reinitialised from scratch:

def page_up_down_edit(self, up_down):
    <...database manipulation stuff...>
    self.table.selectRow(current_row + shift)
    QtWidgets.QMessageBox(text=f"Exit: selected_rows {current_row+shift} {self.table.selectionModel().selectedRows()}").exec_()
    return

This shows a dialog on his machine displaying "Exit: selected_rows 435 []". So, no row gets selected, even though that's exactly what the previous command should do....

SGaist

Are you sure about the values of current_row and shift ?

PeterB74

Yes, that's entirely expected.

I am destroying and recreating the model and the table from scratch inbetween, though. Could it be related to that in any way? Or does the selectRow statement take a while to get into effect?

SGaist

Do you really need to destroy everything every time ?

PeterB74

Yes, because I need to release access to the Qt database, so I have to invalidate the model.

Meanwhile, I managed to get rid of a consistent 'qt_sql_default_connection' still in use' warning (I was still holding on to a variable containing the model), but that has had zero effect....

self.table.selectRow(current_row + shift) does not do anything in that place in my code (at least on my user's machine), and no error message gets written to the console either.

I tried all sorts of things, like rearranging my code, in the hope that I could work around this, but to no avail....

My guess is that there's a very subtle bug in Qt that causes this, but as it only happens on some machines and in a quite specific scenario that cannot be be reduced to a simple runnable test case, it will be very difficult to track down what's happening.

Unless people here have some brilliant insight or new things to try?

SGaist

One thing you can do is to just clear the model content rather than replacing the whole model object.

What type of database are you using ?

PeterB74

It's an sqlite database.

I do this when I unload the Qt view of the database:

self.table.setModel(QtGui.QStandardItemModel())
del self.card_model
self.card_model = None

And when I reload, I do

self.card_model = CardModel(component_manager=self.component_manager)
self.card_model.setTable("cards")
<...>
self.table.setModel(self.card_model)

SGaist

That looks pretty convoluted. Can you explain why you remove the connection ?

PeterB74

Because the backend library I use to process the necessary changes to the database is pure Python, so I need to release Qt's lock on the database first, have the Python library change the database, and then reload the database in Qt.

JonB

@PeterB74
I will say this then: if you are saying you are actually using non-Qt Python stuff to execute the database updates/access I wonder why you are also trying to use QSqlDatabase at all? Maybe you should go via the Python level model? Closing and re-opening the connection/database/model is an "expensive" operation. Just a thought, I admit I don't know your full situation.

PeterB74

I don't think replacing a fast C++ Qt direct database access with a slow Python wrapper is a good idea :-)

Updates to the database happen relatively infrequently, but scrolling through it and filtering is very common.

JonB

@PeterB74
And you think the time taken to process the data in-memory in C++ versus in Python outweighs the time taken to access the data in the database across the library/protocol?

Anyway, best of luck.

PeterB74

The overhead of performing function calls in Python is very big because of the dynamical typing, and you need hundreds of calls to display a reasonable part of your table.

I tried it out, and scrolling becomes unbearingly slow... Accessing the database while staying in C is way more efficient than C calling Python which then calls C again.

JonB

@PeterB74
Point taken! I can only say I used Python/PyQt to do SQL database read/writes/attached as model for Qt views and found it fine for large data (obviously with suitable paging for views if required). But I wasn't doing any Python<->C++ (other, of course, than what's going on in Qt C++ code).

SGaist

One thing that intrigues me, why not just close the connection and reopen it after that ? It looks like there's no need to remove it completely. Or is the file trashed and recreated ?

PeterB74

If I only close the connection but otherwise leave my table intact, I'm getting into trouble because it seems there are still paint calls to my delegates, which require Qt database access...

But I guess I can add some logic to detect a closed database and return from the paint events without doing anything.

I'll have my user try out a version where I do that, thanks for the suggestion!

SGaist

You can try QWidget's updatesEnabled property.

PeterB74

My user got back to me, still the same behaviour. selectRow simply refuses to do anything...

JonB

@PeterB74
Ask user to debug the code for you? ;-)

Since you're not getting an answer here and it's only some certain situation/not readily reproducible, because it's Python can you quickly put in a bunch of print() or whatever statements, perhaps to a log file, for all possibly interesting places/values, and ask him to run your code?

BTW, could it be that user has some other/funny version of Qt or PyQt or something in his environment?