Анти SelectAll...Существует что-нибудь подобное?

← →
Tcount © (2012-11-22 23:49) [0]

У меня появился вроде простой вопрос...
Например, у ListView"a есть метод SelecAll. А есть что-то подобное, делающее обратное? Может в WinApi есть? Просто не знаю, в какую сторону копать)

← →
Германн © (2012-11-23 00:16) [1]

> А есть что-то подобное, делающее обратное?

ClearSelection не подойдет?

← →
DVM © (2012-11-23 00:17) [2]

> А есть что-то подобное, делающее обратное?

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

← →
Tcount © (2012-11-23 00:22) [3]

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

Я бы с радостью, но строк довольно много)

← →
Tcount © (2012-11-23 00:24) [4]

> ClearSelection не подойдет?

СПАСИБО! То, что доктор прописал) Чот я не обратил внимание на методы, начинающиеся с "Clear") Не всегда хорошие ассоциации с этим словом)

← →
Германн © (2012-11-23 02:01) [5]

> Я бы с радостью, но строк довольно много)
>

> СПАСИБО! То, что доктор прописал

Там тот же самый цикл по тем же Items и их Subitems.

← →
Tcount © (2012-11-23 02:11) [6]

> Там тот же самый цикл по тем же Items и их Subitems.

Разве не с помощью WinApi?

← →
Tcount © (2012-11-23 02:22) [7]

Не нашел я модуля этого, хотелось бы взглянуть на алгоритм ClearSelection...
Если в нем пробегается конкретно по всем строкам, то для моего случая можно было бы в некоторых случаях сделать быстрее: например, сначала записать кол-во выделенных элементов (SelCount), сделать ту же пробежку, только при каждом обнаружении выделения уменьшать эту переменную, пока она не станет равной нулю, тогда и прервать пробежку.

← →
Tcount © (2012-11-23 02:23) [8]

Или ничего вообще не записывать, постоянно проверяя SelCount. Хотя не думаю, что так будет быстрее)

← →
Германн © (2012-11-23 02:47) [9]

> Tcount © (23.11.12 02:11) [6]
>
>
> > Там тот же самый цикл по тем же Items и их Subitems.
>
>
> Разве не с помощью WinApi?
>

А разве WinApi - это некая "волшебная палочка"?

← →
DVM © (2012-11-23 10:17) [10]

> Tcount © (23.11.12 00:22) [3]
>
> > пройти по всем элементам и развыделить сложно что ли?
>
> Я бы с радостью, но строк довольно много)

Сто тысяч миллиардов? У тебя там наверняка не более 50 000 строк, даже при значительно меньшем количестве даже в виртуальном режиме использовать обычный ListView проблематично. Цикл от 0 до 50 000 выполняется на современном компьютере за ничтожно малое время.

← →
Dimka Maslov © (2012-11-23 10:20) [11]

> Цикл от 0 до 50 000 выполняется на современном компьютере
> за ничтожно малое время

Только если не забыть сделать BeginUpdate и EndUpdate...

← →
han_malign (2012-11-23 10:43) [12]

> не более 50 000 строк, даже при значительно меньшем количестве
> даже в виртуальном режиме использовать обычный ListView
> проблематично.

- да ничего, несколько сотен тысяч вполне тянет - главное по невидимым ListItem не бегать, а статусы в элементах "внешнего" контейнера кешировать...

> > Разве не с помощью WinApi?
...
> А разве WinApi - это некая "волшебная палочка"?

- как бээ..., зачастую - да:
ListView_SetItemState(lv.Handle, -1, 0 , LVIS_FOCUSED or LVIS_SELECTED); // LVM_SETITEMSTATE

← →
DVM © (2012-11-23 10:47) [13]

> han_malign (23.11.12 10:43) [12]

> - как бээ..., зачастую - да:
> ListView_SetItemState(lv.Handle, -1, 0 , LVIS_FOCUSED or
> LVIS_SELECTED); // LVM_SETITEMSTATE

