Здравствуйте, _Artem_, Вы писали:
_A_>Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще.
То есть список, фактически, совершенно не нужен. Реальная задача пользователя — найти требуемый договор. При этом спорю, что если попытаться расшифровать понятие "требуемый", то там явно выделяется поиск по номеру, поиск по клиенту, и все остальные типы поиска. Что подсказывает способ реализации удобного UI: оптимизировать его под эти специфические задачи.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, _Artem_, Вы писали:
_A_>>Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще.
S>То есть список, фактически, совершенно не нужен. Реальная задача пользователя — найти требуемый договор. При этом спорю, что если попытаться расшифровать понятие "требуемый", то там явно выделяется поиск по номеру, поиск по клиенту, и все остальные типы поиска. Что подсказывает способ реализации удобного UI: оптимизировать его под эти специфические задачи.


prox@inbox.ru

вчера посмотрел 101 example VS 2005

10000 строк добавление 135 ms
+ грид
22 МБ

Здравствуйте, _Artem_, Вы писали:

_A_>А начитать список договоров, дело необходимое, их просматривать нужно и искать среди них ...

10 000 договоров просматривать по доному? И кто способен на такой подвиг?

Я как пользователь хотел бы от систем подобной вашей хороший поиск. Чтобы мне были выданы 1-10 довговоро отвечающих неким критериям. И уж на них то памяти хватит из любого положения.

Здравствуйте, _Artem_, Вы писали:

_A_>А то, что нужно выводить их в гриде, что тут непонятного? ListView не подойдет. Нужно выводить весть список договоров!

А зачем весь то? Ну, ты сам попробй просмотреть 10 000 довговорв! Озвереш ведь!!!

Найди где-нить системы вроде Референта/Консультанта/Гаранта и погляди на их поиск.

Здравствуйте, _Artem_, Вы писали:

VGn>>Вы нормально можете объяснить за каким х** ВЕСЬ?
VGn>>Религия такая?
_A_>А что 10000 записей по Вашему много?

Ага. Невероятно. На неделю просмотра для среднего человека.

И я согласен с товарищем, кроме как религией вывод 10 000 записей на экран объяснить нельзя ни чем.

_A_>Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.

На фиг такой интерфейс. Не пререгладывайте ISAM-ные привычки на клиент-серверные решения. Делайте запрос вычисляющий количество документов и выводите эту информацию. А список огрничивайте сотней записей, ну, максимум 1000-ей.

Здравствуйте, _Artem_, Вы писали:

_A_>Почему Вы так решили? Мне кажется существует много различных областей где нужно просматривать и больший объем информации ...

Примеры можно привести? Я вот и сам бухгалтерией занимаюсь, и не мало решений делал/видел в этой области. И уверен, что просматривать более 20 записей смысла нет. А раз так, то есть туча решений от подлистывания инфромации (а-ля Гугль), до уточнения запросов.

Здравствуйте, Владек, Вы писали:

В>В каждый момент времени в этом гриде видно одну страницу записей (ну пусть 30-40 штук), пользователь за раз может охватить 7-9 записей. И не важно сколько вообще записей в гриде, для пользователя эти числа не меняются — значите есть возможность изменить способ подгрузки записей из базы и тем самым сократить объем используемой памяти.

Более того. Если пользователь не идиот, то ищет он по критериям. А раз так, то лучше сделать удобный поиск. А просмотр всех записей только на крайняк. И тут уж пусть сам думает что ему лучше много метров памяти и долгие часы листания или один запрос.

Здравствуйте, _Artem_, Вы писали:

_A_>Здравствуйте, Sinclair, Вы писали:
S>>И что? Есть какая-то задача, требующая наличия именно >10000 договоров в одном окне? Или все-таки вас заставили прикрутить к этому окну фильтры, чтобы пользователи не утонули в этом списке?
_A_>Фильтр есть, но и никто не пользуется. Есть поиск по номеру договора, и по любой колонке вообще.

ну если юзеры так уперто не хотят пользоваться поиском — то тогда не грузить все в грид, а подгружать в процессе пролистывания...

ЗЫ. Оттого, что хочется загнать 10000 записей в память и съедается много памяти — это не вина .NET...

_A_>>Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.

А стоит ли ?

Может как в анекдоте про программера:

