NSTableView in NSScrollView problems

[Duhov Fil]

I getting items using selector "view:'NSTableRowView' view:'NSTableCellView'", when I start my test it returns a lot of items, but when i scroll down the table it returns less and less then at start - only items that i can saw at start and see now, so when i scroll all the initial rows, it returns just [].

as example, if i have table

1

2

3

4

5

6

7

and my scroll can show just 3 items, at fist selector returns [1,2,3], when i scroll by one element it returns [2,3], then [3], and then [], when always see three of them.

[Duhov Fil]

Another problem is error:

frankly_map view:'NSTableRowView' view:'NSTableCellView' FEX_accessibilityLabel failed because: invalid selector

      -[AppDelegate tableView:objectValueForTableColumn:row:]: unrecognized selector sent to instance 0x10041ae40 (RuntimeError)

I get it when run tests when table data is updating, how can I analyse table when it updating?

[Michael Buckley]

It sounds like something might be going on in your application's tables.

First, here's the code that Frank uses to determine which rows to return, where "self" is your NSTableView.

CGRect visibleRect = [self visibleRect];

NSRange rowRange = [self rowsInRect: visibleRect];

If your rowRange.length is 0, you'll get no rows returned.

Second, It appears that you have a view-based table, but during update, Frank thinks that your table is cell-based.

Frank calls -viewAtColumn:row:makeIfNecessary: and -rowViewAtRow:makeIfNecessary: on your NSTableView to determine whether a row is view-based or cell-based. If either of these methods returns nil, it assumes your row is cell-based. However, it will only call these methods on the rows returned from the rowRange above. So your table is telling Frank that it has rows, but when Frank asks for these rows, your table returns nil.

I don't think this is standard table behavior. However, it may be I'm missing something. I will take a look when I have some more time. Hopefully in about 8 hours from now.

--
You received this message because you are subscribed to the Google Groups "Frank" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frank-discus...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Buckley]

I have been trying to reproduce this behavior using a few view-based tables, including the NSTableViewPlayground sample code provided by Apple. https://developer.apple.com/librarY/mac/samplecode/TableViewPlayground/Introduction/Intro.html

I could not reproduce the problem. It is possible that you are updating the data differently than my tests, and Frank doesn't account for this. If you can send me a sample project showing the problem I can help to debug it. Thanks!

[Duhov Fil]

I failed with creating sample project with second problem.. I can only add that for some reason this error also appears with "view:'NSTabViewItem' marked:'#{tabName}'" - I can`t imagine why.

But first questions isn`t answered. NSRange rowRange = [self rowsInRect: visibleRect]; returns normal length, i create sample project to show it - https://github.com/FilippDuhov/FrankIssue.git, last commit "invisible rows".

вторник, 10 декабря 2013 г., 6:34:56 UTC+2 пользователь Michael Buckley написал:

[Michael Buckley]

I think I've narrowed this down to a problem in Shelley. Symbiote and the frankly_dump command have no problem seeing the rows. 

It also only appears to affect tables that use bindings. Tables that use data sources seem to be OK. I will look into this and try to get a fix out soon.

[Michael Buckley]

This turned out to be caused by a very stupid bug on my part. I have fixed the bug for the next release. In the meantime, you can download a fixed version of Frank at http://www.buckleyisms.com/storage/libFrankMac.a.zip

[Duhov Fil]

Thanks!

About second problem, you said "Frank calls -viewAtColumn:row:makeIfNecessary: and -rowViewAtRow:makeIfNecessary ...", so I create CustomTableView and overload these functions by setting makeIfNecessary=YES, and it solved my problem. I think I'm not quite correctly working with the table, but Frank is only one who care about it..

среда, 11 декабря 2013 г., 5:37:02 UTC+2 пользователь Michael Buckley написал: