Re: NSTableView corrupts the last column
Re: NSTableView corrupts the last column
- Subject: Re: NSTableView corrupts the last column
- From: John Nairn <email@hidden>
- Date: Tue, 21 Oct 2003 16:51:31 -0600
I am using delegate/notification mechanism to track column size
changes. When a column is resized, my application records that change
and informs other documents that might have the same type of
information in view to resize its table too (there is one
application-wide table style but there may be many documents open using
that table). The problem was that resizing the window resizes the
column when I do not want it resized and during that window resizing,
there are continuous resize notifications to my table notification
code. These notifications trigger user-defined column changes when the
user likely did not think they changed the column size. Furthermore,
when multiple documents are open, it triggers coupled column resizes
that do make any sense with respect to actual window size in the other
document. There appears to be no way to turn off resize notifications
during window resize. Even telling the table that columns are not
resizeable does not work. In other words, when using a non-resize
setting for a table, a window resize causes non-resizeable columns to
resize?
I played around with trapping resize notifications of the last column
and blocking them by returning to current user-defined size, but that
has other problems. First I could not distinguish resize events
triggered by window resize from resize events triggered by user
dragging table column header lines. Also, NSTableView seems to need to
fill the NSClipView otherwise the table header does not draw fully and
appearance suffers.
The extra column is handling it all OK now despite all the special case
code required for the extra column.
I expect it is a non-issue for most applications because they will
simply ignore resizing which is handled automatically by NSTableView
letting the user select the size. My application, however, wants to
remember column sizes and reload them the next time the same type if
data is opened and viewed. In this mode it is preferable for column
sizes to be changed actively by user dragging column headers and not
passively by changing window sizes. The sizes my application remembers
are user preferences and not tied to window size. In contrast,
NSTableView is built around column sizes that are adjusted for current
window size. Its only two options are to resize all columns to fit or
resize the last column to fit. I need a third option to decouple
columns sizes from window size (and to extend the header to fill the
NSClipView if needed). The extra column is inelegant solution because
it takes up all needed slack to bridge the space between my
user-defined column settings and the current window size. The extra
column also absorbs all undesired resizes that occur during window
resizing.
I have posted a simple project having an NSTableView with n columns and
1 extra column. The resize and column dragging notifications handle all
special cases for last column and write NSLog() messages when they
encounter a true column resize or drag associated with real columns
(i.e., all but the last one). Column dragging is also adjusted to act
like the last column is not there (i.e., a drag of a column past the
extra column will be converted to drag that inserts it after the last
real column and before the extra column).
See
http://www.mse.utah.edu/~nairn/SimpleTable.sit (642 kB) for the
project.
On Tuesday, October 21, 2003, at 11:34 AM,
email@hidden wrote:
The point I don't get is why you don't use the delegate and
notification mechanism to set the size of the columns with code when
the window is being resized. You don't need an extra column.
El Martes, 21 octubre, 2003, a las 02:43 AM, Devin Lane escribis:
John
Sorry, I didn't mean for you to create the extra column with code, I
meant for you to do it in IB. Then, you can implement the delegate
[...]
------------
John Nairn (1-801-581-3413, FAX: 1-801-581-4816)
Web page:
http://www.eng.utah.edu/~nairn
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.