при обновл. датасета оставить DBGrid в той же позиции скроллинга?

← →
ari_9 (2007-10-28 12:10) [0]

использую QuantumGrid 6

на форме лежит cxGrid в котором отображаются данные запроса к БД. по некоторым действиям пользователя вне этого грида запрос обновляется. поставить после обновления курсор в гриде на ту же запись, что и была до - вопросов нет. но как сохранить ту же позицию окна скроллинга ?

допустим, запрос выдает 100 строк, в грид помещается 20. пользователь скроллингом "спустился" до просмотра записей с 80 по 100. но при этом курсор датасета остался на первой записи. потом происходит рефреш (по сути закрытие и открытие запроса). как перед этим зафиксировать состояние скроллбара cxGrid"а и потом установить его ?

← →
ari_9 (2007-10-28 14:05) [1]

если сделать

x := cxGridDBTableView.Controller.TopRecordIndex; ... обновление данных ... cxGridDBTableView.Controller.TopRecordIndex := x;

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

← →
ari_9 (2007-10-29 11:19) [2]

ап

ну хорошо, допустим в случае QuantumGrid можно пользоваться Controller.TopRecordIndex, играясь как-то с тем, скроллит ли пользователь в данный момент грид или нет, скажем, при помощи того же GetCaptureControl. но как-то все это громоздко, да и в стандартном vcl гриде нет никакого TopRecordIndex

гугл нашел один топик на sql.ru, где автору внятного ответа не дали

не верю, что никто здесь не сталкивался с этой проблемой

← →
Ega23 © (2007-10-29 11:22) [3]

написать свой грид

← →
Sergey13 © (2007-10-29 11:24) [4]

> [1] ari_9 (28.10.07 14:05)
> то есть тащит пользователь "каретку "скроллбара, тут от
> БД пришло сообщение, данные обновились, но скроллбар уже
> не движется.

Ужос. Я бы убил программиста. 8-)

← →
Правильный_Вася (2007-10-29 11:27) [5]

Locate по первичному ключу в наборе данных

← →
ari_9 (2007-10-29 11:27) [6]

Sergey13

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

← →
ari_9 (2007-10-29 11:30) [7]

Правильный_Вася

и снова, и снова, я не устану повторять .... (с)

мне хочется сохранить ПОЗИЦИЮ ОКНА СКРОЛЛИНГА на наборе данных. открыли датасет, в нем куча записей. курсор датасета стоит на первой. пользователь не кликая на собственно столбцы и соответственно не перемещая курсор датасета проскроллил грид до последней записи. как в этом случае поможет Locate ?

← →
Ega23 © (2007-10-29 11:34) [8]

> ari_9 (29.10.07 11:30) [7]

посмотрите внимательно реализацию TDBGrid.

← →
Sergey13 © (2007-10-29 11:35) [9]

> [6] ari_9 (29.10.07 11:27)

Сделай простую кнопку обновить и нарисуй какую нибудь лейблу с надписью "Данные в БД изменились. Для обновления нажмите на кнопку."

← →
ari_9 (2007-10-29 11:46) [10]

Sergey13

диспетчера вносят заказы. каждый видит данные остальных. в среднем заказ вносится за 3 секунды и подтверждается еще через 10-20. эвенты приходят примерно раз в секунду

Ega23

да читаю модули .... пока туго (

если у кого аналогичная проблема для Eh - здесь кое-что есть http://www.sql.ru/forum/actualthread.aspx?tid=169750

← →
Sergey13 © (2007-10-29 11:51) [11]

> [10] ari_9 (29.10.07 11:46)
> эвенты приходят примерно раз в секунду

Ну и что? А оператор например может обработать 1 заявку в минуту максимум. Какой смысл показывать ему новые данные чаще?

← →
ari_9 (2007-10-29 12:13) [12]

Sergey13

вопросов нет, диспетчер человек и за десятые заказ не примет. но когда он выбирает какой заказа обрабатывать (передавать на исполнение), то есть по сути просто смотрит на список, и, гад такой, иногда его даже скроллит 8-), вот тут то и нужно обновление по КАЖДОМУ эвенту. иначе он просто не увидит, что вот этот две секунды назад появился, а тот секунду назад другой диспетчер взял

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

← →
Sergey13 © (2007-10-29 12:58) [13]

> [12] ari_9 (29.10.07 12:13)
> но все это как-то .... как гланды через анальный проход

По мне, так твой подход под это определение подходит на 120%.
Ни один человек не сможет принять решение (выбрать 1 из сотни вариантов), если условия перед ним меняются раз в секунду. У авиадиспетчеров и то условия проще.
Ты пытаешься достичь некоего умозрительно-теоретического идеала, а благими намерениями, как известно, вылоежна дорога в ад.

ИМХО.

← →
ari_9 (2007-10-29 13:06) [14]

Sergey13

с другой стороны, данные не обновились - диспетчер кликает на заказ, который уже взят кем-то другим и физически в БД его статус уже изменен, то есть мы просто не успели убрать его из грида - тоже плохо. причем плохо и в варианте окна с сообщением, и при "тихом игноре". в первом случае вынуждаем еще раз кликнуть на "Ok", во втором можно запутаться, что происходит

в реальности сейчас уже есть предыдущая версия ПО - там разработчик не заморачиваясь с эвентами, скроллами и прочим просто повесил рефреш запроса на таймер

