Какое условие для раскраски Grid

← →
btv (2002-10-02 15:37) [0]

Здравствуйте, мастера! Я уже прочитала подсказку, как раскрасить строку в сетке, но я только учусь и потому, видимо, не знаю очевидного. Какое условие нужно написать, для того, чтобы расскрасить строку, если в ней произошла корректировка, т.е. поменяли количество и надо бы поменять цвет этой строки.
Заранее, благодарю.

← →
Prooksius (2002-10-02 15:53) [1]

Мой совет: возми DBGridEh, напиши обработку события OnGetCellParams.
Там есть параметр AFont: TFont и Background: TColor, эти цвета-то и меняешь, как захочется.
Меньше проблем и все гораздо проще.

← →
AM (2002-10-02 16:03) [2]

А на самом, чтобы очень много полезного по этой теме узнать загляни на:
http://www.delphikingdom.com/helloworld/dbgridcolor.htm

Удачи!

← →
Zz_ (2002-10-02 16:04) [3]

grid.canvas.brush.color := clWindow;
if(table.fieldByName("QQ").asinteger>0)then grid.canvas.brush.color := clAqua;

← →
btv (2002-10-03 08:54) [4]

Zz_ Большое спасибо за ответ. Хотя это поле изначально >0, это вариант!) А с подсказкой Дельфийского королевства я и работала, но только не знала какое условие нужно в моём случае.

← →
btv (2002-10-03 09:15) [5]

Ничего не выходит(( Есть в поле значение и пользователь его может скорректировать на большее или на меньшее, но отличное от 0. На что нужно проверять, для того что бы отметить скорректированную строку

← →
Sergey13 (2002-10-03 09:32) [6]

2btv (03.10.02 09:15)
В вашем случае (отлавливать корректировку поля - если я правильно понял) это сделать будет сложно(если вообще возможно) без извратов (например с таблицами в памяти от Rx). Дело в том, что все подобные примеры расчитаны на раскраску в зависимости от текущего значения какого то поля. А вам надо в зависимости от неравенства страрого и нового значения этого поля. Увидеть это неравенство сложно - т.к. любой комит-рефреш исправленной записи приведет к потере старого значения.

← →
Max Zyuzin (2002-10-03 10:36) [7]

Можно попробовать примерно следующюю весч.
Поставить обработчик события BeforeEdit у датасета, которым вы пользуетесь. при срабатывании запоминать значение полей. А так же событие AfterEdit проверку изминилиь ли у вас значения.
Ну и паралельно создать список какой нить, где хранить ключевые поля которые надо раскрашивать. И добавлять в него если измениения произошли, ну и в конче концов, раскрашивать эти записи (из списка), как написано в
http://www.delphikingdom.com/helloworld/dbgridcolor.htm

← →
KSergey (2002-10-03 13:39) [8]

Про что-то подобное в принципе уже говорили, но если позволите.
Я бы сделал так:
1.Завести динамический массив, очистить его при открытии формы. В этом массиве будем хранить значение ключевого поля изменившихся строк.
2.В BeforeEdit в нек. временную перемнную (глобальную для формы или в ее переменную-член) скинуть значение цены.
3.В AfterEdit (а может в Before/AfterPost?) запихать значение ключевого поля этой строки в созданный массив (соотв. скорректировав его длину), если там этого значения еще нет.
4.В том месте, где будет изменяться цвет, проверять наличие ID (ключевого поля) тек. отображаемой строки и если оно там есть - значит цвет меняем. Поиск можно осуществлять тупо перебором: ну сколько человек за один присест цен изменит? Ну 100, ну 200, ну наконец 500 - я не думаю, что больше. Обббежать такой массивчик - да нефиг делать, для пользовательского интерфейса это не страшно. Ну если уж очень хочется - можно сразу вставлять ID строк так, чтобы они были упорядочены, тогда можно применять алгоритны быстрых поисков в упорядоченных списках (если уж совсем приспичит).
5.Ну понятно, что при закрытии формы массив уничтожить ;)

К стати, если даже цену изменят вначале, а потом вернут на первоначальное знчение - то этот алгоритм все равно будет ее подсвечивать. Вообще-то на мой взгляд это правильно, меняли ведь? Вот и получите. Впрочем возможно, что это не устроит клиента.. Хотя я и не согласен.

← →
KSergey (2002-10-03 13:41) [9]

Дополнение к п.3.
Естественно имеется в виду, что перед запихиванием в массив проверяем новое значение поля и сохраненное значение в переменной; запихиваем только в случае несовпадения.

← →
KSergey (2002-10-03 13:52) [10]

> Max Zyuzin © (03.10.02 10:36)

Вчитался в ваш пост - одно и тоже. Напрасно кнопки мучал ;)

