Після оновлення до Xcode 6.1 beta 2, коли я запускаю додаток, що містить комірки табличного перегляду, помічник налагодження каже:

Warning once only: Detected a case where constraints ambiguously suggest a height of zero for a tableview cell's content view. We're considering the collapse unintentional and using standard height instead.

Раніше, коли я використовував Xcode 5 у цьому проекті, я отримав би кілька помилок, але вони пішли з моменту оновлення. Зараз у мене немає інших помилок чи попереджень. Я вже спробував коригувати розміри всіх комірок tableview, а також намагався використовувати стандартну висоту, але все одно отримую таке ж попередження:

Warning once only: Detected a case where constraints ambiguously suggest a height of zero for a tableview cell's content view. We're considering the collapse unintentional and using standard height instead.

Я також прочитав усі подібні теми з цього приводу, але жодне їхнє рішення не допомагає. Коли я тестую додаток за допомогою симулятора, додаток працює нормально, за винятком зображень, які, як передбачається, знаходяться в клітинах tableView.

Три речі встигли заглушити це попередження. Ви можете підібрати найбільш зручний для вас. Нічого гарного, хоча.

• Щоб встановити висоту комірки за замовчуванням у viewDidLoad

  self.tableView.rowHeight = 44;

• Перейдіть до таблиці та змініть висоту рядка на перегляді таблиці на щось інше ніж 44.

