Calling numberOfRowsInSection on a UITableView

175 views
Skip to first unread message

David van der Bokke

unread,
Jun 23, 2011, 12:43:46 PM6/23/11
to Frank
I am having issues calling numberOfRowsInSection on a UITableView. I
am using the following command:

frankly_map( "tableView", "numberOfRowsInSection", i)

"i" in this case is a numeric value indicating the section I want.
The result of this is always null. I traced this back in XCode and
found that "numberOfRowsInSection" is not being found as a valid
selector for the table view.

As an aside "frankly_map( "tableView", "numberOfSections")" does work
as expected and returns the number of sections.

Any help is appreciated.

Pete Hodgson

unread,
Jun 23, 2011, 2:48:49 PM6/23/11
to frank-...@googlegroups.com
I think maybe you need a trailing colon, since the message signature has a parameter. Try:

frankly_map( "tableView", "numberOfRowsInSection:", i)


Maybe frankly_map should raise an error if it looks like the signature doesn't match up with the number of parameters being passed?

David van der Bokke

unread,
Jun 23, 2011, 2:55:27 PM6/23/11
to Frank
That allowed it to be identified. The result is wrong so I need to
dig into that.

Out of curiosity.. what does the signature look like if there are
multiple params? The code is already setup to raise an error if the
number of arguments doesn't match, but it really wasn't clear that the
":" was necessary.

Pete Hodgson

unread,
Jun 23, 2011, 3:15:10 PM6/23/11
to frank-...@googlegroups.com
The way the signatures are represented in Objective C is basically just to strip out the parameter parts. So for example
    + (id)stringWithCharacters:(const unichar *)chars length:(NSUInteger)length
has a signature of
    stringWithCharacters:length:

For furher examples you can look at how the apple docs describe message. For example, check out the NSString docs: http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/Foundation/Classes/NSString_Class/Reference/NSString.html


Hope that helps,
Pete

David van der Bokke

unread,
Jun 23, 2011, 3:26:43 PM6/23/11
to Frank
Found the problem.. which leads to a new question.

In the applyToObject function of Operation.m there is this piece of
code to map arguments:

NSInteger index = 2; // Indices 0 and 1 indicate the hidden arguments
self and _cmd, respectively
for( id arg in _arguments ) {
[invocation setArgument:&arg atIndex:index++];
}

There seems to be some problem when you need to pass an
integer(basically the method seems to just get a random value passed
in). If I manually create an int and pass that then it works
properly. Perhaps we need to special case some of the argument types
so they aren't all just passed as a buffer?

Pete Hodgson

unread,
Jun 24, 2011, 2:22:26 AM6/24/11
to frank-...@googlegroups.com
This looks like the same issue I have been having running battles with for ages. In some cases numbers that are sent over the wire to Objective-C-land need to be treated as raw C values. In other cases they should NSNumbers. The invocation API doesn't really make this easy to deal with, and so there are cases where we discover we don't support invocations that need NSNumber instances, or alternatively ones that need raw C values.

This is definitely a solvable problem, it's just a case of finding a test case that brings the bug to light and then squishing it. Looks like this might be just such a bug.

I continue to be surprised at how fiddly it is to use NSInvocation, NSMethodSignature, with all their attendant corner-cases. Does anyone know of some kind of magical remote invocation library that makes this pain go away?

Pete Hodgson

unread,
Jun 24, 2011, 4:23:01 AM6/24/11
to frank-...@googlegroups.com
Hi David,

I think I have a fix for this checked into the main Frank repo now - https://github.com/moredip/Frank/commit/ebb550742f7a35458932a2fe449613752c6537e3

Please try it out and definitely let us know if I haven't resolved the issue.

Cheers,
Pete

David van der Bokke

unread,
Jun 24, 2011, 1:58:32 PM6/24/11
to Frank
I tried out your fix.. it seems to work for my case and looks a lot
better than the quick hack I put in.

Thanks

On Jun 24, 3:23 am, Pete Hodgson <phodg...@thoughtworks.com> wrote:
> Hi David,
>
> I think I have a fix for this checked into the main Frank repo now -https://github.com/moredip/Frank/commit/ebb550742f7a35458932a2fe44961...
> .
>
> Please try it out and definitely let us know if I haven't resolved the
> issue.
>
> Cheers,
> Pete
>
Reply all
Reply to author
Forward
0 new messages