Re: tab order and restricting entry widgets

[Dave Reed <dreed capital edu>]

> Date: Fri, 14 Jul 2000 20:26:41 +0500 (SAMST)
> From: Vlad Harchev <hvv@hippo.ru>
> 
> On Fri, 14 Jul 2000, xander wrote:
> 
> > On Fri, 14 Jul 2000, Vlad Harchev wrote:
> > 
> > > Date: Fri, 14 Jul 2000 16:38:10 +0500 (SAMST)
> > > From: Vlad Harchev <hvv@hippo.ru>
> > > To: Dave Reed <dreed@capital.edu>
> > > Cc: gtk-list@gnome.org
> > > Subject: Re: tab order and restricting entry widgets
> > > 
> > > On Fri, 14 Jul 2000, Dave Reed wrote:
> > > 
> > > > 
> > > > Is there an easy method to change the focus order when you tab through
> > > > entry widgets.  I've got a bunch of entry and combo widgets in a table
> > > > and I want the tab key to go down the column first rather than across
> > > > the row.  I guess I could use the leave_notify signal for each widget,
> > > > but that would be a pain.
> > > 
> > >  As for focus order - I don't know any easy solution.
> > >  
> > > > Is there a way to restrict entry widgets to only numeric (and
> > > > only dates would be great also)?
> > > 
> > >   No special support for this exists, but you always can connect to "changed"
> > > signal, validate the data, and act accordingly.
> > 
> > That is an easy solution. Connect the signal "changed" in this case for
> > each widget and supply the next widget as extra data. In the callback,
> > use gtk_widget_grab_focus((GtkWidget*)data) and this should do the trick.
> 
>   Yes, but this requires a lot of handwork. It would be nice to hack glade to
> do this.
>   As for original case - I think the following nice hack will work:
> create hbox, pack vboxes into it and make each vbox contain the widgets that
> a column of your table contained. In this case, pressing tab will first switch
> to next entry in column, then to next column.


Yes, but then I can't easily get the nice alignment I get with the
tables.  Maybe I could pack each widget in an alignment instead of the
table, but then I need lots of alignment widgets (at least I think).

The "changed" signal isn't a good solution for me because I don't need
to know when each widget has changed.  I just grab all the values when
a button is pressed.


> > > I prefer to disable "OK"
> > > button if data is invalid; coloring the text of the entry with different color
> > > is nice too.
> > 
> > You mean selecting the whole entry text which is faulty? That is imo a
> > nice solution.
> 
>   No, I meant coloring the text with another color, not selecting it 
> as with shift-arrow. When the entry content becomes valid again, restore the
> color.


Yes, I can do this.  I was just hoping there was some automatic way to
restrict them to numeric types vs. strings, etc. instead of doing it
by hand.

Thanks,
Dave