mbigatti / bmxswipablecell Goto Github PK

I've found another issue when using accessory views, while the current logic moves the accessory view using a transform this does not seem to move the underlying UIView and therefore touching the area where the accessory view was located triggers cell selection when the basement view is uncovered.

I have a custom cell prototype which consists on a UIView, 3 UILabels. On iOS 7, everything is working as expected but crashes on iOS 6.1.

*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: '{ Rows:
BMXSwipableCell:0x7c92330.Height == 128 + 1_0x7c9b520.marker
BMXSwipableCell:0x7c92330.Width == 640 + 1_0x7c9acc0.marker
BMXSwipableCell:0x7c92330.minX == 0 + 1_0x7c999b0.marker + -0.5_0x7c9acc0.marker
BMXSwipableCell:0x7c92330.minY == 0 + 1_0x7c9a890.marker + -0.5_0x7c9b520.marker
objective == <> + 750:-1_0x7c982c0.negError + 251:-1_0x7c982c0.posErrorMarker

Constraints:
<NSAutoresizingMaskLayoutConstraint:0x7c999b0 h=--- v=--- BMXSwipableCell:0x7c92330.midX == + 320> Marker:0x7c999b0.marker
<NSAutoresizingMaskLayoutConstraint:0x7c9a890 h=--- v=--- BMXSwipableCell:0x7c92330.midY == + 64> Marker:0x7c9a890.marker
<NSContentSizeLayoutConstraint:0x7c982c0 H:[UILabel:0x7c92830(48)] Hug:251 CompressionResistance:750> Marker:0x7c982c0.posErrorMarker
<NSLayoutConstraint:0x7c9acc0 H:[BMXSwipableCell:0x7c92330(640)]> Marker:0x7c9acc0.marker
<NSLayoutConstraint:0x7c9b520 V:[BMXSwipableCell:0x7c92330(128)]> Marker:0x7c9b520.marker
}: internal error. Cannot find an outgoing row head for incoming head 0x7c982c0.negError, which should never happen.'

By commenting out "[self bmx_moveContentViewSubViews]" in layoutSubviews method. Is now running fine in iOS 6.1 and 7.

This should make the project compile even if you don't have Reveal.app

Hi Guys,

I'm using BMXSwipableCell and using autolayout in it getting crash..Means when I add autolayout to controls and make BMXSwipableCell to its baseClass...App gets crashed.
This reason is :- +[NSLayoutConstraint constraintWithItem:attribute:relatedBy:toItem:attribute:multiplier:constant:]: Constraint must contain a first layout item'

(removed)

Environment

Use BMXSwipableCell with NSFetchedResultsController.

Steps to reproduce:

1. update ManagedObject, that is presented in Cell
2. when

 - (void)controller:(NSFetchedResultsController *)controller didChangeObject:(id)anObject
       atIndexPath:(NSIndexPath *)indexPath forChangeType:(NSFetchedResultsChangeType)type
      newIndexPath:(NSIndexPath *)newIndexPath 

getting called for event

NSFetchedResultsChangeUpdate

 - reloadRowsAtIndexPaths:withRowAnimation:

[NSTableView cellForRowAtIndexPath:]

Hi,

This looked really promising until I noticed it does not play well with Auto Layout. Because it moves the subviews out of the UITableViewCell's contentView and adds them as subviews to scrollViewContentView which causes the NSLayoutConstraints to be lost.

iOS will remove any constraints related to the view when it's removed from it's superview.

It would be nice if this library could detect all the existing constraints and add them back relative to the scrollViewContentView or alternatively try and incorporate the contentView within a UIScrollView and not the other way around as it is current doing it.

I have buttons in my cell but they aren't tappable. Any quick tips on how to use this library and keep my contentView buttons capable of being tapped?

ios 7 mail app correctly handles screen rotation

Thank you so much for this amazing library!

I'm trying to implement a button in scrollViewContentView. It's supposed to trigger an action that's different from tapping elsewhere on the cell. So far, it's not responding to taps whether or not userInteractionEnabled = YES.

Any ideas?

Current version reimplement significant logic to send messages the table view delegate to support highlight / selection. A better option it do let the original UIKit code do that. Investigate if it is possible to somehow forward touches from hosted UIScrollView to UITableViewCell to trigger original UIKit messaging implementation.

There's a line in your code where you do exact floating point equality testing. If, for example, the basementVisibleWidth is non-integer and non-power-of-two decimal, it will always fail and keep the basement closed.