Re: A queer problem
- From: Vlad Harchev <hvv hippo ru>
- To: nikhil linuxstart com
- Cc: GTK <gtk-list gnome org>
- Subject: Re: A queer problem
- Date: Thu, 10 Aug 2000 12:24:19 +0500 (SAMST)
On Thu, 10 Aug 2000, Nikhil Bhavadas K. wrote:
> 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
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
> 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
> > 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.
> "Once a saty‚grahi, always a saty‚grahi"
> Nikhil Bhavad‚s K. <firstname.lastname@example.org>
] [Thread Prev