(1) В вашем стиле списка, метка NameLabel с текстом использует резиновую разметку и растягивается по размеру контейнера CardPanel. Аналогично касается CardPanel, которая растягивается по размеру стиля. Корневой div - это CollectionView_Style1

<div layout="width: 167; height: 33; top: 25; left: 0;" style="align-content: stretch; width: 167px; height: 33px; position: absolute; left: 0px; top: 25px; " >
  <!-- CardPanel-->
  <div layout="width: 157; height: 27; top: 5; left: 5;" style="flex-direction: row; align-content: stretch; flex-grow: 1; margin-left: 5px; margin-top: 5px; margin-right: 5px; " >
    <!-- NameLabel -->
    <div layout="width: 144; height: 27; top: 0; left: 10;" style="flex-grow: 1; margin-left: 10px; margin-right: 3px; " ></div>
  </div>
  <div layout="width: 157; height: 1; top: 32; left: 5;" style="margin-left: 5px; margin-right: 5px; height: 1px; " ></div>
</div>

Затем в событии OnShow вы принудительно пытаетесь указать новый размер тексту и метке, размер которых расчитывается автоматически FlexBox! Получается, что вы пытаетесь задать размер для компонентов, размер которых расчитывается автоматически.

(2) После расчета размера, компоненты принимают дробный размер. В вашем случае у стиля получается высота равная 37.4285736 dp. Android использует физические пиксели px для финальных размеров компонентов, вьюшке и т.д. Поэтому после конвертации с учетом дробного коэффициента масштабирования естественно происходит округление с потерей точности. В результате вьюшка принимает размер в 67px, что соответствует уже 38dp.

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

На эмуляторе с android 9.0 всё считается отлично. На реальных телефонах считает высоту меньше. Причем на разных телефонах по разному. Где-то на пару пикселей, а где-то больше.

Это связано с тем, что в эмуляторе используется коэффициент масштабирования 1, поэтому 1 dp = 1 px. А на реальных устройствах это не так.

Решение - это перейти от накопительной погрешности к единовременной. Нужно вычислять размер стиля в px и именно его использовать при вычислении высоты всего списка.

uses
  FGX.Screen;

FStyleSizeInPx: Integer;
// Расчет высоты стиля в px
FStyleSizeInPx := Ceil(CollectionView_Style1.Height * TfgScreenManager.Main.Scale);
// Расчет высоты списка 
CollectionView.Height := (FStyleSizeInPx * CollectionView.Count / TfgScreenManager.Main.Scale);

Задача у меня в том, что в разных вариациях приложения используются разные шрифты. Шрифт выбирает заказчик. А мне нужна минимальная высота данной конструкции для текущего шрифта. Поэтому там и стоит расчёт высоты.

В 28.08.2025 в 00:31, Yaroslav Brovin сказал:

Решение - это перейти от накопительной погрешности к единовременной. Нужно вычислять размер стиля в px и именно его использовать при вычислении высоты всего списка.

Этот метод помог. Спасибо.

Но почему этот же самый код на обычной форме работает без всяких проблем. Ничего не обрезается. Условия и устройства те же?!

Так я до сих пор и не понимаю зачем там эти коэффициенты и дробные значения. Все устройства имеют конкретное физическое разрешение и физические пиксели. Зачем их делить - непонятно.

В 28.08.2025 в 00:31, Yaroslav Brovin сказал:

Решение - это перейти от накопительной погрешности к единовременной. Нужно вычислять размер стиля в px и именно его использовать при вычислении высоты всего списка.

Что то я поторопился с выводами. Данное решение ничего не дало. Как обрезалось так и обрезается.

А вот тот же самый код на обычной форме в тех же условиях работает без проблем!

Project30.zip Project29.zip

39 minutes ago, Mineev said:

Что то я поторопился с выводами. Данное решение ничего не дало. Как обрезалось так и обрезается.

На сколько обрезается?

Видимо зависит от количества элементов. Даже один элемент обрезается на пиксель. А несколько обрезаются довольно много.

48 minutes ago, Mineev said:

А вот тот же самый код на обычной форме в тех же условиях работает без проблем!

Сегодня вечером посмотрю.

В прикрепленных проектах неправильно используется конвертация PX <- -> DP

1 PX = 1 DP * Scale
1 DP = 1 PX / Scale

56 minutes ago, Mineev said:

А вот тот же самый код на обычной форме в тех же условиях работает без проблем!

Нет разницы, на главной форме это или на фрейме. Точно так же я вижу проблему.

Вот мой файл фрейма. Проверяйте на нем.

Screen.Test.xfmScreen.Test.pas

В вашей формуле есть недостаток. Мне нужно чтобы нижняя граница CollectionView была по нижней границе нижнего элемента. Это важно. Я специально подсветил желтым чтобы видно было. Иначе можно было бы просто добавить лишний пиксель (или пару) к каждому элементу. А у вас после расчёта места снизу полно остается лишнего.

Прикрепите, пожалуйста, видеозапись с экрана, где это видно.

Вот

Это видео с моим файлом фрейма?

На всякий случай скриншот с моим фреймом. На нем видно, что нижняя граница отображена красным цветом:

Как я уже писал выше, такое выравнивание меня не устраивает. Всё это затевалось для выравнивания нижней границы.

И если взять ваш фрэйм и сделать пару изменений: хранить неокругленную высоту и высчитывать высоту CollectionView точно, то получается как на моём видео.

С целым коэффициентом всё работает, а с дробным нет.

Project29.zip

Edited September 3, 2025Sep 3 by Mineev

Это не может быть связано со шрифтами? Чисто теоретически не должно, но FGX-454 говорит, что всё может быть.

Я вам задал вопрос на который вы так и не ответили:

21 hours ago, Yaroslav Brovin said:

Это видео с моим файлом фрейма?

В итоге вы прикрепляете свой проект, в котором используете СВОЙ код, а не мой. Он, естественно, не работает. В чем логика? Я, видимо, чего-то не помнимаю.

Это ваш фрэйм с небольшими изменениями, о которых я писал

7 часов назад, Mineev сказал:

И если взять ваш фрэйм и сделать пару изменений: хранить неокругленную высоту и высчитывать высоту CollectionView точно, то получается как на моём видео.

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

Вы вносите изменения, которые МЕНЯЮТ логику вычислений.

Just now, Mineev said:

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

Непонимая логики работы, принимаете лично решение, что код должен работать по вашему. Затем, не отвечая на мои вопросы, продолжаете написывать, что код работает не так. Если вы хотите помощи, то нужно отвечать и делать то, что просят.

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

Для начала, нужно сделать то, о чем я вас попросил.

21 hours ago, Yaroslav Brovin said:

Это видео с моим файлом фрейма?

Вот результат работы вашего фрэйма. Изменил только цвета.

Я пока в процессе поиска решения. Копгнул глубже, тут оказалось несколько сложностей, которые мешают дать решение: У RecyclerView элементы по неизвестной для меня причине меняют немного свою высоту в процессе работы. И варируются от 38 до 38.7. Причем это изменение высоты происходит не сразу, а чуть позже. Поэтому расчитать высоту сразу не получается. Только если отдельно вызывать метод перерасчета, тогда все становится, как нужно. В текущем варианте я пробегался по всем элементам списка и складывал их реальную высоту, таким образом получается реальная высота списка.