RE: GtkTreeView signal before row change

[Lance Zhang <zhangp8 hotmail com>]

Thank you, Tristan!

Handle "edited" signal will not help in my situation. Basically one cannot validate user input in that event. 
Say, there are 3 columns, a user entry some perfectly valid data in the first column, but the whole record is
still incomplete. If at this point the user accidentally hit somewhere so that an unintended row change
occurred, a program could not have predicted and handled it in the "edited" signal handler.

I'll check the GtkTreeRowReference part later. Actually I tried to implement the logic I stated in my previous
post, i.e. make use of "cursor-changed" signal, I detected in the handler that the stored GtkTreeIter was 
valid
(maybe just because I am lucky that I didn't do any insertion or deletion), but gtk_tree_view_set_cursor 
didn't
work in the handler to the "cursor-changed" signal even though the stored GtkTreeIter was valid and I was able
to translate it to a GtkTreePath* for gtk_tree_view_set_cursor's consumption.

Maybe after my signal handler, GTK+ library code undid my work. I tried to connect my signal by using
g_signal_connect_after, problem remained. Maybe I'll need to achieve that with a timeout. A huge lot of work
to achieve something trivial. It's so unnatural that I suspect there is a more elegant way not known to me
who am still a novice in GTK+.



Lance 

----------------------------------------
> Date: Wed, 9 Mar 2011 06:41:11 +0900
> Subject: Re: GtkTreeView signal before row change
> From: tvb gnome org
> To: zhangp8 hotmail com
> CC: gtk-app-devel-list gnome org
>
> On Wed, Mar 9, 2011 at 12:38 AM, Lance Zhang  wrote:
> > Hi:
> >
> > I have a situation where I need to verify data before allowing a row change in a GtkTreeView. Essentially:
> >
> > 1. User requests a row change through a keyboard or a mouse;
> > 2. Check if data in the current row has been edited without be saved, or even is complete
> > and valid, and prompt the user appropriately;
> > 3. Depending on user request, I may need to veto the row change request (aka cancel)
> >
> > What's the best practice?
> >
> > A possible way is use "cursor-changed" signal
> > 1. always remember the current row (possibly by store a GtkTreeIter)
> > 2. in the cursor-changed signal handler, check if on the same row and go back to original row by way of
> > stored GtkTreeIter if necessary.
> >
> > Is there a better way? Tell me how you would approach this please.
>
> If you need to store the current row, the safe way is to use
> GtkTreeRowReference.
>
> If you want to step in between when a user edits a cell and before it
> gets committed
> to the model... then you have code already in place where that can be done.
>
> i.e. when you receive the "edited" signal from GtkCellRendererText, the model
> does not update by itself, it's up to you to update the underlying
> store (or not)
> depending on the user input from the GtkCellRenderer.
>
> Cheers,
> -Tristan