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: James Farwell <email@hidden>
- Date: Fri, 4 Apr 2003 10:22:25 -0800
Chris,
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:
- (void)tableViewSelectionIsChanging:(NSNotification *)aNotification
{
static BOOL beforeTableFlag = NO;
static BOOL afterTableFlag = NO;
NSTableView *tableView = (NSTableView*) [aNotification object];
NSTableView *otherView = nil;
BOOL *flag, *otherFlag;
if ([tableView isEqual: _beforeList]) {
flag = &beforeFlag;
otherFlag = &afterTableFlag;
otherView = _afterList;
} else {
flag = &afterFlag;
otherFlag = &beforeTableFlag;
otherView = _beforeList;
}
if (!*otherFlag) {
*flag = YES;
*** Code to select row(s) ***
*flag = NO;
}
}
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!
- 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.