| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Какое условие для раскраски Grid [D6, dBase, FoxPro]
btv © (2002-10-02 15:37:00)Здравствуйте, мастера! Я уже прочитала подсказку, как раскрасить строку в сетке, но я только учусь и потому, видимо, не знаю очевидного. Какое условие нужно написать, для того, чтобы расскрасить строку, если в ней произошла корректировка, т.е. поменяли количество и надо бы поменять цвет этой строки.
Заранее, благодарю.
btv (2002-10-07 08:48:00) [1]ещё раз спасибо и особое elv © (03.10.02 15:28). Такое решение стоит над средой, могла бы и сама догадаться((. Всё получилось. Извините за отнятое время.
Max Zyuzin (2002-10-07 08:46:00) [2]>elv © (04.10.02 16:26)
Тут считать бесполезно... Сергей в принципе все верно описал. Но дело в том, что заводить неинформативное поле в таблице, ни есть верный подход. (Согласитесь, что поле абсолютно ненужное).
KSergey (2002-10-05 10:52:00) [3]
> 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 - придется все перепродумыватьи переделывать, но для первой программы вполне сойдет.
Так что удачи!
elv (2002-10-04 16:26:00) [4]
> Max Zyuzin © (04.10.02 14:56)
> Этот способ менее ресурсоемкий, чем предложенные
> Вот это как раз боольшое может...
Давай посчитаем. В каком случае расходуется больше памяти когда создаешь массив или когда не создаешь? ;)
Max Zyuzin (2002-10-04 15:33:00) [5]Хе. а я так понял, что надо отмечать только те записи, что были поправлены при текущем просмотре
elv (2002-10-04 15:28:00) [6]> KSergey © (04.10.02 09:18)
> Вот если бы elv слегка задумался - он бы понял, что так
...
> С одним полем, понятно, не пойдет - изменит один -> "обкраснится" у всех. Впрочем, вполне возможно, что нужна
А зачем иначе?
> именно такая функциональность - автор-то молчит и не
> уточняет...
Так как мы с тобой не телепаты. Мое решение подходит. Как мне кажется. В любом случае массивы не выход. Пользователю что в течении дня не выходить из программы? Или сохранять массив на винте после каждого изменения?
> PS: А вообще меня всегда удивляет молчаливость авторов вопроса.
Эт точно (с)
Max Zyuzin (2002-10-04 14:56:00) [7]>elv © (04.10.02 14:45)
Этот способ менее ресурсоемкий, чем предложенные
Вот это как раз боольшое может...
elv (2002-10-04 14:45:00) [8]
> Max Zyuzin © (03.10.02 15:44)
> Я так понимаю что это "кирпич" в наш огород :) ??
Ага. :)
> Очень спорно что "от лукавого" а что нет... Создавать поле
> в таблице, для весьма сомнительных манипуляций или немного
> попрограмировать...
Программирование ценно не само по себе, а как способ решения задач. Я предложил простое, опробованное решение удовлетворяющее условию. Этот способ легко смогут реализовать неопытные программисты. Этот способ менее ресурсоемкий, чем предложенные. Этот способ реализуется с заведомо меньшим кол-ом ошибок.
Вот такое мое скромное мнение :))
btv (2002-10-04 14:08:00) [9]автор уже не молчит) Спасибо всем большое. Маленький обзор проблемы: пользователь будет только один, база-локальная(FoxPro),
проект-первый!)
Слышала, что так можно сделать, но у самой не получилось, надеюсь, что пока не получилось!!!
KSergey (2002-10-04 09:18:00) [10]> 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: А вообще меня всегда удивляет молчаливость авторов вопроса. Хоть бы сказал(а) "О, так пойдет, только вот тут бы еще", или "О, не, это все фигня так делал, были такие то проблемы" и т.д. Ну или наконец "О, класс!". Хотя бы было понятно можно (нужно) еще что-то подсказать/уточнить или нет.
А то все начинают мозги парить: что же автор имел в виду? Всякие варианты предлагают, сами пытаются что-то уточнить - складывается впечатление, что отвечающим это все намного интереснее и нужнее, чем автору... Странно как-то получатеся...
Max Zyuzin (2002-10-03 15:44:00) [11]>elv © (03.10.02 15:28)
Я так понимаю что это "кирпич" в наш огород :) ??
Очень спорно что "от лукавого" а что нет... Создавать поле в таблице, для весьма сомнительных манипуляций или немного попрограмировать...
elv (2002-10-03 15:28:00) [12]btv (02.10.02 15:37)
Я завел поле, в котором отмечал были изменения или нет.
При смене операционного дня отметку удалял.
Что сверх того, то от лукавого (с) ;)
Max Zyuzin (2002-10-03 14:05:00) [13]>KSergey © (03.10.02 13:52)
Ну ничего, у вас подробнее полуилось :) главное что бы получилось то, что надо у btv
KSergey (2002-10-03 13:52:00) [14]
> Max Zyuzin © (03.10.02 10:36)
Вчитался в ваш пост - одно и тоже. Напрасно кнопки мучал ;)
KSergey (2002-10-03 13:41:00) [15]Дополнение к п.3.
Естественно имеется в виду, что перед запихиванием в массив проверяем новое значение поля и сохраненное значение в переменной; запихиваем только в случае несовпадения.
KSergey (2002-10-03 13:39:00) [16]Про что-то подобное в принципе уже говорили, но если позволите.
Я бы сделал так:
1.Завести динамический массив, очистить его при открытии формы. В этом массиве будем хранить значение ключевого поля изменившихся строк.
2.В BeforeEdit в нек. временную перемнную (глобальную для формы или в ее переменную-член) скинуть значение цены.
3.В AfterEdit (а может в Before/AfterPost?) запихать значение ключевого поля этой строки в созданный массив (соотв. скорректировав его длину), если там этого значения еще нет.
4.В том месте, где будет изменяться цвет, проверять наличие ID (ключевого поля) тек. отображаемой строки и если оно там есть - значит цвет меняем. Поиск можно осуществлять тупо перебором: ну сколько человек за один присест цен изменит? Ну 100, ну 200, ну наконец 500 - я не думаю, что больше. Обббежать такой массивчик - да нефиг делать, для пользовательского интерфейса это не страшно. Ну если уж очень хочется - можно сразу вставлять ID строк так, чтобы они были упорядочены, тогда можно применять алгоритны быстрых поисков в упорядоченных списках (если уж совсем приспичит).
5.Ну понятно, что при закрытии формы массив уничтожить ;)
К стати, если даже цену изменят вначале, а потом вернут на первоначальное знчение - то этот алгоритм все равно будет ее подсвечивать. Вообще-то на мой взгляд это правильно, меняли ведь? Вот и получите. Впрочем возможно, что это не устроит клиента.. Хотя я и не согласен.
Max Zyuzin (2002-10-03 10:36:00) [17]Можно попробовать примерно следующюю весч.
Поставить обработчик события BeforeEdit у датасета, которым вы пользуетесь. при срабатывании запоминать значение полей. А так же событие AfterEdit проверку изминилиь ли у вас значения.
Ну и паралельно создать список какой нить, где хранить ключевые поля которые надо раскрашивать. И добавлять в него если измениения произошли, ну и в конче концов, раскрашивать эти записи (из списка), как написано в
http://www.delphikingdom.com/helloworld/dbgridcolor.htm
Sergey13 (2002-10-03 09:32:00) [18]2btv (03.10.02 09:15)
В вашем случае (отлавливать корректировку поля - если я правильно понял) это сделать будет сложно(если вообще возможно) без извратов (например с таблицами в памяти от Rx). Дело в том, что все подобные примеры расчитаны на раскраску в зависимости от текущего значения какого то поля. А вам надо в зависимости от неравенства страрого и нового значения этого поля. Увидеть это неравенство сложно - т.к. любой комит-рефреш исправленной записи приведет к потере старого значения.
btv (2002-10-03 09:15:00) [19]Ничего не выходит(( Есть в поле значение и пользователь его может скорректировать на большее или на меньшее, но отличное от 0. На что нужно проверять, для того что бы отметить скорректированную строку
btv (2002-10-03 08:54:00) [20]Zz_ Большое спасибо за ответ. Хотя это поле изначально >0, это вариант!) А с подсказкой Дельфийского королевства я и работала, но только не знала какое условие нужно в моём случае.
| |
Страницы: 