views:

2292

answers:

3

I've got a button that I'm adding as a subview of a table view's tableHeaderView. The button appears fine, and tap-and-holding on it works intermittently - for the most part, though, it's unresponsive. I've tried adding it as a subview of the table itself; the effect is about the same. I thought the problem might be with the scroll view's touch interception, but disabling scrolling on the table has no effect either.

Am I doing something wrong? Has anyone else encountered this?

edit - to clarify, I'm talking about the main table header, not a section header, in a grouped-style table; think basically modeled after the "Contact" screen.

A: 

You should consider that this is not the intended sue of the headerView and that an implementation such as that might result in rejection from the AppStore as a result of a HIG violation. Given that the dimensions of a header are intended to be small, it is probably better to consider a restructuring of your view. Having said that, there is no easy way to do it short of hand detecting touch events and determining the geometry yourself, then executing a selector based on the geometry - in short, rolling your own button class.

wisequark
I can't find anything in the HIG prohibiting the use of buttons in table (as opposed to section) header/footer views; the Contacts app attaches buttons to the table footer without issue, and Apple's "HeaderFooter" sample does something similar (though it exhibits the same problem). Radar, maybe?
Noah Witherspoon
More likely than not I would suggest filing a bug.
wisequark
+1  A: 

I completely disagree with Wisequark -- there's absolutely nothing wrong with putting a button in the tableHeaderView, and including one would not risk your app being rejected from the app store. The tableHeaderView is designed to be an arbitrary view containing whatever elements you choose.

As far as your issue, it could be that you've got a view obscuring your button, or, it may simply be a bug that should be reported to Apple.

August
+2  A: 

I had the same problem. In my case I had a container view instantiated in IB (that was applied as the table view header in code), with a UIImageView occupying the entire frame of that container. The misbehaving button resided in the image view.

Turns out I needed to have sizing struts in IB set as follows...

Container View: exterior anchors all on, interior resizing - all off

Sub Image View: all struts on (interior and exterior)

I had several different table views, all using header views. Some would respond to touch events correctly, some were flaky. This solved my problem

Danny Hall
+1. This worked for me. I'm not using IB for this, so I had to programmatically set the struts with `-setAutoresizingMask:`, and I found it only necessary on the container. The inner image control didn't need anything. Thanks! Would never have stumbled on this by accident.
quixoto