The GUI I made using Glade/GTK does not end

thatchergrey · 01-17-2009, 06:53 AM

Language:C
OS: Windows XP
IDE: Bloodshed DevC++
(I used Glade for Windows based on Glade 2.6.0)

I made a simple front end using Glade/GTK+. My problem is that even after closing the program (meaning clicking the X button), the program is still running. If I check Task Manager, I can see that the process *.exe, which is the executable I got after compiling and building my program, is still running. So what I do each time is to manually kill the process.

Does anyone have ideas on how this can be resolved. Below is the main.c of my project.

Code:

/*
 * Initial main.c file generated by Glade. Edit as required.
 * Glade will not overwrite this file.
 */

#ifdef HAVE_CONFIG_H
#  include <config.h>
#endif

#include <gtk/gtk.h>

#include "interface.h"
#include "support.h"

#ifdef G_OS_WIN32
char *package_prefix;
char *package_datadir;
#endif

int
main (int argc, char *argv[])
{
  GtkWidget *window1;

#ifdef G_OS_WIN32
  gchar *temp;

  package_prefix = g_win32_get_package_installation_directory (NULL, NULL);
  package_datadir = g_strdup_printf ("%s%s", package_prefix, "/share");
#endif

#ifdef ENABLE_NLS
#ifdef G_OS_WIN32
  temp = g_strdup_printf ("%s%s", package_prefix, "/lib/locale");
  bindtextdomain (GETTEXT_PACKAGE, temp);
  g_free (temp);
#else
  bindtextdomain (GETTEXT_PACKAGE, PACKAGE_LOCALE_DIR);
#endif
  bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
  textdomain (GETTEXT_PACKAGE);
#endif

  gtk_set_locale ();
  gtk_init (&argc, &argv);

#ifdef G_OS_WIN32
//  temp = g_strdup_printf ("%s/%s%s", package_datadir, PACKAGE, "/pixmaps");
 // add_pixmap_directory (temp);
 // g_free (temp);
#else
//  add_pixmap_directory (PACKAGE_DATA_DIR "/" PACKAGE "/pixmaps");
#endif


  /*
   * The following code was added by Glade to create one of each component
   * (except popup menus), just so that you see something after building
   * the project. Delete any components that you don't want shown initially.
   */
  window1 = create_window1 ();
  gtk_widget_show (window1);

  gtk_main ();

#ifdef G_OS_WIN32
  g_free (package_prefix);
  g_free (package_datadir);
#endif
  return 0;
}

thatchergrey · 01-17-2009, 07:04 AM

The thing I tried was altering my callbacks.c file.

I figured that the right exit mechanism should be inside the on_window1_destroy_event () function of my callbacks.c file.

So I tried the following.

Code:

gboolean
on_window1_destroy_event               (GtkWidget       *widget,
                                        GdkEvent        *event,
                                        gpointer         user_data)
{
  exit(0);
}

I also tried this:

Code:

gboolean
on_window1_destroy_event               (GtkWidget       *widget,
                                        GdkEvent        *event,
                                        gpointer         user_data)
{
  gtk_main_quit();
  return FALSE;
}

Neither worked.

MK27 · 01-17-2009, 08:47 AM

The "on destroy" signal handler function has to be connected to the top level window inside the gtk loop in main() (that is, after the window is defined but before gtk_main();), otherwise those functions are not actually called by anything. I don't use windows so I'm not sure if it's the same, but at least with linux/X you have to account for two possible termination signals from the window manager -- the normal "close" which is a delete_event and also the potential destroy:

Code:

g_signal_connect (G_OBJECT (window1), "delete_event", G_CALLBACK (on_window1_destroy_event), NULL);
g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (on_window1_destroy_event), NULL);

You definitely want to use your second version of the function, with gtk_main_quit() and not the one with exit(). You can make it a void rather than a gboolean as well (and take out "return FALSE"). That setup is for when you have two seperate callbacks, one for delete and one for destroy, wherein the delete function calls the destroy function expecting a FALSE -- but it seems unnecessary unless you have some more complicated reason for using two seperate functions, so you can just use the one:

Code:

void on_window1_destroy_event() {
          gtk_main_quit();
}

In fact, when I write small experiments like this that don't require any further clean-up at the end, I just use:

Code:

g_signal_connect (G_OBJECT (window1), "delete_event", G_CALLBACK (gtk_main_quit), NULL);
g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (gtk_main_quit), NULL);

Which is what you might as well do. There is a great gtk+ forum, b/t/w.

ps. I think using glade will only make writing and comprehending your own programs more difficult in the long run.

thatchergrey · 01-17-2009, 10:02 AM

Quote:

Originally Posted by MK27

The "on destroy" signal handler function has to be connected to the top level window inside the gtk loop in main() (that is, after the window is defined but before gtk_main();), otherwise those functions are not actually called by anything. I don't use windows so I'm not sure if it's the same, but at least with linux/X you have to account for two possible termination signals from the window manager -- the normal "close" which is a delete_event and also the potential destroy:

Code:

g_signal_connect (G_OBJECT (window1), "delete_event", G_CALLBACK (on_window1_destroy_event), NULL);
g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (on_window1_destroy_event), NULL);

You definitely want to use your second version of the function, with gtk_main_quit() and not the one with exit(). You can make it a void rather than a gboolean as well (and take out "return FALSE"). That setup is for when you have two seperate callbacks, one for delete and one for destroy, wherein the delete function calls the destroy function expecting a FALSE -- but it seems unnecessary unless you have some more complicated reason for using two seperate functions, so you can just use the one:

Code:

void on_window1_destroy_event() {
          gtk_main_quit();
}

In fact, when I write small experiments like this that don't require any further clean-up at the end, I just use:

Code:

g_signal_connect (G_OBJECT (window1), "delete_event", G_CALLBACK (gtk_main_quit), NULL);
g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (gtk_main_quit), NULL);

Which is what you might as well do. There is a great gtk+ forum, b/t/w.

ps. I think using glade will only make writing and comprehending your own programs more difficult in the long run.

Thank you MK27! Although the code you posted did not work for me (for reasons I still cannot fully comprehend), it gave me an idea on how to resolve my process termination issue.

This is the code I used, which is obviously patterned after yours.

Code:

  gtk_signal_connect(GTK_OBJECT(window1), "delete_event", gtk_main_quit, NULL);
  gtk_signal_connect(GTK_OBJECT(window1), "destroy", gtk_main_quit, NULL);

If you have more insights on this, please do share them.

Again, thank you so much!

MK27 · 01-17-2009, 10:08 AM

Quote:

Originally Posted by thatchergrey

Code:

  gtk_signal_connect(GTK_OBJECT(window1), "delete_event", gtk_main_quit, NULL);
  gtk_signal_connect(GTK_OBJECT(window1), "destroy", gtk_main_quit, NULL);

If you have more insights on this, please do share them.

Again, thank you so much!

Great if it works! In my experience with gtk, it can be very picky about typecasting, so with a normal callback function you may need the cast G_CALLBACK(function). Strange that it caused a problem with gtk_main_quit -- anyway good luck and have fun.

01-17-2009, 07:04 AM	#2
thatchergrey Registered User Join Date: Jan 2009 Posts: 7	Changing my callbacks.c file did not work The thing I tried was altering my callbacks.c file. I figured that the right exit mechanism should be inside the on_window1_destroy_event () function of my callbacks.c file. So I tried the following. Code: gboolean on_window1_destroy_event (GtkWidget widget, GdkEvent event, gpointer user_data) { exit(0); } I also tried this: Code: gboolean on_window1_destroy_event (GtkWidget widget, GdkEvent event, gpointer user_data) { gtk_main_quit(); return FALSE; } Neither worked.
thatchergrey is offline

01-17-2009, 08:47 AM	#3
MK27 subminimalist Join Date: Jul 2008 Location: NYC Posts: 3,944	The "on destroy" signal handler function has to be connected to the top level window inside the gtk loop in main() (that is, after the window is defined but before gtk_main();), otherwise those functions are not actually called by anything. I don't use windows so I'm not sure if it's the same, but at least with linux/X you have to account for two possible termination signals from the window manager -- the normal "close" which is a delete_event and also the potential destroy: Code: g_signal_connect (G_OBJECT (window1), "delete_event", G_CALLBACK (on_window1_destroy_event), NULL); g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (on_window1_destroy_event), NULL); You definitely want to use your second version of the function, with gtk_main_quit() and not the one with exit(). You can make it a void rather than a gboolean as well (and take out "return FALSE"). That setup is for when you have two seperate callbacks, one for delete and one for destroy, wherein the delete function calls the destroy function expecting a FALSE -- but it seems unnecessary unless you have some more complicated reason for using two seperate functions, so you can just use the one: Code: void on_window1_destroy_event() { gtk_main_quit(); } In fact, when I write small experiments like this that don't require any further clean-up at the end, I just use: Code: g_signal_connect (G_OBJECT (window1), "delete_event", G_CALLBACK (gtk_main_quit), NULL); g_signal_connect (G_OBJECT (window1), "destroy", G_CALLBACK (gtk_main_quit), NULL); Which is what you might as well do. There is a great gtk+ forum, b/t/w. ps. I think using glade will only make writing and comprehending your own programs more difficult in the long run. __________________ Accuracy and integrity mean nothing if you don't make it past the censors...PYTHAGORAS
MK27 is offline

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
GUI Programming...	ShadeS_07	C++ Programming	12	12-28-2008 04:58 PM
socket newbie, losing a few chars from server to client	registering	Linux Programming	2	06-07-2003 11:48 AM
Next Question...	Azmeos	C++ Programming	3	06-06-2003 02:40 PM
Problem building Quake source	Silvercord	Game Programming	14	01-25-2003 10:01 PM
Collision with quads?	SyntaxBubble	Game Programming	6	01-18-2002 06:17 PM