After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319942 - gtk_tree_view_get_path_at_pos fails after model reset
gtk_tree_view_get_path_at_pos fails after model reset
Status: RESOLVED WONTFIX
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.7.x
Other Linux
: Normal major
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2005-10-27 03:59 UTC by Alex Graveley
Modified: 2016-05-24 11:33 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alex Graveley 2005-10-27 03:59:04 UTC
gtk_tree_view_get_path_at_pos will fail if the TreeView's internal rbtree is not
first validated in it's size_request handler.  This can have bad consequences
when something happens causing invalidation (such as resetting of the model) at
an inopportune time before size_request is invoked.  

An example of this is when the model is (re)set after the first click of a
double click.  Any attempts to figure out the clicked row in order to activate
it in the second-click handler will fail, since the TreeView has not yet gone
through a size_request.

The current workaround is to call size_request after resetting the model, which
causes treeview to validate the first 500 records.  The rest are processed with
an idle handler.  I don't think there is a workaround for treeviews with >500
records.

I propose a corrolary for TreeView similar to gtk_ui_manager_ensure_update,
which would ensure that the internal tree has been validated.
Comment 1 Matthias Clasen 2005-10-29 14:56:42 UTC
Kris, can you look at this ?
Comment 2 Matthias Clasen 2006-03-13 00:36:55 UTC
Kris, any insight ?
Comment 3 Kristian Rietveld 2006-05-25 21:52:40 UTC
I am not planning on supporting changing the model after the first click of a double click unless there is a really good usecase for it.