[Solved] Normal vertical scrollbar handle behavior in QTableView
I'm using a QTableView in Qt (PyQt4, actually). Whenever I have a large table, with hundreds of rows, the vertical scrollbar acts very weird, different than how a QTableWidget scrollbar or any other scrollbar acts.
What happens is that the handle (the clickable/draggable portion) of the vertical scrollbar always starts out larger (taller) than it should, relative to the amount of the table that is currently visible (a very small part). When I use my scroll wheel to scroll down the table to the point where the handle is at about the 90% position of the scrollbar (even though I'm only say 30% through the table), the handle suddenly moves back up to say the 70% position of the scrollbar and shrinks a bit in size. As I traverse the rest of the table, the handle repeats this behavior, getting a little smaller each time and jumping back up the scrollbar to about the 70% position every time the handle gets to the bottom of the scrollbar. Basically, the handle's position in the scrollbar is not properly representing the absolute position of my progress through the table.
Note that this strange behavior only happens when my table is pretty long (say at least 500 rows). I appreciate that this is an interesting mechanic and makes some sense, but it must be optional. Is there some way to disable it and get a scrollbar handle which behaves normally in a long table?
All I'm doing with the QTableView is creating it and setting its model to a QSqlQueryModel which uses a basic SQL query to a database.
Hi and welcome to devnet,
From the top of my head, what is happening is that the model fetches more data while you are scrolling. If you don't want that you would need to load everything at startup, using fetchMore but it might slow down your application status.
You're right. This solves my problem:
@ model = QSqlQueryModel()
model.setQuery("select some stuff", db)
Since it's working as you want now, please update the thread title prepending [solved] so other forum users may know a solution has been found :)