Ну а внутри этого макроса разве нет цикла?

← →
DVM © (2012-11-23 10:51) [14]

> han_malign (23.11.12 10:43) [12]

> главное по невидимым ListItem не бегать, а статусы в элементах
> "внешнего" контейнера кешировать...

Ну так это и есть виртуальный режим. В виртуальном режиме не запрашиваются данные невидимых элементов и бегать по ним и не нужно. Данные тоже хранятся в обычном списке. Я не знаю как устроен внутри ListView но в виртуальном режиме он намного хуже, чем, например, TVirtualTreeView. Даже прокрутка у него хуже работает (отстает от мыши что ли, как то заторможенно все). И памяти жрет больше.

← →
han_malign (2012-11-23 11:41) [15]

> несколько сотен тысяч вполне тянет

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

Ну и конечно epic fail на
procedure TListItems.Clear; begin if Owner.HandleAllocated then ListView_DeleteAllItems(Handle); end;
- с OnData(+ TCustomListView.Delete(){ OnDeletion }) - на каждый элемент...
Только и исключительно:
procedure TListItems.SetCount(Value: Integer); begin ListView_SetItemCountEx(Handle, Value, LVSICF_NOINVALIDATEALL); end;
:= 0; - с очисткой ассоциированных данных во внешнем контейнере(что вполне логично)...

З.Ы. А "оптимизация":
lv.OwnerData:= false; lv.Items.Clear;
- это вообще армагедецЪ...

← →
han_malign (2012-11-23 12:55) [16]

> Даже прокрутка у него хуже работает (отстает от мыши что
> ли, как то заторможенно все). И памяти жрет больше.

- а это реализация обработки LVN_GETDISPINFO { OnData }, где набивается список Subitems в OnData(хорошо хоть кешируется, т.е. для PLVDispInfo(NMHdr)^.item.iSubItem > 0 список заново не набивается)...
Если отрабатывать по честному(как OnGetSubItemImage) - то чуть пошустрее будет, т.к. выделение памяти таки затратная операция...

И LVM_SETCALLBACKMASK(и соотвественно state/stateMask or LVIS_FOCUSED or LVIS_SELECTED or ... )
- отсутствует как класс - оттуда и объем(как минимум 12*N бит)...

← →
Sha © (2012-11-23 13:05) [17]

> DVM © (23.11.12 10:51) [14]
> Я не знаю как устроен внутри ListView но в виртуальном
> режиме он намного хуже, чем, например, TVirtualTreeView.
> Даже прокрутка у него хуже работает (отстает от мыши что
> ли, как то заторможенно все).

Вот только что проверил TListView (ViewStyle=vsReport,OwnerData=true,OwnnerDraw=true).
Просто летает на 80.000 элементах.
Прокрутка великолепная.

← →
Sha © (2012-11-23 13:12) [18]

естественно, всеми селектами, птичками, иконками и т.п. придется рулить вручную (Multiselect=false)

← →
han_malign (2012-11-23 13:22) [19]

> Прокрутка великолепная.

- i7?
А клиенты на Келеронах сидят...

TVirtualXxxView - не пробовал, но DrawGrid - всё-таки на порядок быстрее - особенно если значения ячеек несколько раз в секунду обновлять надо(вот только выравнивание на границу ячейки при горизонтальной прокрутке бесит, а пилить лень)...

Кстати - есть еще классический глюк с закраской квадратика на стыке srollbar-ов...

> han_malign (23.11.12 13:22) [19]
> > Прокрутка великолепная. - i7?

i5 )

> ..TVirtualXxxView - не пробовал,

я попробовал, там как раз верт прокрутка не устроила

> но DrawGrid - всё-таки на порядок быстрее -
> особенно если значения ячеек несколько
> раз в секунду обновлять над

Зачем так часто?

> Sha © (23.11.12 13:29) [20]

