taps, touchBegan doesn't work anymore
plandem opened this issue · comments
when i replaced my custom header with flexible, then any taps is not received anymore. I track my taps for custom logic and now it's not catching anymore. Any ideas how to fix?
Based on the little info I know about your setup, I can only recommend seeing why/where the touches are getting absorbed. Maybe userInteractionEnabled is equal to YES on the flexible height bar and you want them to be passed through to the table view or view controller's view? Looking at that property would be a good start.
well, that's another screen, but not matter, when i set:
self.tableView.delegate = (id<UITableViewDelegate>)self.headerView.behaviorDefiner;
any taps inside of table is not working anymore. If set at header's userInteractionEnabled to NO/YES - nothing changed (at least for taps inside of table).
Where have you overridden touchesBegan:?
for my custom tableViewCell. also for one subview of header.
And if you place a breakpoint in touchesBegan:, it never gets hit? You're sure that it gets hit if you comment out self.tableView.delegate = (id<UITableViewDelegate>)self.headerView.behaviorDefiner;?
sure, i already tried it. when comment this delegate setup - everything is working like before!
This problem isn't specific to BLKFlexibleHeightBar - if you set the delegate property of your UITableView, then this is the expected behavior.
ok, but how to use your bar if it requires delegate to be replaced? for me it sounds like bar's specific.
-
that delegate has nothing about touches, that table's delegate must implement some methods and non of them about touches
-
if your bar require to change common workflow for something and after that common behaviour will break - than, i'm sure it's bar specific.
Any issue when component that trying to add some new functionality, also remove common functionality - specific to that component. Just my thoughts.
But if you still think, that it's ok - your choice, that's your component. But at least, please, update and inform potential users, that their common behaviour will break - in that people will decide before integrating - spend or not time for integration and what kind of problems they will have.
As for me - right now my tableViewCell can't catch touches (and catching touches - common behavior by default), the only reason - using your bar. My solution? i will try to replace your bar with something other, because it's not acceptable - one new nice visual feature vs few already implemented and tested other features. I'm not sure that i will not have any other surprises in future.
This doesn't appear to be the case actually. Setting the delegate doesn't cause a change in touch behavior. That being said, I can't reproduce this issue.
Can you double check userInteractionEnabled and make sure that it's YES for your table view cell?
i will try to figure out, maybe i'm wrong and problem at something other. i will let you know.
Did you get a chance to try BLKDelegateSplitter?
hmmm....of course nope, because there is no any information about it at readme. So as i see, same final destination. Of course if i would try i would not do own implementation, but now - what the reason for another class? why not just use 1 additional property only?
Yeah that definitely should be in the README, shouldn't it! I'll update that =)
I kept it as a separate class for the sake of making the separation of responsibilities a bit clearer. In practice is probably doesn't make much difference.
ok, but than it's better to 'patch' you splitter to support 'conformsToProtocol', because in some cases it can be used too (Apple doesn't check, but at some logic of UIViewController it can be easily)
That's a good idea. I'll add that in soon. I totally agree that it would be useful to check the delegate splitter for protocol conformance. Thanks for pointing this out!