Нарушение полосатости грида при 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]

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

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

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

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

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

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

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

← →
kyn66 © (2009-09-04 11:57) [31]

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

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

← →
Anatoly Podgoretsky © (2009-09-04 12:27) [32]

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

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

← →
kyn66 © (2009-09-04 12:51) [33]

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

← →
Anatoly Podgoretsky © (2009-09-04 13:21) [34]

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

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

← →
Сергей М. © (2009-09-04 14:25) [35]

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

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

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

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

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

← →
kyn66 © (2009-09-04 15:10) [37]

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

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

← →
Anatoly Podgoretsky © (2009-09-04 15:25) [38]

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

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

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

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

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

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

← →
kyn66 © (2009-09-04 15:33) [40]

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

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

← →
Сергей М. © (2009-09-04 15:48) [41]

СУБД-то какая ?
К 40-му посту можно было бы сподобиться и открыть наконец тайну)

← →
Anatoly Podgoretsky © (2009-09-04 15:58) [42]

> когда мы в чистый TTable перегоняем заранее отсортированные
> квериком данные и не применять к нему ничего (фильтр, сортировка),
> просто вывести в гриде и все. И RecNo будет в поряде.

Никогда не будет в порядке. Особенно с абстрактным форматом.

← →
kyn66 © (2009-09-04 16:05) [43]

> СУБД-то какая ?

Так в [1] было описано про TADSQuery, сопсна ADS.

> Никогда не будет в порядке.

Что-ж так категорично? Ведь при формировании нового набора и записи с нуля начинают формироваться.

> kyn66 (04.09.2009 16:05:43) [43]

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

2Anatoly Podgoretsky

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

> kyn66 (04.09.2009 16:41:45) [45]

Нельзя найти кошку в темной комнате, если ее там нет.

Не понимаю, в чем проблема?

procedure TForm1.DBGrid1DrawColumnCell(Sender: TObject; const Rect: TRect; DataCol: Integer; Column: TColumn; State: TGridDrawState); begin if ([gdSelected, gdFixed] * State = []) and Odd(DBGrid1.MouseCoord(Rect.Left, Rect.Top).Y) then with DBGrid1, Canvas do begin Brush.Color := clYellow; FillRect(Rect); DefaultDrawDataCell(Rect, Column.Field, State); end end;

И даже FillRect можно убрать. Само закрасится.

Удалено модератором

которые уже и не FAQ, а сверхFAQ

>Юрий Зотов © (05.09.09 13:32) [47]
>Не понимаю, в чем проблема?

Насколько я понял, автору нужно, чтобы каждая запись датасета имела что-то вроде св-ва "чет-нечет", в соответствии с которым ее нужно отображать в сетке "своим" цветом. Т.е. запись с №=17 ВСЕГДА была окрашена как "нечет" вне зависимости в какой (четной или нечетной) строке сетки она отображалась. Что при этом будет с "полосатостью" в случае, если НД будет переупорядочен на клиенте или, как несколько раз повторил АП, отфильтрован, очевидно для всех, кроме автора.

Вообще не понимаю откуда возникла подобная трабла.

О, я придумал! пусть будет так, как делает автор, но не чет-нечет, а в порядке радуги. Тогда, после отображения с каким-либо условием, мы получим дополнительную яркую цветовую информацию этого условия.

Насколько я понял, автору нужно, чтобы каждая запись датасета имела что-то вроде св-ва "чет-нечет", в соответствии с которым ее нужно отображать в сетке "своим" цветом.

Неа. Удаляем "эту" запись, а ее соседи остаются четными/нечетными.
Получаем две соседние записи одного цвета.
Полосатость пропадает.

>Медвежонок Пятачок © (07.09.09 13:45) [54]

Речь не шла об удалении вообще-то. А по поводу перемешивания или пропадания записей из сетки в том же посте имеется второе предложение. Его не читаем ?

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

> Неа. Удаляем "эту" запись, а ее соседи остаются четными/нечетными.
> Получаем две соседние записи одного цвета.Полосатость пропадает.
>

Совершенно верно

> Речь не шла об удалении вообще-то. А по поводу перемешивания
> или пропадания записей

За счет удаления происходят те-же нарушения.

Все заморочки по поводу четности-нечетности имеют место быть, если использовался метод Background := BackColors[(Sender as TDBGridEh).DataSource.DataSet.RecNo mod 2 <> 0]; Но с этим решено было покончить, т.к. у датасета имеется своя способность разукрашивать фон в полосатый. Вот здесь и пытаюсь понять почему он не срабатывает. Что на это влияет.?

> Насколько я понял, автору нужно, чтобы каждая запись датасета
> имела что-то вроде св-ва "чет-нечет",

Совершенно не нужно. Нужно чтобы компонент отрабатывал то, что в нем предписано

>kyn66 © (07.09.09 16:39) [58]
>> Насколько я понял, автору нужно, чтобы каждая запись датасета
>> имела что-то вроде св-ва "чет-нечет",
>Совершенно не нужно. Нужно чтобы компонент отрабатывал то, что в нем >предписано

Тогда извольтк изъясняться внятно и понятно, что же Вам требуется. При этом некисло было бы узнать о том, что Вы понимаете под таинственной фразой "Нужно чтобы компонент отрабатывал то, что в нем предписано"

> т.к. у датасета имеется своя способность разукрашивать фон
> в полосатый.

Это какая же?

> Тогда извольтк изъясняться внятно и понятно, что же Вам
> требуется.

[5]

> "Нужно чтобы компонент отрабатывал то, что в нем предписано"

[20]

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