> я попробовал, там как раз верт прокрутка не устроила

А что там с прокруткой то не так? Там она просто хитрая.

> Вот только что проверил TListView (ViewStyle=vsReport,OwnerData=true,
> OwnnerDraw=true).
> Просто летает на 80.000 элементах.

А у меня при почти аналогичных настройках тормозило. Не сказать чтоб прямо совсем, но какой то дискомфорт при прокрутке был. То было на Delphi7 и XP еще. Правда там был еще один момент, в ячейках отрисовывались галочки, фон полосатый, сами строки цветом. Но не думаю, что именно отрисовка добавляла сильно тормозов.

Сейчас сделал тестовый проект с 1000 000 узлов под XE2 но правда без OwnerDraw - не тормозит.

> DVM © (23.11.12 14:48) [21]
> А что там с прокруткой то не так? Там она просто хитрая.

Да, я знаю.
Просто, единственное существенное отличие от TListView,
которое могло привлечь - различная высота ячеек в таблице.
Так вот как раз такие таблицы с большим количеством строк,
оно прокручивает с ошибкой (на конец таблицы ползунком встает
с 5-6ой попытки).

> А у меня при почти аналогичных настройках тормозило.
> Не сказать чтоб прямо совсем, но какой то дискомфорт при прокрутке был.
> То было на Delphi7 и XP еще. Правда там был еще один момент,
> в ячейках отрисовывались галочки, фон полосатый, сами строки цветом.
> Но не думаю, что именно отрисовка добавляла сильно тормозов.

У меня Delphi7 и XP/W7 - нормально все и с деревом, и с птичками, и с украшайзингом.

← →
han_malign (2012-11-26 18:14) [23]

> Зачем так часто?

- на прошлой работе - заказчик утверждал, что его мотористы отслеживают показания датчиков с временем реакции порядка 50 мс, и 10 Гц для них уже тормоза вызывающие дискомфорт(времена перехода с циферблатов - на жестокое реальное время под DOS)... Правда убедили, что они себе льстят, да и прецизионный АЦП больше 5 Гц физически не выдавал...

- сейчас - уровень сигнала в мониторе каналов захвата голоса 5 раз в секунду обновляется(слово "двести" произносится в среднем за 200 мс(как и известный посыл из трех на три)) - раз в секунду уже реально некомфортно...

> han_malign (26.11.12 18:14) [23]

сейчас проверил на 60-строчном листвью (размер примерно x=600, y=1100)
2 столбца: 1ый - 2 иконки+40 знаков текста, 2ой - 4 иконки + 2 знака,
обновление 17 раз в секунду. Вроде немного,
но все равно ни фига не разглядеть из-за частоты обновления экрана 60 Гц.

← →
han_malign (2012-11-27 12:27) [25]

> сейчас проверил на 60-строчном листвью

процессор оно значительно больше грузит, и принцип перерисовки там не всегда адекватный:
- в DrawGrid можно часто обновлять одну ячейку через InvalidateCell(InvalidateRect)
- ListView - на поверхности только LVM_UPDATE/LVM_REDRAWITEMS, да полный Invalidate...
(InvalidateRect({LVM_GETITEMRECT/LVM_GETITEMINDEXRECT}) - вроде не прокатывает, не помню уже)

Я делал полный Invalidate, получил частоту 17 Гц,
этого вполне достаточно, чтобы не заморачиваться с чем-то другим.

← →
han_malign (2012-11-28 08:26) [27]

> этого вполне достаточно

- повторюсь, у юзверей обычно Celeron - и повезет если из этой эпохи - и еще десяток левых приложений зачастую висит - там не достаточно...

З.Ы. Нельзя программистам мощные рабочие станции выдавать - расслабляет... А ведь пророчат эпоху ультра-мобильных ПК, где особо не разгуляешься...

Анти SelectAll...Существует что-нибудь подобное? Найти похожие ветки