С появлением DataGridViewComboBoxColumn в DataGridView наконец-то появилась возможность использовать ComboBox при заполнении таблиц данными.
Но ведь эта же возможность существует в MS Access уже давно.
Там вместо DataGridView используется форма в режиме таблицы, где в качестве поля ввода можно использовать ComboBox.

В MS Access я подключаюсь к базе данных MySQL через ODBC.
В качестве источника данных ComboBoxColumn я использую таблицу длиной более 5000 строк.
Здесь все работает очень быстро: и вывод таблицы на экран с большим количеством строк, и ComboBoxColumn раскрывается мгновенно, и автоподстановка прекрасно работает.

Когда я попробовал сделать тоже самое в DataGridView, то был очень озадачен низкой производительностью DataGridViewComboBoxColumn.
Здесь каждый раз при обращении к ComboBoxColumn процессор загружается до 100% и виснет порядка четырех-пяти секунд перед тем как список раскроется (процессор Celeron 1700, ОЗУ 512).
Причем в качестве провайдера подключения к данным я использую не ODBC, а более производительный MySQL Connector Net 5.0.3 (с ODBC все работает еще медленнее).
Подключение к данным стандартное:

Я попробовал на примере из MSDN слепить пользовательский DataGridViewComboBoxColumn с использованием ComboBox из System.Windows.Forms.
Здесь на первый взгляд производительность заметно повысилась, но все равно отстает от MS Access, зависание примерно на одну секунду остается.

Отсюда вытекают следующие вопросы:
1. Действительно ли производительность DataGridViewComboBoxColumn такая низкая, или это у меня что то не так?
2. Если это так, то можно здесь что то сделать или все таки придется писать самому пользовательский DataGridViewComboBoxColumn с использованием ComboBox из System.Windows.Forms (подозреваю, работа предстоит не хилая)?
3. И последнее, стоит ли вообще заморачиваться с формами доступа к данным MySQL на Visual Studio, когда в MS Access в принципе есть все самое необходимое в готовом виде (единственно, что останавливает, так это то, что за саму MS Access надо не слабые деньги платить, тогда как есть бесплатные инструменты для создания NET приложений).

PS
У меня из-за этого головняка вся работа встала, никак не могу определиться в какую сторону двигаться.
Очень прошу откликнуться, полагаю ни я один такой на распутье оказался.

Можно попробовать добавить индекс в DataTable (после Fill), по полю InvN. Для этого устанавливается свойство PrimaryKey:

Попробовал, тормоза те же.

Так что, это не только у меня тормозит?
Выход то есть какой нибудь?

Выход - либо использовать нормальные компоненты от сторонних производителей (например, попробовать DevExpress), либо для комбобокса использовать отдельный источник данных, заполняемый 1 раз вручную. Насчёт последнего не уверен, можно ли навесить на колонку грида такой источник, не пробовал.

Означает ли это, что бесплатные компоненты NET Framework 2.0 - "ненормальные" в силу их бесплатности, т.е. своего рода демо версии в которые намеренно заложены "ненормальности" для того, чтобы вынудить разработчиков платить деньги за уже "нормальные" коммерческие компоненты?

Приведенный мною код - это часть процедуры Sub New() класса формы.
Разве это не "отдельный источник данных, заполняемый 1 раз вручную"?


Это сообщение отредактировал(а) kuzyaka - 15.1.2007, 13:31

Ну, можно и так сказать. Правда о преднамеренной ущербности говорить вряд ли можно, скорее у M$ просто не хватило времени и/или желания доводить некоторые свои компоненты до 100% коммерческого уровня. Бесплатное не бывает хорошим, по крайней мере не у мелкософт.


При раскрытии комбобокса, каждый раз происходит выборка данных из таблицы датасета.

Насколько я понимаю - это приговор, и ситуацию не изменить?