-Пап, а почему солнышко каждый день на востоке встаёт ?
-Проверял сынок ? Точно на востоке встаёт ?
-Да, точно.
-Ну тогда ничего не трогай сынок, ничего не меняй.

Здравствуйте, VladD2, Вы писали:

VD>10 000 договоров просматривать по доному? И кто способен на такой подвиг?

VD>Я как пользователь хотел бы от систем подобной вашей хороший поиск. Чтобы мне были выданы 1-10 довговоро отвечающих неким критериям. И уж на них то памяти хватит из любого положения.
Требуется ввод информации по этим договорам, каждый месяц. Затем требуется проверка введенной в другом месте информации. Грубо говоря, есть сеть филлиалов, в которой вводится информация по этим договорам, после чего данные передаются в центр, где их проверяют и выставляют клиентам. Поэтому и требуется грид.

Здравствуйте, _Artem_, Вы писали:

_A_>Здравствуйте, anton_t, Вы писали:

_>>Искать их нужно, но зачем же грузить всё в память? Делаешь текстбокс и листвью под ним. При наборе текста в текстбоксе, если там введено 2 или более символов идёт запрос к базе, из которого заполняется листвью. Чего же проще?
_A_>А то, что нужно выводить их в гриде, что тут непонятного? ListView не подойдет. Нужно выводить весть список договоров!

Можно точно так же их выводить в гриде. Зачем пользователю СРАЗУ 10000 записей?

Здравствуйте, _Artem_, Вы писали:

_A_>Здравствуйте, VladD2, Вы писали:

VD>>10 000 договоров просматривать по доному? И кто способен на такой подвиг?

VD>>Я как пользователь хотел бы от систем подобной вашей хороший поиск. Чтобы мне были выданы 1-10 довговоро отвечающих неким критериям. И уж на них то памяти хватит из любого положения.
_A_>Требуется ввод информации по этим договорам, каждый месяц. Затем требуется проверка введенной в другом месте информации. Грубо говоря, есть сеть филлиалов, в которой вводится информация по этим договорам, после чего данные передаются в центр, где их проверяют и выставляют клиентам. Поэтому и требуется грид.

А почему не сделать пэйджинг (как в гугле)? Уже, кстати, советовали.

Здравствуйте, anton_t, Вы писали:

_>А почему не сделать пэйджинг (как в гугле)? Уже, кстати, советовали.
А вот это идея , спасибо!

Здравствуйте, RuneLord, Вы писали:

RL>Выводить все 10000 договоров — это преотличнейшее юзабилити, пускай юзера, вместо того чтобы пасьянсы расскладывать, тренируют свои глаза бегая по гриду из 10000 строк. Правильно работать надо, а не фигней страдать.

Правильно — это как, воинственный ты наш? Например, юзеру надо что-то найти, он открывает поисковую форму (или переключается в нее, если она уже открыта), попадает мышью в нужное поле, вводит там строку поиска, жмет кнопку "Искать". Программа находит 5000 элементов. Он снова переходит в поисковую форму, дополняет поиск (а это может быть пара букв), снова жмет, программа находит, он снова переключается — и так до тех пор, пока не будет найдено приемлимое число.

Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.

"Правильно работать" для сервера и программиста не всегда совпадает с "удобно работать" для юзера, увы.

RL>Объясните откуда такое бредовое требование все и сразу?

То что ты его не понимаешь не значит что оно бредовое.

Здравствуйте, Andrbig, Вы писали:

A>Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.

Ну во-первых для этого не надо держать весь список в памяти. Посмотрите на Google Suggest... Он что по-вашему, держит все сочетания слов со статистикой использования в памяти (JScript, медленный интернет...)? Если нужен скроллинг, то существует страничный доступ... Другой вопрос, что, конечно, программисту проще не париться и залить все 10000 строк сразу... А когда у клиента их будет миллион, то программист скажет, что на это он, конечно, не рассчитывал, но, конечно, подумает что тут можно сделать... И сделает чтобы они чуть поменьше в памяти занимали, дождавшись, когда их будет 10 миллионов.

Здравствуйте, Max.Subpixel, Вы писали:

MS>Здравствуйте, Andrbig, Вы писали:

A>>Другой вариант. Список из 10..20 тыс. Юзер вводит в фильтрационном поле букву, список тут же фильтруется, еще букву — еще фильтруется, еще пара букв — и результат перед глазами. Сравни сколько кликов по окнам и полям происходит в этих вариантах.

MS>Ну во-первых для этого не надо держать весь список в памяти. Посмотрите на Google Suggest... Он что по-вашему, держит все сочетания слов со статистикой использования в памяти (JScript, медленный интернет...)? Если нужен скроллинг, то существует страничный доступ... Другой вопрос, что, конечно, программисту проще не париться и залить все 10000 строк сразу... А когда у клиента их будет миллион, то программист скажет, что на это он, конечно, не рассчитывал, но, конечно, подумает что тут можно сделать... И сделает чтобы они чуть поменьше в памяти занимали, дождавшись, когда их будет 10 миллионов.

Я и не говорил, что список надо перебирать глазами. Я говорил о фильтрации.

OK, я этим все понятно, следующий вопрос. Вываливается список, надо выделить N записей и у всех заменить определенное поле на какое-то значение. Для определенности пусть это будет ФИО человека, обрабатывающего эти позиции.

Вариант со страницами. Рассмотрим случаи, когде N > размера страницы (иначе все одинаково и сравнивать нечего). Итак, надо сделать поиск, выделить все строки, указать заменяемое поле и новое значение, нажать "Заменить". Перейти на следующую страницу, выделить, указать, заменить. При этом надо держать в голове (!) сколько страниц уже пройдено и высчитывать сколько осталось. Да, круглые цифры запомнить легко, но так же легко и сбиться.

Вариант с общим списком. Находятся все записи у которых нужное поле пусто (или сразу найти или найти все и отфильтровать — неважно), выделяется первая строка, хватается бегунок и тащится вниз. Просходит страшный скроллинг, компьютер трясется и скрипит, но скролирует. Слева есть номер строки, дотаскивается бегунок до нужной строки, там выделяется строка с нажатым Shift. Все выделяется. Выбирается поле, новое значение, жмется кнопка "Заменить". Это делается один раз.

Что удобнее юзеру и где меньше возможностей запутаться?

Здравствуйте, _Artem_, Вы писали:

_A_>Требуется ввод информации по этим договорам, каждый месяц. Затем требуется проверка введенной в другом месте информации. Грубо говоря, есть сеть филлиалов, в которой вводится информация по этим договорам, после чего данные передаются в центр, где их проверяют и выставляют клиентам. Поэтому и требуется грид.

И за месяц появляется по 10 000 договоров?

Если, нет, то и выводи договоры за месяц. Думаю их уже будет разумное количество.

Если же их и в этом случае будет много, то дай возможность фильтровать договоры по датам (с — по). Если программа будет запоминать этот фильтр между сеансами ты еще поможешь людям видеть что они сделали, а что нет.

Ну, и вообще если речь идет о последовательном контроле, то грид на фиг не упал. Выводи один договор и сделай две кнопки "следующий договор" и "предыдущий договор".

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, _Artem_, Вы писали:

VGn>>>Вы нормально можете объяснить за каким х** ВЕСЬ?
VGn>>>Религия такая?
_A_>>А что 10000 записей по Вашему много?

VD>Ага. Невероятно. На неделю просмотра для среднего человека.

VD>И я согласен с товарищем, кроме как религией вывод 10 000 записей на экран объяснить нельзя ни чем.

_A_>>Уже есть сложившийся интерфейс программы, хотим его переписать под .Net.

VD>На фиг такой интерфейс. Не пререгладывайте ISAM-ные привычки на клиент-серверные решения. Делайте запрос вычисляющий количество документов и выводите эту информацию. А список огрничивайте сотней записей, ну, максимум 1000-ей.

Тот же MSDN выдает только первые 500 найденных результатов

Здравствуйте, kirya_kg, Вы писали:

_>Тот же MSDN выдает только первые 500 найденных результатов

Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?

_>>Тот же MSDN выдает только первые 500 найденных результатов

A>Это пример того, как не надо делать, т.к. напрочь теряется смысл поиск в результатах. Какой прок искать в результатах, если ясно, что это не весь результат? Что даст поиск по нему?

Получать результат и выводить его — это не всегда одно и то же