Хочу уточнить

[ssl]

- Менять высоту строки нельзя?
- Выделение - только строки целиком? Ни прямоугольником, ни столбцами выделять не предполагается?
- Сортировку запускать, ИМХО, логичнее после отпускания Ctrl (при сортировке по нескольким столбцам). Ну или добавить новый TRxSortEngineOption (seoInProgress какой-нить), чтоб сортировщик сам мог принять решение. Не всегда ведь оправдано гонять SQL-сервер промежуточными (и не нужными) сортировками.
- У всех гридов, что я видел, повторяется недостаток: если в заголовке столбца выравнивание по центру, а самый правый видимый столбец достаточно широкий (правый край далеко уехал за пределы грида), то текст заголовка тоже уезжает за край. Может, при отрисовке считать правой границей такого столбца границу грида? Ну, типа Rect.Right:= min(Rect.Right, Grid.ClientWidth);

Кстати, если уж фильтр перенесли в DataSet, то и сортировку уж добавили бы к TField (CanSort, smUp, smDown, SortOrder). Вопрос, конечно не по адресу, это к слову..

[alexs]

По пунктам:
1. Напрямую высоту строки изменить можно. Автопдбор высоты строки - в планах. Есть небольшие трудности и нет времени (необходимости) доделать.
2. Мне это не нужно Да и смысла не вижу.
3. Практически все неборы данных, за исключением стандартного из Lazarus TSQLQuery не нагружают сервер сортировками. И Zeos, и мой FBDataSet умеют сами сортировать выбранные с сервера данные. Поэтому так сделано. А пользователю удобно - он сразу видит результат.
4. А в чём смысл таких шировких столбцов? Мне кажется что это ошибка интерфейса от разработчика. Хотя - можешь конечно подправить в тексте как тебе надо.
5. Насчёт признака сортировки - это конечно правильно, чтобы он находился в DataSet-е. Но я пока это решить не могу...

[ssl]

1) Да, высоту в пикселях я нашёл потом. Только удобнее все же в строках текста, ИМХО.
2) Хм. Ну, например, я даю юзерам выделять произвольные области (GridEh) для выгрузки данных в эл. таблицу. Ну, чтоб не им не пришлось вычищать потом лишнее или предварительно прятать столбцы.
3) Это что, ВСЕ отобранные данные высасываются на клиента??? Не, понятно, что работать с километровыми списками не правильно, но у юзеров и произвольная фильтрация по полным спискам местами реализована. Что ж теперь - включать/отключать сортировку в зависимости от размера результата?

И еще вопрос: сортировщику (TRxDBGridSortEngine) передаётся строка: список полей. То есть, сначала грид бежит по списку столбцов, формирует эту строку, потом Engine её тут же парсит. В чём сермяжная правда? Не проще отдать энжину SortColumns? А то и просто сам грид?

И главное: если сподоблюсь прикрутить прямоугольное выделение - засылать? Или тут дело принципа?

[ssadragon]

Это что, ВСЕ отобранные данные высасываются на клиента???

А для чего они тогда отбираются?
Для того чтобы клиенту показать, не?

[ssl]

А для чего они тогда отбираются?

Они не "отбираются", их отбирает пользователь. Гарантировать, что будет отобрано вменяемое количество записей, можно только одним способом: если отобрано больше некоего предела, ничего не показывать, а выдавать соответствующее сообщение. Мне такой подход, мягко говоря, не нравится. И как разработчику, и как пользователю.
Или есть другие, не ведомые мне, варианты?

[alexs]

3) Это что, ВСЕ отобранные данные высасываются на клиента???

А как вы хотели?
Между прочим, есть SQL сервера, которые пока не отдадут всю порцию отобранных данных клиенту, вообще не принимают следующий запрос.
Это FireBird изначально многозапросный, и позволяет прерывать выборку данных на середине. Другие - не факт.
И если вы не отображаете все отобранные данные юзеру - то это не значит что они клиентской библиотекой не скачиваются.
Ну и вообще - выбирать для отображения в гриде записей больше чем на 2-3 экрана - бессмысленно. Даже если вам операторы 100 раз будут кричать, что это им НАДО. Эти данные никто руками не читает.
И ещё подумайте над такой мыслью - зачем повторно и не один раз переоткрывать на сервере запросы, если можно уже отобранный набор данных отсортировать на клиентской машине (у которых сейчас параметры производительности и памяти столько же, сколько года 3-5 назад на хорошем сервере). И что полезнее для сетевого трафика?

[ssl]

М-да. Я, похоже, не понимал своего счастья
Насчет "нефиг юзеру получать больше сотни записей" - это, можно сказать, девиз Но ситуации бывают разные. Тут мне ближе позиция Камноедова (Модест Матвеич такой был): с одной стороны - надо стараться, но и с другой - техника "должна выдерживать прямое попадание в кабину самого необученного академика".
А мне, значит, сильно повезло с сервером. Ничего не надо переоткрывать, читай себе порциями с любой строки. И для сетевого трафика полезней

Да, так как насчет прямоугольного выделения? Делать?

[alexs]

Если реализуешь - патчик конечно жду.