validating input with editable cells (Re: editable treeview column)

On Jan 11, 2005, at 8:00 PM, muppet wrote:

  # do something useful when the user edits the cell.
  $cell_renderer->signal_connect (edited => sub {
          my ($cell, $text_path, $new_text) = @_;
# could mangle the value here or perform other updates if necessary.
          my $path = Gtk2::TreePath->new_from_string ($text_path);
          my $iter = $model->get_iter ($path);
          $model->set ($iter, COLUMN_FOO, $new_text);

Incidentally, the "edited" signal is emitted *after* the user has finished editing the value and the little popup entry has been closed. Therefore, if you want to *validate* the user's input in an editable cell, things can get more complicated.

Say the cell is supposed to take IP addresses, of the form "###.###.###.###". You need to allow the user to type numbers and dots, and not allow any other characters. There are a few ways to handle this:

1) Simplest: set up a normal editable CellRendererText. In the cell renderer's 'edited' handler, validate the input. If the input is okay, apply it. If not, either a) ignore it; the data in the model will remain unchanged, and the editor widget will just disappear, possibly aggravating the user who doesn't understand why the program won't take his changes, or b) pop up a message box explaining why the input is no good. This will also be annoying, because you can't automatically start editing mode again, and if the user is clumsy (like me), he'll trigger this message box a lot, which is quite disruptive.

2) Nicer, but more work: Create a custom cell renderer, derived from Gtk2::CellRendererText, whose only purpose is to override the START_EDITING vfunc, to allow you to connect a handler to the insert-text signal of the Gtk2::Editable used as the cell editor widget. As seen in Gtk2/examples/, this gives you a hook at which to modify the user's input *before* it makes it to the screen, e.g., strip invalid characters, avoiding the problems of solution 1. This is easier than it sounds. You'll still have to put up with the user not entering enough dots or too many dots, etc, but since you have control over the entry, you can keep it from emitting 'activate' (which would stop editing) if the input is invalid.

3) Fanciest: Go whole hog and create a custom IPAddressEntry widget which implements the Gtk2::Editable interface, and new cell renderer to use that new widget as the editor. You could still subclass from Gtk2::CellRendererText to avoid having to reimplement rendering. This would allow you to use some special widget that shows the dots for you while editing and moves to the next field with arrow keys or when you've typed enough numbers, like the IP address controls in windows' network control panel. This has all the advantages of option 2 with the added benefit of looking really cool and letting your user know exactly what's going on.

Creating new CellRenderers really isn't that hard; there are five examples included with Gtk2: -- uses a calendar popdown as the editor -- uses a popup menu; to be superceded
       by the CellRendererCombo in gtk+ 2.6. -- draws a progress bar.  will be superceded
       by the CellRendererProgress in gtk+ 2.6. -- follows the technique of option 2, above,
       to use a SpinButton as the editor for a CellRenderer with only
numerical values. (It does, however, do its own rendering, and is
       more involved that a solution for option 2 needs to be.) -- implements a CellRendererText with a multi-line
       cell editor, using the technique of option 3.

To me, "hajime" means "the man standing opposite you is about to hit you with a stick".
  -- Ian Malpass, speaking of the Japanese word for "the beginning"

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]