Здравствуйте, уважаемые коллеги!
У меня проблема с TListView (режим vsReport). Мне нужно добавить в

него большое количество Item'ов (порядка 80 тысяч). В Item'е 4

Subitem. Делаю примерно так:
var
 i: integer;
 li: TListItem;
begin
 for i := 0 to 80000 do
   begin
     li := ListView1.Items.Add();
     li.Caption := str1;
     li.SubItems.Add(str2);
     li.SubItems.Add(str3);
     li.SubItems.Add(str4);
   end;
end;
Беда в том, что на машине средней паршивости этот код выполняется

примерно за 15..20 минут, что не допустимо. Проблема именно в

заполнении ListView - все остальное работает быстро. Есть ли

какой-нибудь способ поднять производительность?

Внимание! Здесь обсуждаются вопросы, связанные с разработкой компонентов, редакторов свойств, редакторов компонентов и экспертов IDE.
Вопросы по поиску и использованию готовых компонентов, редакторов или экспертов являются нарушением тематики и могут быть удалены.

А пользователю что вешаться из-за таких объемов, он же тормозить не умеет.

Пускай пользователь вчитывается, вдруг в 73652 элементе найдёт ошибку

VirtualTree посмотрите

> Есть ли какой-нибудь способ поднять производительность?

для начала элементарно обернуть код в Items.BeginUpdate / EndUpdate.
но над [2] и [3] стоит задуматься.

> для начала элементарно обернуть код в Items.BeginUpdate
> / EndUpdate

Этот фокус, к сожалению, не работает

Нашел отличную статью по этой проблеме: http://www.delphi.int.ru/articles/38/
Суть в том, что при работе с большими объемами инфы нужно устанавливать ListView.OwnerData в true, затем присвоить ListView.Count сколько нужно (в моем случае 80000) и создать обработчик события OnData, в котором будет заполняться каждый конкретный Item (с Subitem'ами). Событие OnData возникает только тогда, когда нужно вывести соответствующий Item в видимую область ListView. Естественно, что при большом количестве Item'ов скорость увеличивается на порядки.
Всем большое спасибо! :-)))

> Всем большое спасибо! :-)))
>


Завсегда рады помочь. Обращайтесь

> большое количество Item'ов (порядка 80 тысяч).

Ни один нормальный пользователь не сможет прочитать 80 тысяч элементов.

> Ни один нормальный пользователь не сможет прочитать 80 тысяч элементов.

- в сортированном списке - найти коллизии и проследить динамику по "ASCII-узору" - легко...

На самом деле все банальней - некоторым пользователям - проще выдать все, чем каждый раз объяснять, что он "не сможет прочитать 80 тысяч элементов", поэтому включена фильтрация по умолчанию - и что события за предыдущий квартал не потеряны, а просто нужно настроить фильтр...