Re: How can I port this gtk construct to gtkmm?
- From: Jef Driesen <jefdriesen hotmail com>
- To: Paul Davis <pjdavis engineering uiowa edu>
- Cc: gtkmm-list gnome org
- Subject: Re: How can I port this gtk construct to gtkmm?
- Date: Tue, 20 Mar 2007 16:38:58 +0100
Paul Davis wrote:
On 3/20/07, Jef Driesen <jefdriesen hotmail com> 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]
I think I'd make a column in your TreeModelColumnRecord a smart
pointer to the dialog.
I'm not certain what I'd do to delete the window when its closed. You
could connect to the dialog's signal_hide, bind the smart pointer to
the call back and search the tree view for the corresponding row, but
that seems rather inefficient. I suppose you could store weak pointers
in the tree view, the shared ptr's in a std::set and then your search
for the dialog to delete would be a bit faster.
Generally, I would only allow editing of a single row at a time to
prevent this but I could imagine there are times when having the
multiple row selection would be a good thing.
Storing a smart pointer in the treeview model is not the solution in my
case, because the treeview is not the only widget that can make the
dialog appear. That's why I liked the approach with the hashtable from
the code snippet. Because it doesn't matter at what place the function
is called, only one dialog will appear for the same object.
I was not planning to allow multiple row selections in the treeview. But
it is possible to edit more than one entry simultaneously (e.g activate
an item in the treeview, move to the next and activate that one also).
The treeview doesn't have to be notified directly by the dialog about
changes. I wanted to make the database engine (sqlite) responsible for
doing that.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]