Вот - возникла задача.
Есть таблица с данными. Есть невидимая псевдоколонка, которая содержит "достоверность" данных в таблице. Хотелось бы как-то по псевдоколонке красить ячейку с данными.
Выбранный путь: в скрипте перебираем все ячейки, для достоверности ячейки через хитрый механизм определяем цвет значения. После этого для ячейки выставляем цвет.
На последнем шаге вышел ступор.
Почему не хочу перейти на формулы для свойства Color ячейки. Поле достоверности - битовая маска из 20 бит. Возможны любые комбинации битов, от которых меняется значение цвета (результат - 5 цветов). Как ее развернуть с условиями чтоб получить цвет в expression - этот вопрос возник ранее и я его решил обойти через ручной перебор ячеек :)
Почитав форум и хелп, создается впечатление, что выбранный способ обхода не поможет :( Но надежда все же теплится.
Введение второй псевдоколонки, в которую бы запихивался цвет после пересчета в скрипте связано с большими затратами труда (необходимо перековырять механизм автоматической генерации DW в зависимости от входных параметров). Конечно, я на это пойду если не получится красить из функции PB цвета ячеек, но ох как не хочется :(

ПС: затирать битовую маску достоверности нельзя (типа в функции пройти все ячейки и поменять маску на цвет, сослаться на эту же ячейку в expression) - поскольку нужно сразу и маску, и цвет.

Благодарю за любой совет...

Та вот как раз этот способ я и описывал как крайний случай... ОЧень не хочется на него идти. Потому что получается что на 1 колонку отображаемых данных у меня будет 2 скрытых псевдоколонки (одна содержит признак достоверности, вторая - цвет). ИМХО избыточность, но в случае ПБ похоже что это необходимость :( Так решения и не нашел...
Почему не хочу идти по данному пути. Потому что ДВ генерится автоматом - там сложная система генерации, через которую формируется несколько типов ДВ, каждый из типов ДВ опять же в зависимости от параметра отчета генерится по-своему... А тут получается нужно ковырять в дно тыскать, т.е. перебирать весь этот ужас с нуля :(
Вобщем, очень расстроило, что в ПБ походу нет возможности выполнить такую простую операцию, как принудительно назначить цвет ячейке :(

Ну так это все понятно :) За одним только мааааленьким ньюансом, который я упоминал выше :) Мне нужно И цвет выставить, И значение достоверности видеть (вывести скажем по дабл-клику в responce-окне).
Вот такие пироги.
Вобщем, я пошел по этому дурацкому пути - впринципе я старался от него уйти и потому создал тему...
Чтоб было понятно, что имеется ввиду:
поле цвет1 для скорости не выбирается функцией из базы, а рассчитывается и через кеширование выставляется на клиенте после retrieve.

НО!! Если кто-то может предложить что-то суттевое по проблеме - как выставить цвет отдельной ячейки в ДВ без привязывания к expression - хотелось бы узнать. По кр мере на будущее :)

цвет1 рассчитывается на основе достоверность1 и все.
НО! Достоверность1 - это некоторая битовая маска, состоящая из 20 битов. Каждый бит - отдельный критерий достоверности. В зависимости от разного сочетания битов - получаем разную картину достоверности того или иного значения.
Я не знаю, насколько велики возможности expression - можно ли туда вписать СТОЛЬКО вариаций... Но ИМХО генерить expression с таким диким алгоритмом внутри... ИМХО опять же неподъемно получится - следующая жертва не разберется, что я пытался этим сказать :)
Это я к идее о том, чтоб не создавать третье поле а прописать критерии расчета цвета в expression каждой ячейки

Ну да, это один из вариантов. Но мне показалось, что чем выполнять кучу вызовов функции, которая по достоверности определит цвет, оптимальней выполнять обработку на клиенте с использованием кеширования.
Так, для понимания аргументов: минимальное кол-во значений в отчете 24*5 = 120. И умножить на 2 - будет с достоверностями (вызовы функций). И если еще умножить на 2 а не 3 - будет вообще жуть сколько вызовов. Мне кажется, что это плохой вариант :) Я типа его обошел тем, что вызовов по выбору цвета будет ровно столько, сколько разных вариантов достоверности встретится в отчете. Вооот.

Да, и еще. 120 значений в отчете - это действительно минимум. Средняя величина - 900 :) 900*2 - это кол-во вызовов для получения данных и достоверности. Если добавить еще 900 вызовов функций для получения цвета - то мне кажется, таки выгодней было сделать так, как я придумал... Вот!

На реализацию именно подмены вместо функции ушло примерно 2 часа :) 1 раз тыскать.
А вот про трафик по локальной сети... Дело в том, что время от времени появляется желание подключиться и посмотреть данные по модему. Ни дай Бог ЖСМу...
А еще бывают ситуации, когда люди работают в филиалах... Там при самом хорошем раскладе 2 мбита. А тут, я Вам скажу, очень ощутимы лишние обращения к серверу... Проверено на собственной шкуре. Вот такие пироги.

