Re: Timing Problem

[Bob Caryl <bob fis-cal com>]

I like the coloring option also...  the main thing is to prevent the
user from having to iterate over every duplicate one at a time.

Bob

R. Douglas Barbieri wrote:

>On 12/7/05, Marco Scholten <mscholtn xs4all nl> wrote:
>  
>
>>>Ok...  a more complete description:
>>>
>>>The Gtk::TreeView is displaying a Gtk::TreeStore, and the user can
>>>create new rows; both sibling rows and child rows.  The first cell in
>>>each sibling row must contain a unique character string.  In order to
>>>enforce this, I created a callback slot and connected it to the
>>>signal_edited signal of the cell renderer of the first column in each
>>>row.  In this callback slot, I have a routine that enforces this
>>>condition.  The callback slot is called anytime this editable cell
>>>renderer loses focus.
>>>
>>>The application has two buttons:  The first is labeled "Apply" and it
>>>writes the content of the TreeStore out to a database.  The second is
>>>labeled "Cancel" and it merely leaves the application screen without
>>>doing anything.  If the user is just trying to leave the screen without
>>>writing the data he has entered to the database, then obviously, I do
>>>not want to perform the uniqueness check in the callback slot of the
>>>cell renderer.  My problem is this:  When the cell renderer loses focus
>>>for whatever reason, its signal_edited callback slot is called before
>>>anything else.  I do have a callback slot connected to both buttons
>>>"signal_clicked" and I did set a status variable in this function, but
>>>it gets set AFTER the callback slot for the cell renderer is called, and
>>>hence is too late to do me any good.
>>>
>>>My question is:  is there any way to force the order in which callback
>>>slots are called.  I had hoped to do this uniqueness enforcement as the
>>>user entered data, rather than at the end when he has pressed the
>>>"Apply" button.  If I cannot detect which of the buttons he presses that
>>>results in the cell renderer losing focus before the signal_edited
>>>callback slot is called, I'll have to abandon this approach.
>>>
>>>I hope this makes  a little more sense.
>>>      
>>>
>>I would think getting the focus in event of the button before the focus out
>>event of the cellrenderer is impossible (this would mean that at some moment
>>2 widget have the focus at the same time).
>>You could use the enter_notify_event of the cancel button to detect that the
>>user is about to press the button, but that would be real messy, and would
>>not
>>work if the user use the keyboard instead of the mouse.
>>
>>Here is what i would do:
>>Always check on focus out, but only indicate that the check failed by making
>>the cell's background red or displaying an error in a statusbar or
>>something.
>>Then check again before applying and display a message when it fails.
>>    
>>
>
>Or...you could just hook up to the signal_row_changed() on your
>tree-model, then detect duplicates that way once the column is
>actually changed. I like Marco's suggestion of just coloring the
>cell(s) in conflict. Then if the user doesn't want the changes, cancel
>will allow him to abandon the changes. And, if there is a conflict,
>set the sensitive property of the "OK" button to false so the user
>cannot commit the changes until the problem(s) are cleared up. Would
>that work?
>
>  
>
>>--
>>Marco
>>
>>_______________________________________________
>>gtkmm-list mailing list
>>gtkmm-list gnome org
>>http://mail.gnome.org/mailman/listinfo/gtkmm-list
>>
>>    
>>
>
>
>--
>R. Douglas Barbieri
>doug dooglio net
>_______________________________________________
>gtkmm-list mailing list
>gtkmm-list gnome org
>http://mail.gnome.org/mailman/listinfo/gtkmm-list
>
>  
>