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! _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
