Re: Treeview column width changed signal

[Gorshkov <listsubscriptions oghma on ca>]

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.