UITableViewCell, находящийся в очереди, имеет неправильный макет до прокрутки (с использованием автоматического размещения)

У меня есть обычайUITableViewCell подкласс, к которому были применены ограничения на автоматическое расположение в Интерфейсном Разработчике. Ячейка содержит несколько представлений, включая.UITextField

Соответственно, размерUITextField ограничен таким образом, что между ним и следующим видом по умолчанию установлен горизонтальный интервал.

Ячейка создается следующим образом:

- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
{
    static NSString *CellIdentifier = @"ProgressCell";
    ProgressCell *cell = [tableView dequeueReusableCellWithIdentifier:CellIdentifier
                                                     forIndexPath:indexPath]

    cell.textField.text = @"Some string that is different for each cell";

    return cell;
}

Когда ячейка появляется впервые,UITextField переходит правильный кадр и появляется заUIView вправо. Однако, когда я прокручиваю ячейку за пределами экрана, пауза, а затем прокручиваю назад, текст усекается правильно.

Пример показан ниже (при втором редактировании).

Я пробовал звонить[cell setNeedsLayout] а также[cell setNeedsDisplay] для клетки вcellForRowAtIndexPath, а также выполнение их после задержки. Ни один не эффективен.

Что делает прокрутка за пределами экрана, что приводит к правильному отображению ячейки, и как я могу либо повторить это, либо исправить основную проблему?

РЕДАКТИРОВАТЬ:

призвание

[self.tableView reloadData];
[self.tableView reloadSections:[NSIndexSet indexSetWithIndex:0] withRowAnimation:UITableViewRowAnimationAutomatic];

для того, чтобы перезагрузить ячейку, кажется, чтобы макет отображался правильно в первый раз.

Однако сейчасбрейки (иногда) при прокрутке (т. е. при обратной прокрутке ограничения макета теперь не применяются правильно).

призвание[cell setNeedsLayout] вcellForRowAtIndexPath Похоже, не решить эту проблему.

EDIT2:

Верхняя ячейка, как показаноВот, отображается правильно (как и нижняя ячейка), пока я не прокрутил экран вниз. Это с тех пор исчезло.

Это отражает проблему с первого редактирования - этовторой рендеринг, который является проблемой (заставляет меня думать, что это может иметь какое-то отношение к повторному использованию ячейки?)

 rdelmar21 февр. 2013 г., 16:34
Я неЯ не вижу ничего плохого в этих ограничениях. Я пытался продублировать вашу проблему, но мой обрезал длинный текст без прокрутки. Если вы сделаете ограничение ширины = вместо>= это помогает? Вы можете просто удалить это (это будет зависеть от того, что у вас есть для двух других объектов справа)?
 jrturton21 февр. 2013 г., 09:08
@ rdelmar Я записал свою категорию Autolayout (разве мы не обсуждали это раньше?), если вы 'заинтересован:commandshift.co.uk/blog/2013/02/20/...I»
 sapi21 февр. 2013 г., 11:24
Мы загрузили пример изображения здесь:imgur.com/a/IKv0Z, Нет предупреждений об ограничениях в консоли @rdelmar - и ониВсе настроено через IB, поэтому они должны быть действительными.
 jrturton21 февр. 2013 г., 09:06
Можете ли вы включить несколько скриншотов?
 rdelmar21 февр. 2013 г., 08:20
Вы получаете какие-либо предупреждения об ограничениях в консоли?
 sapi22 февр. 2013 г., 00:33
мы пытались сделать ширину равной, удалив ограничение и даже полностью игнорируя автопоставку и установив маски авторазмера. Ни одна из этих идей не устранила проблему: / Даже с фиксированной шириной, если я установил textLabel 's цвет фона, я вижу, что он занимает всю клетку.

Ответы на вопрос(2)

Решение Вопроса

UITableViewCell подклассtextLabel или жеdefaultTextLabel, тогда IB проигнорирует указанные вами ограничения и переопределит их по умолчанию без предупреждений.

Это касается даже ячеек, разработанных в IB с пользовательским стилем, которые не видныtextLabel или жеdetailTextLabel свойства.

Это также произойдет, если добавить свойство типаUIImageView недвижимость наUITableViewCell подкласс и назовите его.imageView

 atreat16 нояб. 2013 г., 10:01
Этот ответ нужно добавить в ссылку на класс UITableViewCell, я просто потратил 4 часа своей жизни. его 4 утра ...
 RickiG28 авг. 2013 г., 10:46
То же самое касается "ImageView» собственность также.
 race_carr14 мая 2014 г., 20:30
Я хотел бы, чтобы Интерфейсный Разработчик или компилятор предупредили вас о непреднамеренном переопределении этих имен свойств.
 Ville Laurikari22 апр. 2014 г., 14:38
Огромное спасибо. Вы только что спасли мне несколько часов моей жизни.
 NathanVss27 дек. 2016 г., 04:09
Почему .. просто почему. "ImageView» к. Никаких предупреждений, Xcode тихо, как ад ..
 Dylan Moore22 мар. 2015 г., 15:36
То же самое касается свойств UIImageView с именем "maskView» также.

несколько строкUILabel Выпуск GitHubэто давняя ошибка iOS.

Я обнаружил, что в iOS 9+ эта ситуация в основном возникает в режиме редактирования, с большой непредсказуемостью.

Следующий обходной путь работает только частично: он требует перерисовкиUITableView дважды, и до сих пор не охватывает все сценарии.

override func viewDidLoad() {
    super.viewDidLoad()

    tableView.setNeedsLayout()
    tableView.layoutIfNeeded()
    tableView.reloadData()
}

Заметки:

С помощьюUITextView отличная альтернатива многострочномуUILabelбез ошибки.UITextView не демонстрирует ни одного изIULabel другие странности, как, например,ошибки выравнивания или жемерцает.Существует также альтернативное решениеSO-25947146, который не работал для меня, но стоит упомянуть.Кажется, происходит заметно, когдаself.tableView.editing являетсяtrueИспользуя низкие значения дляtableView.estimatedRowHeight уменьшает возникновениеДемонстрация ошибки наSwiftArchitect / TableViewControllerRowHeightBug суть

Ваш ответ на вопрос