• Для реалізації методу делегата tableview висотаForForWowAtIndexPath

  - (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
  {
      return 44;
  }

Дивно.

Ви натрапляєте на побічний ефект фантастичної нової функції в табличних оглядах iOS8: Автоматична висота рядків.

У iOS 7 у вас були або рядки фіксованого розміру (встановлені з tableView.rowHeight), або ви писали код, щоб обчислити висоту своїх комірок, і ви повернете це вtableView:heightForRowAtIndexPath . Написання коду для обчислення висоти комірки може бути досить складним, якби у вашій комірці було багато переглядів і ви мали різну висоту, яку слід врахувати при різних розмірах шрифту. Додайте в Dynamic Type і процес був біль в попці.

В iOS 8 ви все ще можете зробити вищезазначене, але тепер висоту рядків можна визначити iOS за умови, що ви налаштували вміст своєї комірки за допомогою функції автоматичної компонування. Це величезна вигода для розробників, тому що, коли динамічний розмір шрифту змінюється або користувач змінює розмір тексту за допомогою Налаштувань доступності, ваш інтерфейс може бути адаптованим до нового розміру. Це також означає, що якщо у вас є UILabel, який може мати декілька рядків тексту, ваша клітинка тепер може зростати, щоб вмістити ті, коли потрібно клітинкам, і скорочуватися, коли цього немає, тому немає зайвого пробілу.

Попереджувальне повідомлення, яке ви бачите, говорить про те, що у вашій комірці недостатньо обмежень для автоматичної компонування, щоб повідомити табличний перегляд висоти комірки.

Щоб використовувати динамічну висоту комірки, яка, поряд із технікою, вже згаданою іншими плакатами, також позбавиться від цього повідомлення, вам потрібно забезпечити, щоб у вашій комірці було достатньо обмежень для прив’язки елементів інтерфейсу до верху та внизу комірки. Якщо ви раніше використовували автоматичний макет, ви, мабуть, звикли встановлювати обмеження Top + Leading, але динамічна висота рядка також вимагає обмеження внизу.

Пропуск макета працює таким чином, який відбувається безпосередньо перед відображенням комірки на екрані, точно вчасно:

1. Розміри для вмісту із властивими розмірами розраховуються. Сюди входять UILabels та UIImageViews, де їх розміри залежать відповідно від тексту або UIImages, які вони містять. Обидва ці представлення вважатимуть їх ширину відомою (тому що ви встановили обмеження для останнього / переднього краю, або ви встановили явні ширини, або ви використовували горизонтальні обмеження, які з часом виявляють ширину з боку в бік). Скажімо, на етикетці є абзац тексту ("кількість рядків" встановлено на 0, тому він автоматично обертається), він може становити лише 310 балів, тому він визначає висоту 120pt при поточному розмірі шрифту.

2. Користувальницький інтерфейс викладається відповідно до ваших обмежень щодо позиціонування. Внизу мітки є обмеження, яке з'єднується з нижньою полем комірки. Оскільки мітка зросла до 120 точок у висоту, і оскільки вона обмежена нижньою частиною комірки, вона повинна штовхати клітинку "вниз" (збільшуючи висоту комірки), щоб задовольнити обмеження, яке говорить "внизу мітка - це завжди стандартна відстань від нижньої частини комірки.

Повідомлення про помилку, про яке ви повідомляли, виникає, якщо цього нижнього обмеження відсутнє, і в цьому випадку нічого не можна «відштовхувати» від нижньої частини комірки від верхньої частини комірки, що є неоднозначністю, про яку повідомляється. зверху, клітина руйнується. Але автоматичний макет також виявляє це і повертається до використання стандартної висоти рядка.

Для чого варто, і головним чином, щоб отримати закруглену відповідь, якщо ви реалізуєте динамічні висоти рядків на основі автоматичного макета iOS 8, вам слід реалізувати tableView:estimatedHeightForRowAtIndexPath:. Цей метод оцінки може використовувати приблизні значення для ваших комірок, і він буде викликаний, коли початковий вигляд таблиці завантажений. Це допомагає UIKit намалювати такі речі, як смуга прокрутки, яку неможливо намалювати, якщо таблиця не знає, скільки вмісту він може прокручувати, але не потребує абсолютно точних розмірів, оскільки це просто смуга прокрутки. Це дозволяє відкласти обчислення фактичної висоти рядка до моменту, коли потрібна комірка, що є менш обчислювально обчислювальною та дозволяє швидше представити ваш UITableView.

У мене виникла ця проблема після створення користувальницького UITableViewCellта додавання моїх підвидів до комірки замість її contentView.

Щоб вирішити цю проблему без програмного методу, відрегулюйте висоту рядків подання таблиці в Інспекторі розмірів на аркуші розкладу.

Це проблема з автоматичним розкладом. Переконайтеся, що у ваших підзаглядах є всі обмеження. Для мене нижнє обмеження для клітинки заголовка в комірці відсутнє. Коли я додав це, попередження пройшло, і все вийшло чудово.

Просто увімкніть самостійне розмір комірок перегляду таблиці

   tableView.estimatedRowHeight = 85.0
   tableView.rowHeight = UITableViewAutomaticDimension

& переконайтеся, що ви додали обмеження з усіх боків UITableViewCellяк-

• Приклад посилання 1

• Приклад посилання 2

Якщо ви використовуєте статичну або динамічну комірку, просто додайте деяку висоту рядка до подання таблиці в таблиці інспектора і зніміть прапорці з автоматичної панелі у праву частину висоти рядка, і це перестане отримувати це попередження.

Я отримав це попередження сьогодні. Ось що змусило мене зникнути (у програмі для створення інтерфейсів)

1.Встановіть поле висоти рядка для подання таблиці на щось інше, ніж 44 2 Встановіть поле висоти рядка для комірки tableView на щось інше, ніж 44

Я не повинен був вносити будь-які зміни в код

У моєму випадку я будував клітинку програмно і продовжував отримувати цю помилку.

Я додавання підвидів і обмежень в UITableViewCell«S initметод , як це:

addSubview(rankingLabel)
addConstraints(cellConstraints)

Я вирішив проблему, додавши їх contentViewзамість комірки :

contentView.addSubview(rankingLabel)
contentView.addConstraints(cellConstraints)

Встановіть орієнтовну висоту рядка на нуль, і попередження зникне:

Я надто переживав це попередження з переходом на Xcode 6 GM. Я отримував попередження лише тоді, коли повернув пристрій у вихідне положення.

Я використовую власні UITableViewCells. Вид таблиці таблиці розміщений на мій нестандартний розмір (у моєму випадку 100,0). Хоча комірки таблиці візуалізуються належним чином, як у попередніх випусках, мені не сподобалось попереджувальне повідомлення.

Крім перерахованих вище ідей, я додав це

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 100.0;
}

