Jeffrey Barish wrote: > Gorshkov wrote: > >> I do this exact thing in an application I'm developing now. But I only >> do it in one place - a callback routine that is called for both the >> delete and destroy events. > > Thank you for your suggestions. > > I don't get a delete, destroy, or even a hide signal when the treeview > disappears because I switched to a different page of a notebook. I could, > of course, detect when I change pages of the notebook, but then I am off > plugging holes in the dike. The problem is that there are ways to get to > portions of my code that read the column-width file in which the treeview > has not been destroyed, so the column-width file has not been updated. I > suppose that this code will have to extract column widths from the treeview > rather than read them from the file, but then remote portions of the code > will need to be coupled to this treeview. The file was a neat way to > decouple the code because I need to store the widths anyway. There is > always a way to get around a limitation of a library, but I still wonder > why the GTK developers are comfortable with this limitation when other GUI > toolkits provide the appropriate signal.
You don't have to set the widths again every time you show them. When the TreeView becomes hidden/not hidden or visible/not visible, it will have the same properties and values it had the last time it was visible. The ONLY time you have set those values is when you display/realize the TreeView for the first time - I do it in my initialization code when I first create the widget. It's not a limitation in the library, because it's not a requirement - you're just thinking that you have to do something when you don't, because you had to do it that way in the other toolkits you've used. 2 of the 7 TreeViews in my application are also in tabs. And I can assure you that using a callback for those two signals, as I have, will handle every case you could possibly run into. Please note the call to SWSaveWindowGeometry() in SWSaveWindowPos() - because I also use these routines, and variants of them, to save the windows size and location on the screen so that they can be restored on startup as well. _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
