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 510897 - TreeView doesn't start editing a cell if set_cursor is called on a newly created row
TreeView doesn't start editing a cell if set_cursor is called on a newly crea...
Status: RESOLVED DUPLICATE of bug 477175
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.12.x
Other All
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2008-01-20 21:11 UTC by Tom Jaeger
Modified: 2008-05-30 20:23 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Test case (2.34 KB, text/plain)
2008-01-20 21:12 UTC, Tom Jaeger
Details

Description Tom Jaeger 2008-01-20 21:11:19 UTC
Please describe the problem:
If a row is appended to a TreeView and the new row isn't immediately visible and set_cursor is called on a cell in that row with editable = true, then the row will be selected, but editing will not start until set_cursor is called again.

Steps to reproduce:
1. Compile and run the attached program
g++ editnew.cc -o editnew `pkg-config gtkmm-2.4 --cflags --libs` && ./editnew
2. Add a new row and start editing it by pressing the "Edit" button.
This works at expected since the row is created inside the visible area
3. Populate the list
4. Repeat step 2.


Actual results:
The row is selected.

Expected results:
The cell should also enter "editing mode".

Does this happen every time?
Yes.

Other information:
There is an easy workaround (also demonstrated in the attached file), which defers editing by connecting to Glib::signal_timeout() with a low priority.
Comment 1 Tom Jaeger 2008-01-20 21:12:25 UTC
Created attachment 103280 [details]
Test case
Comment 2 Kristian Rietveld 2008-05-30 20:23:45 UTC
It looks like this issue must have been fixed in January of this year.  Recent versions of 2.12 should have the fix.  I tried your test case with trunk and couldn't reproduce the issue -- trunk and recent GTK+ 2.12 have the same patch to fix this.  Please let me know if you are still experiencing problems.

Marking as duplicate of 477175.


*** This bug has been marked as a duplicate of 477175 ***