Re: Newbie Question: Best view for list of strings? (Addendum: weird horizontal scrollbar/resize issues)
Re: Newbie Question: Best view for list of strings? (Addendum: weird horizontal scrollbar/resize issues)
- Subject: Re: Newbie Question: Best view for list of strings? (Addendum: weird horizontal scrollbar/resize issues)
- From: Chris Giordano <email@hidden>
- Date: Fri, 4 Apr 2003 14:32:31 -0500
James,
On Friday, April 4, 2003, at 01:22 PM, James Farwell wrote:
Ok, cool, I'll check out tableViewColumnDidResize:. In terms of the
loop problem, I'm doing something similar with
tableViewSelectionIsChanging:, I wanted to make it so that selecting a
row in one table selects the same row in the other table, but
obviously, calling selectRow:byExtendingSelection: leads to another
call of tableViewSelectionIsChanging: for the opposite table. My
solution was to use a static boolean flag inside the function that the
function sets on the first call and clears when the first call is
finished, allowing further calls to the function to be able to tell if
it is running already or not,. It's a little odd, I admit, but it
seems to be working nicely, and its probably more thread-safe than
temporarily removing the delegate? Here is a simplified version of
the code:
<snip>
That thought passed through my mind very briefly, but it was a bit more
complicated than I wanted to deal with at the time. You could probably
do the same kind of thing with the resize handler, but I'd first look
at all of the times its called and the various values it's called with
(the column's width at the time it's called, the NSOldWidth in the
notification's userInfo, and your max string width) since I was getting
some unexpected results at times. Actually that method gets called
before the nib is loaded, so there can be some odd side effects if you
don't code things robustly enough, although you could also just make
sure that the tableView's delegate isn't hooked up until after the nib
is loaded.
As far as the other weird behavior I'm seeing with the nib fix, it
does seem to work in a majority of cases, but try this: resize the
window so the table is wider than the longest string and it no longer
needs the horizontal scrollbar, and then bring it back to its original
size. For me, the scrollbar reappears when the table becomes slightly
smaller than the biggest string, but then never scales itself with the
further reduction in width. It's almost as if the tableview is
autoresizing the column again, but it is keeping my pad so that the
end of the column is always #pad# units (pixels?) wider than the
clipped view. Very odd, I wonder if it has something to do with me
always keeping the column width and maxwidth the same? I'll try
implementing your delegate method to see if that works. Thanks a
bunch!
I tried to reproduce your results. The only time that it didn't work
as expected was when I had the table autoresize the columns and have
the column be resizable without using the tableViewColumnDidResize:
method (which gave me the expected original results where the scrollbar
disappeared when anything was resized). All other times the horizontal
scrollbar seemed to accurately reflect the proportion of the total
column displayed.
Uneducated guess: it has to do with the maxWidth. That's the only
difference so far as I can tell.
Good luck.
chris
- James
On Friday, April 4, 2003, at 08:51 AM, Chris Giordano wrote:
No problem, although I seem to not be having the all of the same
problems you are.
First, I'm not setting the maxWidth -- this might have something to
do with your issues. You might want to just set it to something big
and leave it. I also probably noticed that it tended not to like
using just the string's width, because I also pad the column width.
That, and looking at the old width passed in the notifications (see
below), the old width seemed to be truncated. (How that's related,
I'm not sure.)
To look at the issue, I took my code and built a little application
around it. The first thing I noticed was that I saw the same problem
that you were describing: the column width would correctly get set
when I added a new string to the table, but any type of resize would
cause the column width to be set to that of the table (I've also just
got one column in the table). I didn't originally notice before
because my window was not resizable.
So, I first made sure that my controller object was the delegate of
the table view and I implemented the -
(void)tableViewColumnDidResize:(NSNotification *)aNotification
method. I also added a variable to my controller class to store the
max string size (so I didn't have to recalculate it every single time
I wanted to use it). Each time I added an item (or removed one, but
I didn't bother implementing that in this test) I reset this max
value if necessary. Then, in the tableViewColumnDidResize: method,
if the current width was less than the max string length, I reset the
column width.
One thing to note was that changing the width in
tableViewColumnDidResize: caused tableViewColumnDidResize: to be
called again, so if this is the route you choose, it is crucial that
this method not allow the possibility of creating an endless loop
(i.e., don't always reset the column width, because this method gets
called whenever [NSTableColumn setWidth:] gets called, even if the
new column width isn't different than the old column width).
To resolve the endless loop issue, I tried unsetting the tableView's
delegate (setting it to nil) before changing the column width, and
then resetting it after. This should prevent this from happening.
The only issue here was that I was alternately getting a size of 8.0
for the column's width in the delegate method, so I was doing things
at least twice in most cases regardless.
Nonetheless, implementing the delegate method did solve the issue of
keeping the column's size set to an appropriate width when resizing.
After all of this, I also tried playing around with the nib.
Unchecking the "Resizable" box for the NSTableColumn also alleviated
this problem -- the column would no longer be resized every time I
resized the window. It didn't seem to make a difference for me
whether the NSTableView's "Autoresizes columns to fit" was checked or
unchecked.
Anyways, any further assistance you or anyone else could provide is
much appreciated. Thanks again for your help!
Hopefully this helps some. I'm at a bit of a loss to explain why the
nib fix wasn't working for you. I'm sure this solution's not perfect
-- it is a bit noisier that I'd prefer it to be, but it does seem to
get the results you're looking for.
_______________________________________________
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.