← →
Max Zyuzin (2002-10-03 14:05) [11]

>KSergey © (03.10.02 13:52)
Ну ничего, у вас подробнее полуилось :) главное что бы получилось то, что надо у btv

← →
elv (2002-10-03 15:28) [12]

btv (02.10.02 15:37)
Я завел поле, в котором отмечал были изменения или нет.
При смене операционного дня отметку удалял.
Что сверх того, то от лукавого (с) ;)

← →
Max Zyuzin (2002-10-03 15:44) [13]

>elv © (03.10.02 15:28)
Я так понимаю что это "кирпич" в наш огород :) ??
Очень спорно что "от лукавого" а что нет... Создавать поле в таблице, для весьма сомнительных манипуляций или немного попрограмировать...

← →
KSergey (2002-10-04 09:18) [14]

> elv © (03.10.02 15:28)
> btv (02.10.02 15:37)
> Я завел поле, в котором отмечал были изменения или нет.
> При смене операционного дня отметку удалял.

> Max Zyuzin © (03.10.02 15:44)
> >elv © (03.10.02 15:28)
> Я так понимаю что это "кирпич" в наш огород :) ??
> Очень спорно что "от лукавого" а что нет... Создавать поле
> в таблице, для весьма сомнительных манипуляций или немного
> попрограмировать...

Вот если бы elv слегка задумался - он бы понял, что так не пойдет по очень простой причине. С полем идею и я обсасывал - да не придумал как выпуться более-менне пристойно ;)
А дело в том, что таких полей придется создавать по одному на каждого пользователя. Так ведь? А при неизвестном их числе задача, мягко говоря, нетривиальная, если вообще имеющая смысл.
С одним полем, понятно, не пойдет - изменит один - "обкраснится" у всех. Впрочем, вполне возможно, что нужна именно такая функциональность - автор-то молчит и не уточняет...

PS: А вообще меня всегда удивляет молчаливость авторов вопроса. Хоть бы сказал(а) "О, так пойдет, только вот тут бы еще", или "О, не, это все фигня так делал, были такие то проблемы" и т.д. Ну или наконец "О, класс!". Хотя бы было понятно можно (нужно) еще что-то подсказать/уточнить или нет.
А то все начинают мозги парить: что же автор имел в виду? Всякие варианты предлагают, сами пытаются что-то уточнить - складывается впечатление, что отвечающим это все намного интереснее и нужнее, чем автору... Странно как-то получатеся...

← →
btv (2002-10-04 14:08) [15]

автор уже не молчит) Спасибо всем большое. Маленький обзор проблемы: пользователь будет только один, база-локальная(FoxPro),
проект-первый!)
Слышала, что так можно сделать, но у самой не получилось, надеюсь, что пока не получилось!!!

← →
elv (2002-10-04 14:45) [16]

> Max Zyuzin © (03.10.02 15:44)
> Я так понимаю что это "кирпич" в наш огород :) ??
Ага. :)
> Очень спорно что "от лукавого" а что нет... Создавать поле
> в таблице, для весьма сомнительных манипуляций или немного
> попрограмировать...
Программирование ценно не само по себе, а как способ решения задач. Я предложил простое, опробованное решение удовлетворяющее условию. Этот способ легко смогут реализовать неопытные программисты. Этот способ менее ресурсоемкий, чем предложенные. Этот способ реализуется с заведомо меньшим кол-ом ошибок.
Вот такое мое скромное мнение :))

← →
Max Zyuzin (2002-10-04 14:56) [17]

← →
elv (2002-10-04 15:28) [18]

