Нарушение полосатости грида при SQL-запросах

← →
kyn66 © (2009-09-02 13:46) [0]

Добрый день. Когда то я здесь задавал вопрос по теме САБЖ. Решение вопроса так и небыло достигнуто. Сейчас я всетаки обнаружил ответ на этот вопрос и с радостью хочу поделиться со всеми, кто сталкивался с такой проблемой. Исходные данные:
TDBGridEx, TAdsQuery Во время формирования запроса и сортировки по одному из полей, порядок следования цветных полос сбивался, когда я использовал вот это:
procedure TMainFrm.DBGridEh1GetCellParams(Sender: TObject; Column: TColumnEh; AFont: TFont; var Background: TColor; State: TGridDrawState); begin ... Const BackColors : array[Boolean] of TColor = (clWhite, clBtnFace); ... Background := BackColors[(Sender as TDBGridEh).DataSource.DataSet.RecNo mod 2 <> 0]; end;

Затем этот способ представления полосатости был заменен использование свойств самого TAdsQuery Sequenced. Но и после этого картина не изменилась! Сегодня я случайно обратил внимание еще на одно свойство SecuencedLevel и решил его проверить. Когда оно было по умолчанию slStandard - ничего не менялось. Но стоило мне его изменить на slExact - все заработало как нужно!!! "Полосатость" восстановилась при любых забросах. Так что, если кому это пригодится - запоминайте!

← →
kyn66 © (2009-09-03 10:18) [1]

Не успел нарадоваться успеху, как обнаружил, что в аналогичной программе, с почти одинаковым запросом картина осталась прежней, нормальное чередование полос нарушено. :(. Я уже и не знаю на что думать. Хотя в комплекте ADS есть утилита Arc32? посредством которой можно управлять данными. ТАк вот в ней при любых запросах чередование никогда не нарушается.

← →
Медвежонок Пятачок © (2009-09-03 11:18) [2]

Про DataSet.RecNo тебе уже говорили.

← →
kyn66 © (2009-09-03 11:19) [3]

ДА, но в первом случае SecuencedLevel помогло исправить ситуацию

← →
Медвежонок Пятачок © (2009-09-03 11:28) [4]

и чего?
у тебя вычисления идут на основе четности рекно
а посмотреть чему оно реально равно ты не догадался

← →
kyn66 © (2009-09-03 11:35) [5]

> у тебя вычисления идут на основе четности рекноа посмотреть
> чему оно реально равно ты не догадался

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

← →
Медвежонок Пятачок © (2009-09-03 11:40) [6]

а это что такое?

Background := BackColors[(Sender as TDBGridEh).DataSource.DataSet.RecNo mod 2 <> 0];

← →
Медвежонок Пятачок © (2009-09-03 11:43) [7]

Мусолить можно сколько угодно.
Только закон джунглей русским по белому говорит:

Description

As implemented in TDataSet, the value of RecNo is always -1. Ordinarily an application does not access RecNo at the TDataSet level. Instead a re-implemented RecNo property in a descendant class such as TTable is accessed. RecNo provides a fallback property for derived datasets that do not support record numbers.

← →
kyn66 © (2009-09-03 12:00) [8]

Внимательно читать продолжение поста нужно
Затем этот способ представления полосатости был заменен использование свойств самого TAdsQuery Sequenced.

И было уже проверено, данные выводились как положено. А когда попробывал применить ко второй проге - там произошел обломс

← →
Медвежонок Пятачок © (2009-09-03 12:19) [9]

так и дальше будет, если ориетнироваться на датасет, а не на строки кастомгрида

← →
kyn66 © (2009-09-03 12:52) [10]

> так и дальше будет, если ориетнироваться на датасет, а не
> на строки кастомгрида

Не совсем понятен ответ. Ситуация применения и там и там одинакова. Я уже начал думать про наличие типов полей датасета

← →
Медвежонок Пятачок © (2009-09-03 12:59) [11]

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

← →
kyn66 © (2009-09-03 15:11) [12]

> так как строки в гриде есть и у них точно есть порядковые
> номера сверху вниз (речь про элементы самого грида)

И каким образом это сделать? На какое событие опираться? Я использовал оба способа. Лично я так думаю. Примером можно показать , как будет правильно?

← →
Медвежонок Пятачок © (2009-09-03 16:04) [13]

пример лежит в TCustomDBGridEh.DrawCell

← →
kyn66 © (2009-09-03 16:33) [14]

> пример лежит в TCustomDBGridEh.DrawCell

Спасибо за поучительный совет.

← →
Медвежонок Пятачок © (2009-09-03 16:43) [15]

Совет был с самого начала использовать OddRowColor и EvenRowColor

← →
kyn66 © (2009-09-03 16:51) [16]

> Совет был с самого начала использовать OddRowColor и EvenRowColor

Что это такое? Не нахошу таких определений в модулях Delphi

← →
kyn66 © (2009-09-03 16:53) [17]

Пардон, нашел в свойсвах DBGridEx. НУ и дальше то что, что я там укажу свои цвета. Толку с этого? Каким образом строками управлять?

← →
Медвежонок Пятачок © (2009-09-03 17:32) [18]

> пример лежит в TCustomDBGridEh.DrawCell

← →
Сергей М. © (2009-09-03 17:34) [19]

> Толку с этого? Каким образом строками управлять?

Что значит "строками управлять" ?
Какое еще "управление" тебе нужно для реализации "полосатости", если достаточно установкой св-ва EvenRowColor сказать тем самым гриду "Крась четные строки в такой-то цвет !", а установкой OddRowColor - "А нечетный в такой-то другой цвет !"
А уж как он там будет высчитывать четные и нечетные - это не твоя забота.

Ты чего такой трудный ?)

