Re: Timing Problem

["Marco Scholten" <mscholtn xs4all nl>]

> 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.

--
Marco