Ну тут как-бы 20 бит... Насколько вообще в expression можно с битами-то работать??а если перебирать все комбинации... ;) эт ужас.
Насчет только моего варианта... На будущее все еще теплится надежда, что таки можно как-то выставить цвет ячейки без использования псевдоколонок. Вот так вот - раз, и прямо из сырцов.
Может можно было бы поиграться как-то с буферами еще (типа в зависимости от состояния ячейки менять цвет, а состояние выставлять скриптом из условий своих), но это ИМХО вообще редкостный неподдерживаемый геморрой :)

Ну-у-у-у... Битов-то 20 :) Разные комбинации битов приводят к одному и тому же цвету, вобщем-то. Но перебрать их... Нет уж, увольте :)

Да, действительно в результате мы получаем 5 цветов (хотя я, кажется, об этом не говорил :))

Отличненько, формулу, как говорится, в мемориз :)
Впринципе тоже вариант. Но опять же - переписать основные комбинации хотя бы битов - это ж тоже не коротко...
Да и добавить условия на раскраску при генерации DW не так быстро... В моем конкретном случае.
Вобщем, пока остаюсь при мнении что у меня пока все оптимально наваяно :)

Жаль, что, похоже, таки нет способов раскрасить ячейку в ДВ из паверСкрипта. Без expression. Очень даже жаль. Разве что может как-то через WinAPI...

18-я веснаVadim RomanenkoЖаль, что, похоже, таки нет способов раскрасить ячейку в ДВ из паверСкрипта.
Так это и так было известно с самого начала :)
Но вы не расстраивайтесь - это бы вам никакой выгоды не дало (ни по скорости, ни по объему кодирования)
Ну-у-у, это было Вам понятно, а я как-то упустил этот момент из виду :( А выгоду давало. Потому что изначально алгоритм был заточен именно на это.

18-я веснаЯ бы делал так: рядом с битовым полем в таблице БД заводится поле для цвета, которое заполняется при изменении битового поля и всегда находится с ним в согласованном состоянии.

В этом случае на код по расчету цвета не накладывается ограничение по скорости работы, и в нем можно использовать все возможности PowerScript такие как методы и константы, что существенно улучшает качество кода.
Такой способ не фонтанирует радостью. Во-первых лишнее поле в таблице, имеющей десятки миллионов значений. На шо воно? Во-вторых, условия достоверности это такая штука, которая может время от времени меняться. Пусть не часто, пусть раз в год (поначалу чаще)... Проще изменить ПЛ/СКуЛ в части выборки цвета :)
Опять же. Следующий шаг - давать юзеру возможность выбирать цвета для разных критериев. Не апдейтить же таблицу в самом деле... Вобщем, не вижу плюшек от хранения этой вещи в таблице на сервере. Кроме улучшения качества кода PowerScript :) Зато ухудшаются всякие там качества связанные с разработкой модели БД ИМХО...

18-я веснаVadim RomanenkoТакой способ не фонтанирует радостью. Во-первых лишнее поле в таблице, имеющей десятки миллионов значений. На шо воно? Во-вторых, условия достоверности это такая штука, которая может время от времени меняться. Пусть не часто, пусть раз в год (поначалу чаще)... Проще изменить ПЛ/СКуЛ в части выборки цвета :)
Опять же. Следующий шаг - давать юзеру возможность выбирать цвета для разных критериев. Не апдейтить же таблицу в самом деле... Вобщем, не вижу плюшек от хранения этой вещи в таблице на сервере. Кроме улучшения качества кода PowerScript :) Зато ухудшаются всякие там качества связанные с разработкой модели БД ИМХО...
Единственное с чем согласен, что недостаток - это обновление большого числа записей при изменении условий вывода цвета из битов.
Все остальное решается:
- хранится не цвет, а индекс, по которому из настроек пользователя берется цвет
- если так важно место на диске, поле можно не создавать, а использовать незанятые биты в битовом поле

Тоже вариант :)
И действительно единственный недостаток - избыточность.. Вот.
Вобщем, способ имеет право на жисть :)

maxATCVadim Romanenko
Работал над одним проектом (дорабатывал), что то похожее надо было выполнить с изменением цвета на основании нескольких вариантов. Что сделал: таблицу колор с полями показатель , цвет , из пользовательской таблицы посредством выборки Distinct показатель вставил в табл. колор , и сгенерил цвета на основании показатель . Ну и далее
Не факт, что приемлемо для тебя, но как вариант.

Для меня приемлемо боль-мень, за тем только исключением, что логику написал в хранимой процедуре вместо таблицы - как уже писАлось выше, перечислить ВСЕ варианты перестановок 20 бит... Засверлиться можно, да и не нужно :)
Проблема была в том, что хотелось обойтись ВООБЩЕ без дополнительного поля ;)