> KSergey © (04.10.02 09:18)
> Вот если бы elv слегка задумался - он бы понял, что так
...
> С одним полем, понятно, не пойдет - изменит один -> "обкраснится" у всех. Впрочем, вполне возможно, что нужна
А зачем иначе?
> именно такая функциональность - автор-то молчит и не
> уточняет...
Так как мы с тобой не телепаты. Мое решение подходит. Как мне кажется. В любом случае массивы не выход. Пользователю что в течении дня не выходить из программы? Или сохранять массив на винте после каждого изменения?

> PS: А вообще меня всегда удивляет молчаливость авторов вопроса.
Эт точно (с)

← →
Max Zyuzin (2002-10-04 15:33) [19]

Хе. а я так понял, что надо отмечать только те записи, что были поправлены при текущем просмотре

← →
elv (2002-10-04 16:26) [20]

> Max Zyuzin © (04.10.02 14:56)
> Этот способ менее ресурсоемкий, чем предложенные
> Вот это как раз боольшое может...
Давай посчитаем. В каком случае расходуется больше памяти когда создаешь массив или когда не создаешь? ;)

← →
KSergey (2002-10-05 10:52) [21]

> elv © (04.10.02 15:28)
> > KSergey © (04.10.02 09:18)
> > Вот если бы elv слегка задумался - он бы понял, что так
>
> ...
> > С одним полем, понятно, не пойдет - изменит один -> "обкраснится"
> у всех. Впрочем, вполне возможно, что нужна
> А зачем иначе?
> > именно такая функциональность - автор-то молчит и не
> > уточняет...
> Так как мы с тобой не телепаты. Мое решение подходит. Как
> мне кажется. В любом случае массивы не выход. Пользователю
> что в течении дня не выходить из программы? Или сохранять
> массив на винте после каждого изменения?

А разве в вопросе было условие раскрашивания в течении всего дня? Спршено "Как выделить", а в течении одного сеанса работы программы, в течении открытия формы или в течении всего дня - не уточнялось, так что приходится додумыват за автора и каждому понимать по-своему.

> elv © (04.10.02 16:26)
> > Max Zyuzin © (04.10.02 14:56)
> > Этот способ менее ресурсоемкий, чем предложенные
> > Вот это как раз боольшое может...
> Давай посчитаем. В каком случае расходуется больше памяти
> когда создаешь массив или когда не создаешь? ;)

Давай.
Предположим, всего в прайсе 1000 цен (т.е. строк в БД). За один присест человек сколько поправит? Ну пусть грубо треть - т.е. 300. Имеем массив, соовтетствующий значению поля в 300 элементов.
В случае дополнительного поля - это одно значение на каждую запись (они ведь тоже в памяи лежал для отображения, верно?), плюс служебная информация...

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

> btv (04.10.02 14:08)
> автор уже не молчит) Спасибо всем большое. Маленький обзор
> проблемы: пользователь будет только один, база-локальная(FoxPro), проект-первый!)
> Слышала, что так можно сделать, но у самой не получилось,
> надеюсь, что пока не получилось!!!

Ну про неполучилось - я совсем не понял (что не получилось-то?), но вот если бы сразу вопрос был поставлен полностью - не было бы и мордобоя.
А при таком раскладе (имеется в виду 1 пользователь, а не перваяпрограмма) метод elv © (03.10.02 15:28) самый простой и подходящий.
Правда, когда пользователей вдруг станет 2 - придется все перепродумыватьи переделывать, но для первой программы вполне сойдет.
Так что удачи!

← →
Max Zyuzin (2002-10-07 08:46) [22]

>elv © (04.10.02 16:26)
Тут считать бесполезно... Сергей в принципе все верно описал. Но дело в том, что заводить неинформативное поле в таблице, ни есть верный подход. (Согласитесь, что поле абсолютно ненужное).

← →
btv (2002-10-07 08:48) [23]

ещё раз спасибо и особое elv © (03.10.02 15:28). Такое решение стоит над средой, могла бы и сама догадаться((. Всё получилось. Извините за отнятое время.

Какое условие для раскраски Grid Найти похожие ветки