Екран відображає ... реагує на обертання та більше не попереджає повідомлення.

У xcode 6.0.1 я видалив це попередження із зазначенням висоти рядка, використовуючи:

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath {
    return 44.0;
}

Якщо ви створили користувальницький tableViewCell для tableView, переконайтеся, що ви надали як нижній, так і верхній обмеження для ваших комірок, ви також можете отримати це повідомлення, якщо ваші підпогляди всередині спеціальних комірок вирівняні в центрі Y, що не буде виводити жодне повідомлення про помилку, але буде заплутано вгору з визначенням висоти рядка для перегляду столу, по черзі, як на зображенні, яке я додав, тут ми маємо і верхнє, і нижнє обмеження

Під час створення користувацької комірки для tableView потрібно вказати висоту рядка або обмеження верхніх і нижніх підрядів під власні підгляди клітинки всередині комірки (наприклад, мітка у спеціальній комірці, як на зображенні нижче)

Але якщо це не працює, ви можете спробувати встановити висоту рядка для вашої клітини, а не бути автоматичною, як на цьому зображенні

Але будьте впевнені, якщо ви вимкнете цю автоматичну галочку, вам доведеться налаштувати розмір рядка для змін, які програмно могли бути виконані автоматично

У дошці розкадровки встановіть cell Row heightполе з тим же значенням, що і Row heightв tableView(обидва з тим самим значенням працювали для мене).

Якщо ви додасте heightForRowAtIndexPathфункцію до свого коду, це може спричинити проблеми з продуктивністю, оскільки вона буде викликана для кожної комірки, тому будьте уважні.

Ви також можете побачити це повідомлення, якщо встановлені ваші єдині обмеження для вирівнювання всіх елементів по вертикалі і у вас немає / хочете висоти, вказаної для комірки. Якщо встановити верхнє / нижнє обмеження для елемента, попередження зникне.

У мене виникла ця проблема, коли мої мітки та представлення у користувальницькій таблиціViewCell обмежувались customCell, а не його Перегляд вмісту. Коли я очистив обмеження і з'єднав їх з оглядами вмісту, проблема була вирішена.

У мене було те саме повідомлення про помилку, переконайтеся, що всі ваші торгові точки справжні, як перегляд таблиці та обмеження перегляду таблиці

Якщо ви робите динамічний розрахунок висоти,

• у вас повинні бути пов’язані між собою всі елементи з точки зору обмежень, таких як верх і низ.
• Ви обов'язково повинні мати обмеження на дні, яке пов'язане з елементом у нижній частині клітинки

У мене є також аналогічна проблема для користувацької комірки tableview, яка має динамічну висоту рядка. Динамічна висота не відображалася і отримала таке ж попередження в консолі. Рішення полягає в додаванні підвидів до комірки замість contentView. До речі, я створив підзагляди програмно.

У мене ця проблема в TableViewCells, де обмеження встановлюються при ініціалізації, але де вміст комірки завантажується після цього, це означає, що двигун авторозмикання не може визначити висоту. Інші рішення тут не працюють, тому що мені потрібна висота коміркиUITableView.automaticDimension .

Я щойно додав додаткову обмеження для клітини:

contentView.heightAnchor.constraint(equalToConstant: 44, priority: .defaultLow)

Сьогодні я отримав це попередження. Все, що я зробив, - це лише додати один додатковий рядок до мого коду

tableView.rowHeight = 200;

додайте цей рядок коду всередині

func tableView(_ tableView: UITableView, numberOfRowsInSection section:Int) -> Int {
  ...
}

і виглядає кінцевий код

func tableView(_ tableView: UITableView, numberOfRowsInSection section: Int) -> Int {
  tableView.rowHeight = 200;
  ...
}

цей код збільшить висоту комірки рядка таблиці до 200, висота за замовчуванням - 44

У мене така ж помилка, через цей рядок ця помилка була показана.

self.layer.backgroundColor = UIColor (білий: 1, альфа: 0,2) як! CGColor

Я просто змінюю рядок таким чином, щоб виправити помилку

self.layer.backgroundColor = UIColor (білий: 1, альфа: 0,2) .cgColor