Блог

Ведение более старого проекта с использованием c Builder 2009

В TListView экземпляре ( ViewStyle = vsReport ) настройка для работы с виртуальным ( OwnerData = true ) Я хотел попытаться как можно больше увеличить скорость. Каждая крошечная частичка помогает. В OnData случае, если я заметил, что Item->SubItems->Capacity для начала = 0, и оно увеличивается на 4 по мере добавления подпунктов. Я читаю в документах, которые Capacity доступны только для чтения, но я хочу TStrings как можно больше избегать внутреннего перераспределения. Поскольку мне также нужно выполнить кэширование, я решил использовать TStringList кэш as, который уже вырос до необходимой емкости. Я предполагаю TStrings Assign() , что затем сразу же выделит массив, достаточно большой для хранения необходимого количества строк ?

 Item->SubItems->Assign(Cache.SubItems) ;
 

Пока это работает, я заметил, что это заставляет ListView снова и снова вызывать onData и … заставлять его никогда не останавливаться.

Легко исправить это снова, сделав это:

 for (int x = 0 ; x < Cache.SubItems->Count ; x  )
    Item->SubItems->Add(Cache.SubItems->Strings[x]) ;
 

Но, конечно, весь смысл состоял в том, чтобы с SubItems самого начала определить количество строк.

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

Есть ли способ «разрешить» Capacity принимать входные данные ? Чтобы он выделял достаточно места для строк, которые будут добавлены ?

TListView::OnData Событие запускается всякий раз, когда ListView требуются данные для данного элемента списка, например (но не ограничиваясь) операциями рисования.

Обратите внимание, что когда OnData событие запускается, TListItem::SubItems оно уже было Clear() отредактировано заранее. TStringList::Clear() устанавливает значение Capacity 0, освобождая его текущий string массив. Вот почему Count и Capacity всегда равны 0 при вводе вашего OnData обработчика.

SubItems Свойство реализовано как TSubItems объект, который является производным от TStringList . Задатчик TStrings::Capacity свойств реализован в TStringList и выполняет то , что вы ожидаете, для предварительного выделения string массива. Но это все, что он делает — выделяет память VCL для массива, не более того. Все еще существует аспект обновления самих элементов ListView на уровне Win32 API, и это необходимо делать индивидуально по string мере добавления каждого из них в SubItems .

Когда ваш OnData обработчик вызывает SubItems->Assign() , вы вызываете TStrings::Assign() (как TStringList и TSubItems не переопределяйте его). Тем не менее, ПРЕДВАРИТЕЛЬНО TStrings::Assign() не распределяет string массив по размеру исходного TStrings объекта, как можно было бы ожидать (по крайней мере, не в CB2009, я не знаю, делают ли это современные версии или нет). Внутренне, Assign() просто вызывает Clear() , а затем TStrings::AddStrings() (что TStringList ни TSubItems в коем случае не переопределяет предварительное выделение массива). AddStrings() просто вызывает TStrings::AddObject() в цикле (который и TStringList то, и TSubItems другое переопределяет).

Вся эта логика очистки и добавления заключена в паре TStrings::(Begin|End)Update() вызовов. Это важно отметить, потому TSubItems что реагирует на счетчик обновлений. Когда счетчик падает до 0, TSubItems запускается TListView для выполнения некоторых внутренних обновлений, включая вызов Invalidate() самого себя, который запускает полную перерисовку и, таким образом, запускает новую серию OnData событий для элементов списка, которые нуждаются в повторной прорисовке.

С другой стороны, когда вы вызываете SubItems->Add() свой собственный ручной цикл и пропускаете (Begin|End)Update() вызовы, вы пропускаете перерисовку всего списка. TSubItems переопределяет TStrings::Add/Object() (среди прочего) обновление только определенного элемента ListView, с которым он связан. Он не перекрашивает весь вид списка.

Таким образом, вы должны быть в состоянии установить Capacity перед входом в ручной цикл, если вы действительно хотите:

 Item->SubItems->Capacity = Cache.SubItems->Count;
for (int x = 0; x < Cache.SubItems->Count;   x)
    Item->SubItems->Add(Cache.SubItems->Strings[x]);
 

В этом случае вы можете использовать AddStrings() вместо ручного цикла:

 Item->SubItems->Capacity = Cache.SubItems->Count;
Item->SubItems->AddStrings(Cache.SubItems);