| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
при обновл. датасета оставить DBGrid в той же позиции скроллинга? [D7, XP]
ari_9 © (2007-10-28 12:10:00)использую QuantumGrid 6
на форме лежит cxGrid в котором отображаются данные запроса к БД. по некоторым действиям пользователя вне этого грида запрос обновляется. поставить после обновления курсор в гриде на ту же запись, что и была до - вопросов нет. но как сохранить ту же позицию окна скроллинга ?
допустим, запрос выдает 100 строк, в грид помещается 20. пользователь скроллингом "спустился" до просмотра записей с 80 по 100. но при этом курсор датасета остался на первой записи. потом происходит рефреш (по сути закрытие и открытие запроса). как перед этим зафиксировать состояние скроллбара cxGrid'а и потом установить его ?
ari_9 (2007-10-29 14:45:00) [1]jack128_
спасибо
jack128_ (2007-10-29 14:39:00) [2]
> // этот метод переоткрывает в том числе и DocumentGrid.DataSet
> dmMain.RefreshDocDataSets;
ну и восстанавливает текущую запись, естественно.
jack128_ (2007-10-29 14:35:00) [3]Писалось для DBGridEh, но думаю без проблем мона переписать и для cxGrid
procedure TfrmMain.RefreshDocDataSets;
var
Row: Integer;
MoveCount: Integer;
begin
Row := DocumentGrid.Grid.Row;
DocumentGrid.DataSet.DisableControls;
try
// этот метод переоткрывает в том числе и DocumentGrid.DataSet
dmMain.RefreshDocDataSets;
// Эти махинации нуны, что бы текущая запись в гриде отображалась
// в том же месте в гриде.
MoveCount := DocumentGrid.DataSet.MoveBy(DocumentGrid.Grid.VisibleRowCount - Row - 1);
DocumentGrid.DataSet.MoveBy(-MoveCount);
finally
DocumentGrid.DataSet.EnableControls;
end;
end;
Ega23 (2007-10-29 14:25:00) [4]
> да какая разница, если эти 40 записей у вас не влезут все
> по высоте, точно так же как и сто тысяч :)
У меня влезает.
ari_9 (2007-10-29 14:12:00) [5]вопрос закрыт, проблема решена
спасибо
ari_9 (2007-10-29 14:11:00) [6]да какая разница, если эти 40 записей у вас не влезут все по высоте, точно так же как и сто тысяч :)
Sergey13 (2007-10-29 14:10:00) [7]> [18] ari_9 (29.10.07 13:58)
> но давайте про предметную область не будем спорить
Почему? Это 90% решения задачи. У тебя как раз, ИМХО, проблема в неверной модели.
> получается, де-факто стандартом является игнорирование положения
> выбранной записи в окне скроллинга после обновления данных ?
Стандартом де-факто является обновление данных по требованию юзера. При этом смена положения грида - это нормальное и ожидаемое поведение программы.
Ega23 (2007-10-29 14:05:00) [8]
> интересно другое. как я понимаю, все после рефреша в своих
> приложениях делают Locate, чтобы отпозиционироваться на
> ранее выбранную запись. в обычном гриде никаких TopRecordIndex
> и TopRowIndex нет. получается, де-факто стандартом является
> игнорирование положения выбранной записи в окне скроллинга
> после обновления данных ?
>
Стандартом де-факто считается тащить на клиент выборку в 20-40 записей. А не 10000 и не 100000.
ari_9 (2007-10-29 13:58:00) [9]я всем признателен за комментарии, но давайте про предметную область не будем спорить. в диспетчерской сидит шесть девочек, обычно занято 4-5 линий. за сутки проходит порядка двух тысяч заказов
Sergey13
ну да .... но мы сервер будем долбить "легкими" запросами в рид-онли транзакциях. понятно, что любые действия по обновлению пойдут отдельно. и потом, при "ушел в туалет" эти запросы будут только тогда, когда остальные активно редактируют - если ушли все - от БД не будет эвентов
Правильный_Вася
ПОСЛЕ того, как какая-то операция пользователем выполнена, естественно рефреш будет. а если диспетчер смотрит на экран и ждет заказ с определенными характеристиками, который можно будет поставить "в пару" к какому-то уже взятому на выполнение ... ей что, десять минут ежесекундно кнопку "обновить" нажимать ?
>>вообще дубовая организация работы
возможно, но это вне моей компетенции
вообще давайте вернемся к моему вопросу. тут поступило мнение от коллег, что когда пользователь проявляет какую-то активность на гриде - конкретно в моем случае он может его скроллировать и открывать попап-меню, содержимое которого привязанно к конкретной строке набора данных, не стоит и пытаться что-то обновлять "в фоне"
интересно другое. как я понимаю, все после рефреша в своих приложениях делают Locate, чтобы отпозиционироваться на ранее выбранную запись. в обычном гриде никаких TopRecordIndex и TopRowIndex нет. получается, де-факто стандартом является игнорирование положения выбранной записи в окне скроллинга после обновления данных ?
Правильный_Вася (2007-10-29 13:41:00) [10]
> ari_9 (29.10.07 11:30) [7]
> и снова, и снова, я не устану повторять .... (с)
> мне хочется сохранить ПОЗИЦИЮ ОКНА СКРОЛЛИНГА на наборе
> данных.
что мешает совместить переход на нужную позицию с совмещением окна?
а вообще дубовая организация работы
диспетчер не должен видеть все, если таких, как он, несколько
он отвечает за свой участок работы
и тогда обновлять имеет смысл после операций ЭТОГО диспетчера, а не всей толпы
Ega23 (2007-10-29 13:17:00) [11]
> с другой стороны, данные не обновились - диспетчер кликает
> на заказ, который уже взят кем-то другим и физически в БД
> его статус уже изменен, то есть мы просто не успели убрать
> его из грида - тоже плохо. причем плохо и в варианте окна
> с сообщением, и при "тихом игноре". в первом случае вынуждаем
> еще раз кликнуть на "Ok", во втором можно запутаться, что
> происходит
Как кто-то "захватил запись", при попытке другого оператора изменить эту запись выдавать сообщение: "Запись редактируется тем-то и тем-то". Этого вполне достаточно.
А когда программа, которой я пользуюсь, вдруг начинает что-то делать без моего ведома - я эту программу выбрасываю.
Sergey13 (2007-10-29 13:16:00) [12]> [14] ari_9 (29.10.07 13:06)
> в первом случае вынуждаем еще раз кликнуть на "Ok",
Ах бедняжка. Лучше мы програмно будем сервер БД долбить обновлениями, даже если диспетчер в туалете газету читает.
> [14] ari_9 (29.10.07 13:06)
> в реальности "висящих" заказов редко когда более двадцати
Сейчас еще окажется, что и заводят то их раз в час, и на обработке сидит один чел на неполном рабочем дне. 8-)
> вроде бы люди привыкли
Привыкнуть можно ко всему. Это не показатель. Ты поговори с людьми то, изложи варианты. Осчастливливать людей без их информирования как то некузяво.
ari_9 (2007-10-29 13:06:00) [13]Sergey13
с другой стороны, данные не обновились - диспетчер кликает на заказ, который уже взят кем-то другим и физически в БД его статус уже изменен, то есть мы просто не успели убрать его из грида - тоже плохо. причем плохо и в варианте окна с сообщением, и при "тихом игноре". в первом случае вынуждаем еще раз кликнуть на "Ok", во втором можно запутаться, что происходит
в реальности сейчас уже есть предыдущая версия ПО - там разработчик не заморачиваясь с эвентами, скроллами и прочим просто повесил рефреш запроса на таймер
вроде бы люди привыкли ... в реальности "висящих" заказов редко когда более двадцати
Sergey13 (2007-10-29 12:58:00) [14]> [12] ari_9 (29.10.07 12:13)
> но все это как-то .... как гланды через анальный проход
По мне, так твой подход под это определение подходит на 120%.
Ни один человек не сможет принять решение (выбрать 1 из сотни вариантов), если условия перед ним меняются раз в секунду. У авиадиспетчеров и то условия проще.
Ты пытаешься достичь некоего умозрительно-теоретического идеала, а благими намерениями, как известно, вылоежна дорога в ад.
ИМХО.
ari_9 (2007-10-29 12:13:00) [15]Sergey13
вопросов нет, диспетчер человек и за десятые заказ не примет. но когда он выбирает какой заказа обрабатывать (передавать на исполнение), то есть по сути просто смотрит на список, и, гад такой, иногда его даже скроллит 8-), вот тут то и нужно обновление по КАЖДОМУ эвенту. иначе он просто не увидит, что вот этот две секунды назад появился, а тот секунду назад другой диспетчер взял
в случае, когда я откладываю рефреш датасета до тех пор, пока он не отожмет мышу над гридом, я просто логически предполагаю, что нельзя не закончив скроллинг еще и кликнуть на строку грида. вариант, что можно мышой таскать, а стрелочками с энтером параллельно выбирать что-то, мышь не отпуская - это к терапевту 8-) .... но все это как-то .... как гланды через анальный проход
Sergey13 (2007-10-29 11:51:00) [16]> [10] ari_9 (29.10.07 11:46)
> эвенты приходят примерно раз в секунду
Ну и что? А оператор например может обработать 1 заявку в минуту максимум. Какой смысл показывать ему новые данные чаще?
ari_9 (2007-10-29 11:46:00) [17]Sergey13
диспетчера вносят заказы. каждый видит данные остальных. в среднем заказ вносится за 3 секунды и подтверждается еще через 10-20. эвенты приходят примерно раз в секунду
Ega23
да читаю модули .... пока туго (
если у кого аналогичная проблема для Eh - здесь кое-что есть http://www.sql.ru/forum/actualthread.aspx?tid=169750
Sergey13 (2007-10-29 11:35:00) [18]> [6] ari_9 (29.10.07 11:27)
Сделай простую кнопку обновить и нарисуй какую нибудь лейблу с надписью "Данные в БД изменились. Для обновления нажмите на кнопку."
Ega23 (2007-10-29 11:34:00) [19]
> ari_9 (29.10.07 11:30) [7]
посмотрите внимательно реализацию TDBGrid.
ari_9 (2007-10-29 11:30:00) [20]Правильный_Вася
и снова, и снова, я не устану повторять .... (с)
мне хочется сохранить ПОЗИЦИЮ ОКНА СКРОЛЛИНГА на наборе данных. открыли датасет, в нем куча записей. курсор датасета стоит на первой. пользователь не кликая на собственно столбцы и соответственно не перемещая курсор датасета проскроллил грид до последней записи. как в этом случае поможет Locate ?
| |
Страницы: 