← →
kyn66 © (2009-09-04 09:36) [20]

Если на то пошло, то цвета там стоят по умолчанию, допустим не важно какие, главное что разные. Эти цвета будут задействованы в том случае, если включено свойство Sequenced.

> А уж как он там будет высчитывать четные и нечетные - это
> не твоя забота.

ТАк как-же он всеже будет вычислять, почему не вычисляет? Почему не полосатирует?

> Ты чего такой трудный ?)

ЗАчем так сказаль плохо? Вот она теоретическая версия http://yurec66.narod.ru/Vopros/qver1.jpg , а вот что на практике получается http://yurec66.narod.ru/Vopros/qver2.jpg
НУ и при чем тут трудность? Какие еще данные нужно предоставить, чтобы решить, почему он всетаки не рисует полосы чередованием?

← →
Anatoly Podgoretsky © (2009-09-04 10:00) [21]

> kyn66 (04.09.2009 09:36:20) [20]

Всеобщую волосатость грида достигнуть трудно, практически невозможно, поэтому все примеры, реализуют только частичную.

← →
Сергей М. © (2009-09-04 10:32) [22]

> почему он всетаки не рисует полосы чередованием?

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

← →
kyn66 © (2009-09-04 10:57) [23]

> правильная волосатость

Решь шла о полосатости
> поэтому все примеры, реализуют только частичную.

Т.е. нужно смириться с тем, что хоть это делает?

> Если гриду эта информация по тем или иным причина недоступна,
> красить он будет как попало.

Все очень доходчиво. Т.е. не будем от него требовать невозможного, хотя кто знает, может авторы пересмотрят этот вопрос. Мучает одна непонятка... Почему же тогда в утилите Arc32? написанной на базе в том числе этих-же компонентов полосатость всегда четкая. Я сознательно в SQL-buildere ввел такой-же запрос... все отработало нормально. ЛАдно, выходит тему можно считать закрытой, но до конца не раскрытой. Всем спасибо за участие в дебатах.

← →
Anatoly Podgoretsky © (2009-09-04 11:11) [24]

> Сергей М. (04.09.2009 10:32:22) [22]

Дополнение, номера записей должны быть логическими, а не физическими.

← →
Anatoly Podgoretsky © (2009-09-04 11:12) [25]

> Сергей М. (04.09.2009 10:32:22) [22]

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

← →
Сергей М. © (2009-09-04 11:16) [26]

> в SQL-buildere ввел такой-же запрос... все отработало нормально

Значит SQL-builder окрыл НД с клиентским курсором, сходил в его конец, вернулся назад в начало, при этом получил актуальное значение RecordCount. А дальше все объяснимо с простотой пареной репы)

← →
Сергей М. © (2009-09-04 11:16) [27]

> Anatoly Podgoretsky

Ну это подразумевалось)

← →
Медвежонок Пятачок © (2009-09-04 11:23) [28]

а все потому, что кто-то не будем говорить кто поленился сделать паблик свойство "номер строки в гриде"

> kyn66 (04.09.2009 10:57:23) [23]

Я бы не смирился, я бы просто убил.

> Сергей М. (04.09.2009 11:16:27) [27]

Ну не все же телепаты и в итоге возникает нарушение и его непонимание.

> сходил в его конец, вернулся назад в начало, при этом получил
> актуальное значение RecordCount

А не много манипуляций? А если число записей будет очень много? Долгого зависа не получится?

> kyn66 (04.09.2009 11:57:31) [31]

А это другая проблема, не относящая к полосатости, тут уж чем-то надо жертвовать.

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

> kyn66 (04.09.2009 12:51:33) [33]

Может быть все таки на недопонимание сущности?

> А если число записей будет очень много?

Да без разницы сколько - это самое "много" в любом случае надо знать.

> Может быть все таки на недопонимание сущности?

Уже недопонимание цитаты. По новой начнем обсуждать?

> это самое "много" в любом случае надо знать.

Получается, что после того как кверик с запросом отработает, я в цикле должен перегнать полученные данные в новый TTable(к примеру) и уж только его привязывать к гриду. Тут -то тогда будет все пучком, все записи будут упорядочены по порядку. Это называется в обход огородами :)

> kyn66 (04.09.2009 15:10:37) [37]

Это только тебе кажется, что все будет в порядке, на самом деле это ситуации не меняет.

> я в цикле должен перегнать полученные данные в новый TTable(к
> примеру)

Хоть перегоняй хоть не перегоняй, но "много" так или иначе должно быть известно. Именно от него пляшет свойство дейтасета RecNo.

Ну ты сам подумай - откуда произвольный компонент-дейтасет возьмет значение RecNo для любой записи, кроме первой, если ему неизвестно, сколько всего записей в откытом им НД ?

> на самом деле это ситуации не меняет

НУ почему? Не буду сильно настаивать, но мне кажется, когда мы в чистый TTable перегоняем заранее отсортированные квериком данные и не применять к нему ничего (фильтр, сортировка), просто вывести в гриде и все. И RecNo будет в поряде. Для промежуточных отображений я к примеру часто использую TrxMemoryData.

Нарушение полосатости грида при SQL-запросах Найти похожие ветки