3

I have a rather large table header view above my table view. I have a number of subviews in that header view. I am doing something a bit nonstandard where I am "sticking" some of those subviews (but not all) at the top of the table view.

My problem is that although visually the table view cells pass under the sticky table header subviews, it seems that the table view cells are "above" the table header view in terms of touch response. (For example: I have a button that is a subview of the table header view. When there are no cells underneath the button, the button works great and responds to touches. However, when the user scrolls the table view so that there are cells underneath the button, a touch on the button actually selects a hidden cell rather than push the button.) Can anyone give advice on how to "raise" the table header view above the table view cells, so that its subviews get first shot at touch handling?

I am using a table header view rather than a section header view due to the fact that I only want some of the subviews to stick (letting the others scroll up off the screen as usual). One of the subviews also can be expanded (and that expansion is animated) - to a height that is even bigger than the entire height of the screen. For these reasons, I didn't think using a section header view would be feasible. (If it is, please let me know, as I know that section header views are "above" table cells when it comes to touch response.)

danbretl
  • 624
  • 6
  • 14

1 Answers1

0

You may try this, which would keep the desired header view on top of the others.

[yourView bringSubviewToFront:yourSubView];

This may be able to help as well: http://www.iphonedevsdk.com/forum/iphone-sdk-development/5222-keeping-subview-front.html

Is this what you were looking for or did you want another approach?

Kinetic Stack
  • 759
  • 12
  • 30
  • The problem is not visual. Does bringSubviewToFront affect the responder chain as well? I'll try and get back to you. – danbretl Dec 23 '11 at 21:51
  • Yes, it should cause it to be the primary responder. – Kinetic Stack Dec 23 '11 at 21:55
  • On which view would you call the method, and which view would you tell it to bring to front? Would you tell the table view to bring the header view to front? Or tell the header view to bring the (e.g.) button subview to front? So far, I'm not having luck. – danbretl Dec 23 '11 at 21:59
  • You would need to call it whenever you suspect that the other view is being overridden. You would call the header view to the front (which if I understand correctly would bring the buttons). Another option is that if the user cannot select the cells anyway, simply turn off user interaction with them, then the button will be the one to receive the action. – Kinetic Stack Dec 23 '11 at 22:04
  • I tried (brute force) in scrollViewDidScroll telling the table view to bring the header view to the front. That had no effect. – danbretl Dec 23 '11 at 22:06
  • In that case try turning user interaction for the cells off if that works for what you are trying to do. – Kinetic Stack Dec 23 '11 at 22:07
  • I can't simply turn off user interaction with the cells because a cell could be only partially obscured by a header view subview (that should have first dibs on user interaction) - the part of the table view cell that is still visible in that instance should still be able to receive a touch. – danbretl Dec 23 '11 at 22:08
  • In that case I'm not sure :/ There is a way to hide it though I'm sure. I bumped the question up :) – Kinetic Stack Dec 23 '11 at 22:15
  • Thanks for your time. I'm not sure you're totally understanding my problem though. Visually, everything is perfect - the table header view's sticky subviews stay on the top layer, and the cells slide underneath. The problem is only in terms of touch response. So, the problem is not really in needing to "hide" anything. It's just to get the order of touch response to fall in line with the visual appearance of things (as is normally the case)! – danbretl Dec 23 '11 at 22:17