Re: Regarding example code (was Why is ChangeValue reentrant)

Boggess Rod wrote:
In cases like this, you probably have to hack around the problem/bug.
IE solve your use case in a different way.

Already have.  Instead of using the response from gtk_dialog_run, I
gtk_widget_show_all the dialog window and return TRUE from the
change-value callback of hscale.  Then I decide on the action within the
clicked callback of the Ok and Cancel buttons.  It means manually adding
the buttons, but that's not a big deal.


The code in bug.c runs fine for me.  OK allows the change, Cancel
prevents the change.  I'm on Fedora 11 with GTK 2.18 I think.

That said, if this example is in anyway how your program expects to
work, I highly recommend you take a different approach to the UI.  It's
a very unnatural way of working with a GUI element.  Personally if I had
to click OK or Cancel after each single movement of a slider I'd be
driven crazy (you mentioned multiple sliders too!).  If I needed to
change the value from 1 to 20, for example, I have to click OK 20 times!
   I didn't learn much in my UI class, but I'm pretty sure there has to
be a better way.

Now I don't know what you are trying to accomplish, but if I were
writing a program that needed to verify that a user really wanted to
change a value, I'd do it *after* the value had been changed.  On other
words, I'd let the user change the sliders to his hearts content and
then, depending on the scenario, either have a "revert" button that
undid everything and canceled the operation, or have an "apply" button
that would make the changes active (either for the slider itself or for
the dialog box as a whole).  If necessary I'd have the UI highlight
which UI elements had been changed (in case the user accidentally
changed a slider or something).

In other words, there has to be a better way!

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