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

["Boggess Rod" <rboggess corefurnace com>]

LOL.  Yes, of course there is.  In the real-world code, it only pops up
if you've changed some text in one of the entry boxes without saving.
But that wasn't germane to the bug, so I stripped it out.  (I never
really imagined what the bug code would look like to an end user --
thank you for that image, I needed a laugh.)

This was the bare bones to demonstrate the problem.  If you can click
either button on the popup dialog, and the dialog goes away and stays
away, that's what I would expect.  So, thank you, that answers my
question.  It's either already be resolved in a newer release, or it
exists only as an HPUX implementation issue.  I may contact HP, but it
doesn't belong on the Gtk bug list.

> -----Original Message-----
> From: Michael Torrie [mailto:torriem gmail com] 
> Sent: Thursday, August 13, 2009 11:32 AM
> To: Boggess Rod
> Cc: Gtk app list
> Subject: 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.
> >
> > Thanks.
>
> 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!