table.selectRow no doing anything
-
That looks pretty convoluted. Can you explain why you remove the connection ?
-
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.
@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 useQSqlDatabaseat 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. -
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.
-
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.
-
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.
@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). -
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 ?
-
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!
-
You can try QWidget's updatesEnabled property.
-
My user got back to me, still the same behaviour. selectRow simply refuses to do anything...
@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?
-
To repeat what I mentioned higher in this thread, that is exactly what I'm doing: a debug statement right after the call to selectRow tells me that no row is selected.
Also, as I mentioned, the software is packaged with pyinstaller, so he has exactly the same environment for Python and Qt as me.
-
To repeat what I mentioned higher in this thread, that is exactly what I'm doing: a debug statement right after the call to selectRow tells me that no row is selected.
Also, as I mentioned, the software is packaged with pyinstaller, so he has exactly the same environment for Python and Qt as me.
@PeterB74
I meant maybe to be a bit more ambitious in what you try to print out. I don't know, maybe it's relevant to print out how many rows are inself.table.selectionModel().selectedRows()? Maybe it's relevant what the user does to get here?Or, you can wait for someone here to figure out what is going on in your particular user case.
-
