Пошло-поехало. Просил же специально:

Дмитрий77...не надо советов ... использовать что-то вместо Listview.

именно объектная модель Listview в .Net с точки зрения выполнения скоростной задачи с большим количеством итемов / большой динамикой изменений этих итемов.
Единственный выбор который мне надо сделать: между .Net Listview и API-реализацией ( для этой задачи )

Быстрее видимо сделать, а потом уже смотреть на живых тестах. Если не прокатит, воткну API-шные, тем более есть считай готовый класс под эти нужды.

Меня .Net и Listview вполне устраивает.
А в другой форме у меня 15 Listview на разных вкладках - по 2-10 итемов в каждом. И че мне их на C++/API рисовать?
В .Net макет удобно делать: всякие там Dock=Fill, Padding очень помогают, в том же VB6 сплошные ресайзы надо писать.

>А вот сколько кнопочек-текстбоксов-итп максимально возможно разместить на форме (винформ)?
В VB6 контролов на форме может быть 255 максимум. Но можно использовать массивы (неудобно жутко).
В .Net на сколько понимаю такого ограничения точно нет, м.б. есть какое-то большое но мне думаю хватит.

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

Ни о каком самописном контроле речь не идет.

Речь идет исключительно об этом:
List View (Windows) - MSDN - Microsoft

И об этом:
ListView - класс (System.Windows.Forms) - MSDN - Microsoft

Причем второе есть не более чем Net-обертка над первым.

Если использовать первое, то никаких лишних "вычислений" я точно не делаю.

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

Но объектная обертка, как было указано может страдать :
1) дополнительными индусскими вычислениями
2) дополнительными индусскими идеями, которые не всегда плохи, но иногда приводят к глюкам. Пример с тулбаром я недавно приводил.
Под "нагрузкой" оно может иметь очень негативные последствия. И в этом случае оправдан API-вариант .

Примером классической программы от Microsoft где именно Listview используется с подобной динамикой/объемами является "Windows Fax and Scan" (Консоль факсов в XP). Скриптом можно добавить хоть 20000 заданий "сразу". На серверных OS можно использовать хоть 100 модемов (=100 одновременных вызовов). При отправке информация в "активных" строчках динамически меняется.
У меня реализовано примерно тоже самое. Никакие самопало-гриды здесь не катят.

Другой пример -Outlook Express и его производные, но последний пример менее удачен, так как нет описываемой динамики.

D129 обновлять строку на экране 50 раз в секунду - это мягко говоря, неправильно.
Об обновлении одной строки 50 раз в секунду речь не идет.
У меня там таймаут обновления где-то секунда.
Но в предельных нагрузочных случаях за секунду может одновременно обновиться 50 строк (разных), или например добавиться 50 строк.

У меня эта модель прекрасно работает на
VB6+Listview_API
но плохо работала на
VB6+Listview(объектная модель VB6)

Сейчас я хочу сделать ту же модель на
.Net + Listview(объектная модель .Net)

Естественно с учетом опыта(объектная модель VB6) у меня некоторые опасения.

Чего рассуждать, в процессе изготовления пока. Только динамику фиг протестируешь пока приложение целиком готово не будет.

D129Вопрос вот в том, как вы делаете это обновление - через перезагрузку списка?
Нет конечно.
Через правку item/subitems.
На языке API:
LVM_INSERTITEM
LVM_SETITEM

D129Ну и какую проблему вы опасаетесь получить?

15016495
В VB6(объектная модель) была например следующая проблема:

авторВыполняем любую из команд:



Проблема в том, что когда любая из них выполняется (не для выделенного, а для любого итема), то ListView делает для выделенной записи (для той кот. Selected) прокрутку в видимую область (EnsureVisible)

Т.е. когда много записей, они постоянно добавляются и изменяются, невозможно даже сделать прокрутку (все время скручивает на выделенную запись).

Вылечилось только полным отказом от объектной модели.

D129И опять скажу - WPF
В WPF не лез. Но насколько понимаю ListView в WPF -это вообще другой контрол. Не по теме.

Изопропилне делай преждевременной оптимизации - будет плохо - заменишь реализацию
Интерфейс к списку сделай сейчас так, чтоб легко замену реализации произвести
Примерно по этому пути я и иду. В VB6 именно реализация и была заменена. У меня перед глазами 2 VB6 варианта, с которых и слизываю. Есть надежда/предположение что .Net-объектная модель таки заведется.

[quot Antonariy]Дмитрий77А гасить прокрутку в сабклассинге не пробовал? Обычно это универсальное средство от нежелательных телодвижений.
Отлавливаешь ...
Вот скажи, мне сейчас это зачем, VB6 лечить?
Если ты глянешь в ту тему, то увидишь что подобные заплатки делать пытались, под твоим кстати чутким руководством.
После неуспешных попыток было плюнуто и сделано с нуля на API, не без трудозатрат, но успешно (сразу было ясно что успешно, но теперь еще и проверено временем - по крайне мере я не вижу больше писем от упертых юзеров типа: я тут попытался добавить 30000 job-ов и у меня все нафиг зависло. Раньше иногда получал подобные баг-репорты).

А в .Net-модели этого бага скорее всего нет (его и в 6-х контролах (которые не пригодны сам знаешь почему) на VB6 нет).
Но фиг знает что в .Net-Listview есть.
Ты вроде в этом понимаешь, с тобой тогда обсуждали "скоростные характеристики", типа API-Listview "быстрее" и т.п.
Что нибудь про .Net-листвью плохое/хорошее сказать можешь? Ну, с каким-то модельными свойствами типа "ShowItemTooltips" лучше лишний раз не играться, это понятно.

А по динамике/скорости что касается добавления/правки item/subitems и "лишних индусских расчетов"?

По сортировке по столбцам, когда много записей? Тоже самое что в API? -там пришлось попотеть особенно с датами если помнишь (в VB6 в объектной модели кстати быстрая сортировка и не требует крушений мозга).

Ну вот, кой какие результаты предварительные.
3 Listview -в общей сложности 500 записей (чего есть сейчас в тестовой БД).
Делаю статическую загрузку (циклом)

API в VB6 загружает за 70мс (чисто добавление в Listview)
Объектный в VB6 делает тоже самое за 200мс
Делаю тот же тест на .Net -650мс -до хрена

Был код типа:


Переделал так


И стало те же 70-80мс.
Думаю, если слегка оптимизировать, результат будет нормальный. Надо делать, а не рассуждать.