On 12/7/05, Marco Scholten <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/gtkmm-list > -- R. Douglas Barbieri [EMAIL PROTECTED] _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
