2

I have a UITableViewController subclass used for entering settings for my app. I add custom buttons to the table footer by adding them to a view that I return in he call to tableView:viewForFooterInSection:.

- (UIView *)tableView:(UITableView *)tableView viewForFooterInSection:(NSInteger)section 
{
    CGRect viewRect = self.view.bounds;
    float height = _settings.isNew ? 50.0 : 110.0;
    float margin = (viewRect.size.width > 480.0) ? 44.0 : 10.0; 
    UIView *view = [[UIView alloc] initWithFrame:CGRectMake(0, 0, viewRect.size.width, height)];    

    GradientButton* button = [[GradientButton alloc] initWithFrame:CGRectMake(margin, 5, viewRect.size.width - margin * 2, 44)];
    [view addSubview:button];
    [button addTarget:self action:@selector(testConnectionClicked:) forControlEvents:UIControlEventTouchUpInside];
    [button release];

    if (!_settings.isNew)
    {
    // I add another button
    }

    return [view autorelease];
}

- (CGFloat)tableView:(UITableView *)tableView heightForFooterInSection:(NSInteger)section 
{
    return _settings.isNew ? 50 : 110;
}

The whole point of subclassing from UITableViewController is to avoid problems with getting the cells scrolled into view when the keyboard appears.

This works mostly as it should, however when the edit moves to the last cell it seems to try to scroll the table footer into view. This means that it actually scrolls the editing textfield out of view when on iPhone in landscape view.

Xavi López
  • 27,550
  • 11
  • 97
  • 161
jonny
  • 111
  • 2
  • 6

5 Answers5

2

I solved this by adding an extra UIView below the tableview in my tableviewcontroller instead of setting some text in the footer of my last tableview section.

if you want that footer in multiple sections, this does not fix your problem of course.

Xavi López
  • 27,550
  • 11
  • 97
  • 161
wvdhaute
  • 71
  • 9
1

Taking a hint from @ben-packard's answer, I discovered that the UITableViewController auto-scrolling isn't at fault; it's actually UITableView's -scrollToRowAtIndexPath:atScrollPosition:animated: that's causing the view to scroll too far. I have to imagine this behavior is intentional even though it's not documented, but in any case we can fix it by subclassing UITableView and overriding that method:

- (void)scrollToRowAtIndexPath:(NSIndexPath *)indexPath atScrollPosition:(UITableViewScrollPosition)scrollPosition animated:(BOOL)animated {
    if (scrollPosition == UITableViewScrollPositionNone)
        [self scrollRectToVisible:[self rectForRowAtIndexPath:indexPath] animated:animated];
    else
        [super scrollToRowAtIndexPath:indexPath atScrollPosition:scrollPosition animated:animated];
}
phu
  • 1,199
  • 2
  • 10
  • 20
0

I found that scrolling to the rect instead (even though it is derived from the same row) seems to work:

CGRect rect = [myTableView rectForRowAtIndexPath:myIndexPath];
[myTableView scrollRectToVisible:rect animated:YES];
Ben Packard
  • 26,102
  • 25
  • 102
  • 183
0

Did you implement tableView:heightForFooterInSection? It sounds like that could be the problem. If you implement tableView:viewForFooterInSection you must also implement tableView:heightForFooterInSection.

morningstar
  • 8,952
  • 6
  • 31
  • 42
0

I suspect that the problem lies in your implementation of the scrolling on keyboard, but you didn't post any code from it.

Instead of subclassing a UITableView, why don't you do something like scrollToRowAtIndexPath:atScrollPosition:animated: when you do something that displays the keyboard? I found a similar thread here.

Community
  • 1
  • 1
Can
  • 8,502
  • 48
  • 57
  • 1
    I don't implement any scrolling on my own, as that is done automatically in UITableViewController - note that I don't subclass UITableView, but UITableViewController. That was done based on the answer from Sam Ho in the thread you mention. I have already tried most of the solutions in that thread without success, that is why I switched to the UITableViewController. – jonny Aug 29 '11 at 13:23