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 <[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 > > > _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
