Re: Apparent NSTableView Bug
Corbin- Looks like [myTableView setAllowsColumnSelection:NO]; stopped the crashing for now (I'm sure I've made plenty of other mistakes that are lurking in the dark) Thanks for the tip! -dan___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Apparent NSTableView Bug
It's definitely a bug in AppKit; thank you for logging it, and including a test
case.
Try setting -setAllowsColumnSelection:NO. That work?
corbin
On Jan 28, 2010, at 2:00 PM, Daniel Wambold wrote:
> I have run up against an apparent 10.6.2 bug in the NSTableView object.
> Specifically, if NSTableViewSelectionHighlightStyleNone is set, the tableView
> causes Assertion failures and other problems. Below is some code
> demonstrating the problem. In any event, I need to emulate the None style for
> highlight in my TableView. Does anyone know how to set the highlight color,
> perhaps, to clearColor or something with a tiny alpha value so it
> approximates the None appearance? I can live with undocumented changes, as
> the program will run on a system with a fixed OS, and I can un-hack the
> NSTableView when the problem is repaired. (Radar ID# 7588256). If I've done
> something wrong and this code is the problem, please tell me, as I'm sort of
> stuck for now.
> Thanks!
> -Dan
>
> Sample code: create a new Cocoa project, drag a tableView into IB, wire it to
> your controller. When you add a row, click on the header, then on the
> tableView cell. If you comment out the highlightStyle line, this aberrant
> behavior disappears.
>
> @implementation MArrayCont
>
> - (void)awakeFromNib
> {
> mColTitles = [[NSArray arrayWithObjects:@"One", @"Two", nil] retain];
> NSArray *mCols = [myTableView tableColumns];
> int i=0;
> for (NSTableColumn *aCol in mCols)
> {
> [aCol bind:@"value" toObject:self
> withKeyPath:[NSString stringWithFormat:@"arrangedObjects.%@",
> [mColTitles objectAtIndex:i]]
> options:nil];
> i++;
> }
> [myTableView
> setSelectionHighlightStyle:NSTableViewSelectionHighlightStyleNone];
>
> }
>
> - (IBAction)add:(id)sender
> {
> NSMutableDictionary *mNewRow = [[[NSMutableDictionary alloc] init]
> autorelease];
> int i=[[self content] count]; // Just provides some
> uniqueness to each entry.
> for (NSString *aColTitle in mColTitles)
> {
> [mNewRow setObject:[NSString stringWithFormat:@"%i: %@",i,
> aColTitle] forKey:aColTitle];
> }
> [self addObject:mNewRow];
> }
>
> - (void)dealloc
> {
> [mColTitles release];
> [super dealloc];
> }
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Apparent NSTableView Bug
I have run up against an apparent 10.6.2 bug in the NSTableView object.
Specifically, if NSTableViewSelectionHighlightStyleNone is set, the tableView
causes Assertion failures and other problems. Below is some code demonstrating
the problem. In any event, I need to emulate the None style for highlight in my
TableView. Does anyone know how to set the highlight color, perhaps, to
clearColor or something with a tiny alpha value so it approximates the None
appearance? I can live with undocumented changes, as the program will run on a
system with a fixed OS, and I can un-hack the NSTableView when the problem is
repaired. (Radar ID# 7588256). If I've done something wrong and this code is
the problem, please tell me, as I'm sort of stuck for now.
Thanks!
-Dan
Sample code: create a new Cocoa project, drag a tableView into IB, wire it to
your controller. When you add a row, click on the header, then on the tableView
cell. If you comment out the highlightStyle line, this aberrant behavior
disappears.
@implementation MArrayCont
- (void)awakeFromNib
{
mColTitles = [[NSArray arrayWithObjects:@"One", @"Two", nil] retain];
NSArray *mCols = [myTableView tableColumns];
int i=0;
for (NSTableColumn *aCol in mCols)
{
[aCol bind:@"value" toObject:self
withKeyPath:[NSString stringWithFormat:@"arrangedObjects.%@",
[mColTitles objectAtIndex:i]]
options:nil];
i++;
}
[myTableView
setSelectionHighlightStyle:NSTableViewSelectionHighlightStyleNone];
}
- (IBAction)add:(id)sender
{
NSMutableDictionary *mNewRow = [[[NSMutableDictionary alloc] init]
autorelease];
int i=[[self content] count]; // Just provides some
uniqueness to each entry.
for (NSString *aColTitle in mColTitles)
{
[mNewRow setObject:[NSString stringWithFormat:@"%i: %@",i,
aColTitle] forKey:aColTitle];
}
[self addObject:mNewRow];
}
- (void)dealloc
{
[mColTitles release];
[super dealloc];
}
@end___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On 2 Jul 2009, at 11:10 AM, Greg Guerin wrote: Hold down the Option key and drag the thumb. It should "micro scroll" for as long as Option remains down. This scroller gesture modifier has been around for a while. Wow. Never heard about this one before. I wonder how many people know about this rather obscure feature? -- Tito ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
Tito Ciuro wrote: Not to mention that dragging the scroll thumb one pixel will result in thousands of rows scrolled at once. Simply useless. Hold down the Option key and drag the thumb. It should "micro scroll" for as long as Option remains down. This scroller gesture modifier has been around for a while. I still agree with the basic criticism: a huge scrolling table of hex isn't a great view. I don't think option-modified micro-scrolling greatly improves it, either. At best, it prevents the scroll thumb from being useless. Damning by faint praise. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
I was going to recommend 0xED is a good one too. Very fast and he appears to be using a custom view of somesort. Scott On Jul 2, 2009, at 10:21 AM, Jean-Daniel Dupas wrote: I've created a simple application with an NSTableView. I have written a delegate for this table, numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the number of rows in the table when requested. My application uses the table view to display hexadecimal data on a flash memory chip, with 16 bytes displayed per row. As a test, I tried returning a large number for the number of rows, 0x100. When I scroll through the table, everything looks okay for the first 14 million rows or so, after which the gray horizonal cell separator disappears and the row data begins to shift by a pixel per row, until it eventually is superimposed on the row above it. This seems like a bug with the NSTableView class, but perhaps I'm doing something wrong. Has anyone else run into this problem? My 2 cents, If you're looking for a (very) efficient and clean way to display large amount of binary data, have a look at HexFiend. This is the fastest hex editor I know. It's able to handle multi Gbytes files smoothly and without problem (and it's distributed under modified BSD license). http://ridiculousfish.com/hexfiend/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/scottandrew%40roadrunner.com This email sent to scottand...@roadrunner.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
I've created a simple application with an NSTableView. I have written a delegate for this table, numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the number of rows in the table when requested. My application uses the table view to display hexadecimal data on a flash memory chip, with 16 bytes displayed per row. As a test, I tried returning a large number for the number of rows, 0x100. When I scroll through the table, everything looks okay for the first 14 million rows or so, after which the gray horizonal cell separator disappears and the row data begins to shift by a pixel per row, until it eventually is superimposed on the row above it. This seems like a bug with the NSTableView class, but perhaps I'm doing something wrong. Has anyone else run into this problem? My 2 cents, If you're looking for a (very) efficient and clean way to display large amount of binary data, have a look at HexFiend. This is the fastest hex editor I know. It's able to handle multi Gbytes files smoothly and without problem (and it's distributed under modified BSD license). http://ridiculousfish.com/hexfiend/ ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On Jul 2, 2009, at 1:11 PM, Tito Ciuro wrote: I totally agree. I would never present anywhere that much info to the user. It's overwhelming and difficult to navigate through. My comment referred to a bad approach in design: I was adding another argument as to why displaying 14 million rows in a table view is a bad, bad idea. I don't see this as a limitation of NSTableView at all. Ah, very good. (takes finger off poo-flinging machine's launch button) ;-) -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On 2 Jul 2009, at 9:56 AM, I. Savant wrote: On Jul 2, 2009, at 12:52 PM, Tito Ciuro wrote: Not to mention that dragging the scroll thumb one pixel will result in thousands of rows scrolled at once. Simply useless. Well, yes, but the only real way to avoid that is to design your application to limit the amount of data presented to the user. It's not an argument against the table view / scroll view mechanism so much as an argument against an overall UI approach that relies on that mechanism to display thousands and thousands of rows of data, which is rarely useful in itself ... -- I.S. I totally agree. I would never present anywhere that much info to the user. It's overwhelming and difficult to navigate through. My comment referred to a bad approach in design: I was adding another argument as to why displaying 14 million rows in a table view is a bad, bad idea. I don't see this as a limitation of NSTableView at all. -- Tito ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On Jul 2, 2009, at 12:52 PM, Tito Ciuro wrote: Not to mention that dragging the scroll thumb one pixel will result in thousands of rows scrolled at once. Simply useless. Well, yes, but the only real way to avoid that is to design your application to limit the amount of data presented to the user. It's not an argument against the table view / scroll view mechanism so much as an argument against an overall UI approach that relies on that mechanism to display thousands and thousands of rows of data, which is rarely useful in itself ... -- I.S. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On 2 Jul 2009, at 9:36 AM, Shawn Erickson wrote: On Thu, Jul 2, 2009 at 8:37 AM, Michael Ash wrote: On Thu, Jul 2, 2009 at 10:51 AM, Chris Carson wrote: Hello, I've created a simple application with an NSTableView. I have written a delegate for this table, numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the number of rows in the table when requested. My application uses the table view to display hexadecimal data on a flash memory chip, with 16 bytes displayed per row. As a test, I tried returning a large number for the number of rows, 0x100. When I scroll through the table, everything looks okay for the first 14 million rows or so, after which the gray horizonal cell separator disappears and the row data begins to shift by a pixel per row, until it eventually is superimposed on the row above it. This seems like a bug with the NSTableView class, but perhaps I'm doing something wrong. Has anyone else run into this problem? Known problem: http://www.google.com/search?client=safari&rls=en-us&q=nstableview+14+million&ie=UTF-8&oe=UTF-8 Either restrict your app to running in 64-bit mode (which will cause the graphics system to use doubles instead of floats) or write a custom control. ...or seriously reconsider the utility (expectation) of having millions of row in a table view. Do users really want to scroll thru that many rows? Can users work with that much data? etc. In other words will this really be a problem without first causing usability problems for your users. Not to mention that dragging the scroll thumb one pixel will result in thousands of rows scrolled at once. Simply useless. -- Tito ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On Thu, Jul 2, 2009 at 8:37 AM, Michael Ash wrote: > On Thu, Jul 2, 2009 at 10:51 AM, Chris Carson wrote: >> >> Hello, >> >> I've created a simple application with an NSTableView. I have written a >> delegate for this table, >> numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the >> number of rows in the table when requested. >> >> My application uses the table view to display hexadecimal data on a flash >> memory chip, with 16 bytes displayed per row. As a test, I tried returning a >> large number for the number of rows, 0x100. When I scroll through the >> table, everything looks okay for the first 14 million rows or so, after >> which the gray horizonal cell separator disappears and the row data begins >> to shift by a pixel per row, until it eventually is superimposed on the row >> above it. This seems like a bug with the NSTableView class, but perhaps I'm >> doing something wrong. Has anyone else run into this problem? > > Known problem: > > http://www.google.com/search?client=safari&rls=en-us&q=nstableview+14+million&ie=UTF-8&oe=UTF-8 > > Either restrict your app to running in 64-bit mode (which will cause > the graphics system to use doubles instead of floats) or write a > custom control. ...or seriously reconsider the utility (expectation) of having millions of row in a table view. Do users really want to scroll thru that many rows? Can users work with that much data? etc. In other words will this really be a problem without first causing usability problems for your users. -Shawn ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
I had this problem but it had to do with calculating the height for the row and returning a float value. When i made sure i returned an int this went away. Not sure if you doing that. Scott On Jul 2, 2009, at 7:51 AM, Chris Carson wrote: Hello, I've created a simple application with an NSTableView. I have written a delegate for this table, numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the number of rows in the table when requested. My application uses the table view to display hexadecimal data on a flash memory chip, with 16 bytes displayed per row. As a test, I tried returning a large number for the number of rows, 0x100. When I scroll through the table, everything looks okay for the first 14 million rows or so, after which the gray horizonal cell separator disappears and the row data begins to shift by a pixel per row, until it eventually is superimposed on the row above it. This seems like a bug with the NSTableView class, but perhaps I'm doing something wrong. Has anyone else run into this problem? Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/scottandrew%40roadrunner.com This email sent to scottand...@roadrunner.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSTableView bug?
On Thu, Jul 2, 2009 at 10:51 AM, Chris Carson wrote: > > Hello, > > I've created a simple application with an NSTableView. I have written a > delegate for this table, > numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the > number of rows in the table when requested. > > My application uses the table view to display hexadecimal data on a flash > memory chip, with 16 bytes displayed per row. As a test, I tried returning a > large number for the number of rows, 0x100. When I scroll through the > table, everything looks okay for the first 14 million rows or so, after which > the gray horizonal cell separator disappears and the row data begins to shift > by a pixel per row, until it eventually is superimposed on the row above it. > This seems like a bug with the NSTableView class, but perhaps I'm doing > something wrong. Has anyone else run into this problem? Known problem: http://www.google.com/search?client=safari&rls=en-us&q=nstableview+14+million&ie=UTF-8&oe=UTF-8 Either restrict your app to running in 64-bit mode (which will cause the graphics system to use doubles instead of floats) or write a custom control. Mike ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
NSTableView bug?
Hello, I've created a simple application with an NSTableView. I have written a delegate for this table, numberOfRowsInTableView:objectValueForTableColumn:row:, that returns the number of rows in the table when requested. My application uses the table view to display hexadecimal data on a flash memory chip, with 16 bytes displayed per row. As a test, I tried returning a large number for the number of rows, 0x100. When I scroll through the table, everything looks okay for the first 14 million rows or so, after which the gray horizonal cell separator disappears and the row data begins to shift by a pixel per row, until it eventually is superimposed on the row above it. This seems like a bug with the NSTableView class, but perhaps I'm doing something wrong. Has anyone else run into this problem? Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
