Re: How can I port this gtk construct to gtkmm?



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]