Re: Timing Problem

["R. Douglas Barbieri" <dooglio gmail com>]

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