Re: A queer problem

[Vlad Harchev <hvv hippo ru>]

On Thu, 10 Aug 2000, Nikhil Bhavadas K. wrote:

 Hi,

> 	I had written an application having a progress bar in a dialog window.
> As an illustration, I am sending a small GTK program that has a button, clicking
> on which a dialog window with a progress bar appears. 
> 	My first problem might be very common. How to force response on a
> dialog window? A quick look of FAQ did not reveal much details. In my
> program, every time you click on the button separate dialog windows appear. My
> requirement is that when a dialog window appears, a person should be able to
> click only on the dialog window and any click on the parent window should not
> have any affect. Let me say that many GTK+/GNOME programs show this behavior.
> My version of gnome-games(1.0.51) have some games like Same Gnome that show
> dialog windows every time you click on the close button on the top right
> window. Some programs like gEdit crashed when I clicked on the close button
> twice.

 Use gtk_window_set_modal (GTK_WINDOW(dialog),TRUE) for making window modal -
i.e. only that window will receive mouse and key events.

 As for bug in gedit you've described - report that bug on bugs.gnome.org
please.

> 	A queer problem seen when compiling and running this program is that
> when you create many dialog windows by clicking on the button, and killed some
> of them, error messages like
> > Gtk-CRITICAL **: file gtkprogress.c: line 554 (gtk_progress_set_value):
> > assertion `GTK_IS_PROGRESS (progress)' failed.

  Because you timeout function gets called, and it tries to use non-existing
progress bar.
 
> > Gtk-WARNING **: invalid cast from `(unknown)' to `GtkProgress'
> 
> appears. Now when trying to create another dialog window by clicking once more,
> the program segfaults with the message
> > Gtk-WARNING **: invalid cast from `GtkDialog' to `GtkProgress'

 This happens because malloc call returns the same memory location that was
occupied with already-destroyed progress bar.

> The behavior is unpredictable. Sometimes this occurs when we just move the mouse
> over the button.   	

 This happens because mallocs happen when you move the mouse (tooltips?).

> 	What is this `cast' problem? Where have I gone wrong? Or is this some
> bug? Sorry if the mail has become too long. I just wanted to state my
> problem clealry.
> 	Thanks!
> Regards,
>    Nikhil.
> -- 
> "Once a satyâgrahi, always a satyâgrahi"
> Nikhil Bhavadâs K. <nikhil@linuxstart.com>
> 		   <kaplingat@yahoo.com>	
> 

 Best regards,
  -Vlad