Jonathon Jongsma wrote: > On 3/20/07, Jef Driesen <[EMAIL PROTECTED]> wrote: >> I am writing my first gtkmm application (actually my first GUI >> application). To get familiar with the toolkit (both gtk and gtkmm), I >> studied the code of some existing applications. And in one of those >> applications I found a construct that I would like to use in my own >> application, but I don't know how to port the gtk code to gtkmm. >> >> The main application contains a treeview and a secondary dialog is used >> to edit the treeview entries. But if you try to edit an entry that is >> already "open", the existing dialog is activated instead of creating a >> new one (see code snippet below). How can I do this in C++? >> >> And how do I automatically destroy the dialog after clicking the (close) >> button? >> >> [code removed] > > Well, first of all, you'd probably want to replace the g_hash_table > stuff with a std::map<> type. You might even want to store the Dialog > pointer in a smart pointer so that when you remove the item from the > std::map, the Dialog is deleted automatically. Something like this: > > std::map<myobject*, boost::shared_ptr<Gtk::Dialog> > dialogs; > > // when you need to add a new dialog to the cache: > dialogs[obj] = boost::shared_ptr<Gtk::Dialog>(new Gtk::Dialog()); > > // then in a signal handler: this should remove the item from the map and > // automatically free the dialog you allocated earlier since you're > using a smart pointer > dialogs.erase (obj); > > The signal handling should be pretty similar to the existing code, but > would use libsigc++ type signal connections instead of the > g_signal_connect() stuff. for example: > g_signal_connect (close_button, > "clicked", > G_CALLBACK (myobject_dialog_close_clicked_cb), > dialog); > would become something like: > close_button.signal_clicked ().connect > (sigc::ptr_fun(myobject_dialog_close_clicked_cb)); > > But it might be easier to just create a new Dialog class that inherits > from Gtk::Dialog and provide implementations for its virtual signal > handler methods (such as on_delete_event(), etc) instead of manually > connecting to the signals. > Hope that helps. (note that I haven't tested any of the code snippets I > posted)
Actually my problem is not how to connect signals or use C++ features like the std::map for instance. The first problem was that I was trying to incorporate the functionality of the myobject_dialog_new function (construction of the widget and maintaining the cache) inside the constructor of the dialog class. And I could not come up with a way to return an existing dialog from the cache, because the C++ constructor does not return any value. Moving the cache outside the constructor or even the dialog class (like you did), will solve that problem I think. And the second was the automatic destruction of the dialog without the need to keep a pointer to it somewhere. Trying to do the same thing in C++ resulted either in a memory leak or immediate destruction of the dialog (when its variable goes out of scope). _______________________________________________ gtkmm-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtkmm-list