вроде бы люди привыкли ... в реальности "висящих" заказов редко когда более двадцати

← →
Sergey13 © (2007-10-29 13:16) [15]

> [14] ari_9 (29.10.07 13:06)
> в первом случае вынуждаем еще раз кликнуть на "Ok",

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

> [14] ari_9 (29.10.07 13:06)
> в реальности "висящих" заказов редко когда более двадцати

Сейчас еще окажется, что и заводят то их раз в час, и на обработке сидит один чел на неполном рабочем дне. 8-)

> вроде бы люди привыкли
Привыкнуть можно ко всему. Это не показатель. Ты поговори с людьми то, изложи варианты. Осчастливливать людей без их информирования как то некузяво.

← →
Ega23 © (2007-10-29 13:17) [16]

> с другой стороны, данные не обновились - диспетчер кликает
> на заказ, который уже взят кем-то другим и физически в БД
> его статус уже изменен, то есть мы просто не успели убрать
> его из грида - тоже плохо. причем плохо и в варианте окна
> с сообщением, и при "тихом игноре". в первом случае вынуждаем
> еще раз кликнуть на "Ok", во втором можно запутаться, что
> происходит

Как кто-то "захватил запись", при попытке другого оператора изменить эту запись выдавать сообщение: "Запись редактируется тем-то и тем-то". Этого вполне достаточно.
А когда программа, которой я пользуюсь, вдруг начинает что-то делать без моего ведома - я эту программу выбрасываю.

← →
Правильный_Вася (2007-10-29 13:41) [17]

> ari_9 (29.10.07 11:30) [7]
> и снова, и снова, я не устану повторять .... (с)
> мне хочется сохранить ПОЗИЦИЮ ОКНА СКРОЛЛИНГА на наборе
> данных.

что мешает совместить переход на нужную позицию с совмещением окна?

а вообще дубовая организация работы
диспетчер не должен видеть все, если таких, как он, несколько
он отвечает за свой участок работы
и тогда обновлять имеет смысл после операций ЭТОГО диспетчера, а не всей толпы

← →
ari_9 (2007-10-29 13:58) [18]

я всем признателен за комментарии, но давайте про предметную область не будем спорить. в диспетчерской сидит шесть девочек, обычно занято 4-5 линий. за сутки проходит порядка двух тысяч заказов

Sergey13

ну да .... но мы сервер будем долбить "легкими" запросами в рид-онли транзакциях. понятно, что любые действия по обновлению пойдут отдельно. и потом, при "ушел в туалет" эти запросы будут только тогда, когда остальные активно редактируют - если ушли все - от БД не будет эвентов

Правильный_Вася

ПОСЛЕ того, как какая-то операция пользователем выполнена, естественно рефреш будет. а если диспетчер смотрит на экран и ждет заказ с определенными характеристиками, который можно будет поставить "в пару" к какому-то уже взятому на выполнение ... ей что, десять минут ежесекундно кнопку "обновить" нажимать ?

>>вообще дубовая организация работы
возможно, но это вне моей компетенции

вообще давайте вернемся к моему вопросу. тут поступило мнение от коллег, что когда пользователь проявляет какую-то активность на гриде - конкретно в моем случае он может его скроллировать и открывать попап-меню, содержимое которого привязанно к конкретной строке набора данных, не стоит и пытаться что-то обновлять "в фоне"

интересно другое. как я понимаю, все после рефреша в своих приложениях делают Locate, чтобы отпозиционироваться на ранее выбранную запись. в обычном гриде никаких TopRecordIndex и TopRowIndex нет. получается, де-факто стандартом является игнорирование положения выбранной записи в окне скроллинга после обновления данных ?

> интересно другое. как я понимаю, все после рефреша в своих
> приложениях делают Locate, чтобы отпозиционироваться на
> ранее выбранную запись. в обычном гриде никаких TopRecordIndex
> и TopRowIndex нет. получается, де-факто стандартом является
> игнорирование положения выбранной записи в окне скроллинга
> после обновления данных ?
>

Стандартом де-факто считается тащить на клиент выборку в 20-40 записей. А не 10000 и не 100000.

> [18] ari_9 (29.10.07 13:58)
> но давайте про предметную область не будем спорить

Почему? Это 90% решения задачи. У тебя как раз, ИМХО, проблема в неверной модели.

> получается, де-факто стандартом является игнорирование положения
> выбранной записи в окне скроллинга после обновления данных ?
Стандартом де-факто является обновление данных по требованию юзера. При этом смена положения грида - это нормальное и ожидаемое поведение программы.

← →
ari_9 (2007-10-29 14:11) [21]

да какая разница, если эти 40 записей у вас не влезут все по высоте, точно так же как и сто тысяч :)

← →
ari_9 (2007-10-29 14:12) [22]

вопрос закрыт, проблема решена

спасибо

> да какая разница, если эти 40 записей у вас не влезут все
> по высоте, точно так же как и сто тысяч :)

У меня влезает.

← →
jack128_ (2007-10-29 14:35) [24]

Писалось для 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;

← →
jack128_ (2007-10-29 14:39) [25]

> // этот метод переоткрывает в том числе и DocumentGrid.DataSet
> dmMain.RefreshDocDataSets;

ну и восстанавливает текущую запись, естественно.

← →
ari_9 (2007-10-29 14:45) [26]

jack128_

спасибо

при обновл. датасета оставить DBGrid в той же позиции скроллинга? Найти похожие ветки