RE: Can't quite get my head around this, can anyone help?

["Boggess Rod" <rboggess corefurnace com>]

The last one is easy to answer: there are lots of fields to work with,
and many times, records are shown in a parent-child relationship.  The
lots of fields makes it easy for the user to forget if they've made a
change.  The parent-child relationship makes it meaningful to have a
parent set of entry-boxes, and a child set of entry-boxes with a scroll
widget to page through all the child records.

The example is little more difficult.  Technically speaking, it's not
impossible to save the current value.  As it stands, every entry box
shares one common changed event handler which simply sets a flag to say
the data on the form has changed.  If there were only one or two, I
could write a custom handler, and store the value there.  At least, I
think I could.  Much of this isn't working the way I expected, so my
confidence is waning.

Anyway, the problem is that I have lots and lots of entry boxes.  Worse,
I don't really know how many I have until the application runs.  Writing
individual changed event handlers would be impossible.  So, where would
I store the value?

When you click on the trough, the new value is already set, which causes
the lookup of the new child-record, replacing all of the values in the
entry-boxes, including any that the user may have changed.  At this
point, all you'd be doing is telling the luser what an idiot they were
because they forgot to save their data that they forgot they changed.

What I need is an event that triggers before the hscale value has
changed.  One that I could intercept, prompt the user, and choose to
cancel or continue.

I suppose I could save every value on the form before I lookup the data
for the new child record.  But that's not a small amount of data.  And,
as I said, I can't believe I'm the only one that has ever done this
before.  If there isn't a way to intercept and stop these signals, then
there's a major piece missing from GTK.  And I would have thought
(perhaps mistakenly) that it was mature enough to have this type of
functionality.  Not that I'm opposed to contributing to the effort, but
I won't have time to do it before I have to release this application.
Which means I'll have to work around this.

I see some examples of code where the programmer performs a
g_signal_handlers_block_by_func call to disable callbacks, and I thought
they were doing exactly this -- but even that doesn't seem to prevent
the recursion of my callback.  And perhaps worse, a set_value on the
range from within the change-value handler, doesn't (set the value, that
is).

I'll see if I can't post an example that's stripped down to just one
entrybox.  But as I said above, in such a trivial case, it's nothing to
save a single value in the entry-changed event handler.

> -----Original Message-----
> From: gtk-app-devel-list-bounces gnome org 
> [mailto:gtk-app-devel-list-bounces gnome org] On Behalf Of 
> Michael Torrie
> Sent: Monday, August 10, 2009 3:14 PM
> Cc: Gtk app list
> Subject: Re: Can't quite get my head around this, can anyone help?
>
> Boggess Rod wrote:
> > BTDT.  Won't work because by then, the user-value I'm trying not to 
> > loose would already be lost.
>
> Guess I don't understand the problem, then, as I don't see 
> why this would be if you kept track of it in an external 
> variable between callbacks.  Maybe a very small, 
> self-contained example would be appropriate.
>
> > I would have thought this was a somewhat popular function, 
> especially 
> > when processing records from a database.  But I don't seem to know 
> > what to search for.  I can seem to find one single example anywhere 
> > that makes use of the change-value signal.
>
> How would it be used in a database-driven app?  Not having 
> written any, it's not something I'm familiar with.
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list