я считал из базы 10 000 строк. далее вручную добавляю их в DataGridView, который уже с нужными колонками лежит на форме. процесс этот вешает интерфейс, т.к. слишком много строк. хотелось бы выделить это в параллельный поток, но! грид уже создан и из параллельного потока обращаться к нему можно тока через Invoke, что не решает проблему. подскажите как быть? пока у меня только одно в голове: создавать другой грид в этом самом параллельном потоке, там его наполнять и потом заменять на тот, который на форме!
спасибо.
использую C#
16.10.10 10:37: Перенесено модератором из '.NET' — TK
Здравствуйте, corpse56, Вы писали:
C>я считал из базы 10 000 строк. далее вручную добавляю их в DataGridView, который уже с нужными колонками лежит на форме. процесс этот вешает интерфейс, т.к. слишком много строк. хотелось бы выделить это в параллельный поток, но! грид уже создан и из параллельного потока обращаться к нему можно тока через Invoke, что не решает проблему. подскажите как быть? пока у меня только одно в голове: создавать другой грид в этом самом параллельном потоке, там его наполнять и потом заменять на тот, который на форме!
Здравствуйте, corpse56, Вы писали:
C>Здравствуйте! C>задачка такая:
C>я считал из базы 10 000 строк. далее вручную добавляю их в DataGridView, который уже с нужными колонками лежит на форме. процесс этот вешает интерфейс, т.к. слишком много строк. хотелось бы выделить это в параллельный поток, но! грид уже создан и из параллельного потока обращаться к нему можно тока через Invoke, что не решает проблему. подскажите как быть? пока у меня только одно в голове: создавать другой грид в этом самом параллельном потоке, там его наполнять и потом заменять на тот, который на форме! C>спасибо. C>использую C#
Поставьте в цикл заполнения грида Application.DoEvents().
А в обшем то грид избыточен по информации, с таким кол. записей.
Здравствуйте, Jolly Roger, Вы писали:
JR>А более подробно можно о причинах?
Программа a la SQL Query Analyser, только в применении к специфической БД и со специальным языком запросов. Должна показывать то, что будет возвращено запросом, а он может вернуть и 100, и 10000 элементов. Никто их всех просматривать не будет, просто если что-то в основном софте не так — запустят в этой программе и будут смотреть, что не так.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Программа a la SQL Query Analyser, только в применении к специфической БД и со специальным языком запросов. Должна показывать то, что будет возвращено запросом, а он может вернуть и 100, и 10000 элементов. Никто их всех просматривать не будет, просто если что-то в основном софте не так — запустят в этой программе и будут смотреть, что не так.
То есть отладочный инструмент? Может быть, хотя на мой взгляд, объём в 10 000, да хотя-бы в 1000, делает эту информацию фактически бесполезной. Максимум, на что хватит терпения — ну от силы сотня записей, а значит и показывать больше бесполезно. Если эта сотня причины проблем не выявит, то человек скорее всего просто плюнет и "пойдёт другим путём". Чтобы такой инструмент был полезен, нужна возможность задавать критерий неправильности, а тогда первый-же десяток записей покажет и причину. По-моему так.
Здравствуйте, Jolly Roger, Вы писали:
JR>То есть отладочный инструмент?
Да.
>Может быть, хотя на мой взгляд, объём в 10 000, да хотя-бы в 1000, делает эту информацию фактически бесполезной.
Нет. Надо проверить выборку. Что еще предложишь ? Ты так и Query Analyser дискредитируешь — он тоже может много записей вернуть. Что положено, то и возвращает.
>Максимум, на что хватит терпения — ну от силы сотня записей, а значит и показывать больше бесполезно.
Я же сказал — их все просматривать никто не будет.
>Если эта сотня причины проблем не выявит, то человек скорее всего просто плюнет и "пойдёт другим путём".
Нет тут других путей . Есть сортировка по столбцам datagrid, если ему нужно будет часть просмотреть по какому-то критерию.
>Чтобы такой инструмент был полезен, нужна возможность задавать критерий неправильности, а тогда первый-же десяток записей покажет и причину.
И критерия такого нет. Надо просто знать, что этот запрос возвращает. Анализ результатов никакими машинными методами там не возможен, там только человек может решить, что так, а что не так. К примеру, нет какой-то записи, а она вроде как должна быть. Почему ее нет ? Или есть запись, которой вроде как бы не положено здесь быть. Значит, код для запроса в чем-то неверен, или же в БД не те данные.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Нет. Надо проверить выборку. Что еще предложишь ? Ты так и Query Analyser дискредитируешь — он тоже может много записей вернуть. Что положено, то и возвращает.
PD>Я же сказал — их все просматривать никто не будет.
Вот то-то и оно. Вы когда-нибудь просматривали хотя-бы 1000 записей в поиске причин? Наверняка нет. А если их никто не будет просматривать, то зачем тратиться на отображение? А никто и не тратится — ни Query Analyser, ни, наверняка, Ваше решение. Он просто рисует на экране записи по индексу из уже существующего, возвращённого набора.
А потому возможность просмотреть всю выборку там — просто побочная фича, которой практически никто на больших выборках не пользуется, и которая присутствует просто потому, что её наличие ничего не стоит.
Теперь сравните с ситуацией ТС:
считал из базы 10 000 строк. далее вручную добавляю их в DataGridView
>>Если эта сотня причины проблем не выявит, то человек скорее всего просто плюнет и "пойдёт другим путём".
PD>Нет тут других путей . Есть сортировка по столбцам datagrid, если ему нужно будет часть просмотреть по какому-то критерию. PD>К примеру, нет какой-то записи, а она вроде как должна быть. Почему ее нет ?
И Вы будете просматривать все 10000 элементов, чтобы убедиться — нет её таки? Не верю
10 000 записей Вам будут полезны не более, чем 100. Вы всё равно будете искать способы сузить диапазон поиска — то есть использовать обычные приёмы отладки в условиях ограниченности инструментальных средств.
Ну и плюс к тому, оладочные средства — очень узкая и специализированная ниша. В жизни отображение данных не самоцель, а способ довести информацию до оператора, дабы он её использовал для принятия решения — пардон за банальность. Но в этом плане должна отображаться только реально значимая информация, помогающая, а не мешающая своей избыточностью.
Весьма сильными факторами в развитии состояния психической напряженности явились дефицит и избыточность информации в заданиях по различению тональных сигналов. В частности, при выполнении задания в условиях дефицита информации у испытуемых значительно нарушалась эффективность работы, на что указывают такие данные, как увеличение относительной частоты ошибочных ответов и среднего времени реакции по сравнению с фоном почти в 3 раза, ухудшение показателей обучаемости (по критериям скорости и надежности реагирования) на 30–40%. Об эмоциональном напряжении свидетельствует также учащение пульса, в среднем, с 65 до 75 ударов в мин, повышение кожной температуры с 32,5 до 33,1°С появление выраженных внешних признаков напряженности.
Еще более существенными были перечисленные выше сдвиги при выполнении задания в условиях избыточности информации.
Исследования в условиях возрастающего потока информации показали, что эмоциональная напряженность у испытуемых возникает при идентификации 4-х и более сигналов. Так, если при идентификации 3-х сигналов относительная частота ошибочных ответов составляет 2,5%, то при 4-х сигналах этот показатель возрастает до 13, 1%, среднее время реакции увеличивается, соответственно с 733 до 957 сигм, частота пульса – с 69 до 73 ударов в мин., кожная температура – с 32,9 до 33,4°С. В последующих сериях при увеличении количества предъявляемых сигналов отмеченные сдвиги нарастают, причем наиболее выраженными являются изменения показателей, характеризующих эффективность выполнения задания.
Здравствуйте, Jolly Roger, Вы писали:
JR>Вот то-то и оно. Вы когда-нибудь просматривали хотя-бы 1000 записей в поиске причин? Наверняка нет. А если их никто не будет просматривать, то зачем тратиться на отображение? А никто и не тратится — ни Query Analyser, ни, наверняка, Ваше решение. Он просто рисует на экране записи по индексу из уже существующего, возвращённого набора.
Естественно. И у меня там тоже virtual-mode. Показывают те, которые сейчас видны, доступны все.
JR>А потому возможность просмотреть всю выборку там — просто побочная фича, которой практически никто на больших выборках не пользуется, и которая присутствует просто потому, что её наличие ничего не стоит.
Ничего не понимаю. Есть datagrid, он показывает все записи — потенциально. И десятка два записей реально нарисованы в нем, остальные под скроллингом. Естестивенно, датагрид в вирт. режиме, естественно, все данные получены и куда-то записаны при исполнении запроса. Ты считаешь, что датагрид не показывает все ? Бога ради. Я считаю, что он показывает все записи.
JR>Теперь сравните с ситуацией ТС:
JR>
JR>считал из базы 10 000 строк. далее вручную добавляю их в DataGridView
Ну и я так же. Формально — добавил, фактически — указал их количество (чтобы скроллинг работал) и сделал обработчик CellValueNeeded. Это детали, а не принцип.
JR>И Вы будете просматривать все 10000 элементов, чтобы убедиться — нет её таки? Не верю
Я все объяснил уже. Если датагрид содержит 10000 элементов, то из этого не следует ни то, что их можно все увидеть сразу, ни то, что их все кто-то будет рассматривать, зато следует, что без всяких усилий можно увидеть любую или убедиться в отсутствии ее.
Здравствуйте, Jolly Roger, Вы писали:
JR>И заодно помедитируйте над вопросом "Кому нужны 10 000 строк в UI элементе?"
Такое ТЗ! ну и по логике как бы должно быть... если придумают лучше — с удовольствием переделаю! но я учту и передам им это, пусть подумают!
спасибо за ответ!
PD>>Бывают, что нужны. У меня был такой случай. JR>А более подробно можно о причинах?
Обычно в гриде показывается сумма записей. В моём случае это были клиенты. Менеджер смотрел на эту цифру и это, по его словам, грело ему душу
"Нормальные герои всегда идут в обход!"
. Есть сортировка по столбцам datagrid, если ему нужно будет часть просмотреть по какому-то критерию.
