query grid

[ald]

На форме есть button и grid. По клику выполняю следующий код

void clicked()
{

Query q = new Query();
QueryBuildDataSource qbDS;
QueryRun MyQueryRun;
QueryBuildRange range;
;
super();
qbDS = q.addDataSource(tablenum(CD_BRAND));
MyQueryRun = new QueryRun(q);
box::info(int2str(SysQuery::countTotal(MyQueryRun)));
CD_BRAND_ds.query(q);
CD_BRAND_ds.executeQuery();
Grid.dataSource(CD_BRAND_ds);
}


Что я делаю неправильно для того что бы отобразились данные из таблицы CD_BRAND в gride? Кол-во записей правильное соответствует кол-ву в таблице.

[Berty Wooster]

Для того чтобы Grid отображал данные DataSource необходимо в свойствах Grid указать DataSource. И из DataSource на Grid добавить поля.

Для того что бы обновить данные в Grid,

PHP код:

void clicked()
{
     CD_BRAND_ds.executeQuery();
} 


Накладывать range и изменять query лучше внутри executeQuery();

[ald]

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

[ald]

Как на лету изменить DataSource и поля?

[dn]

Цитата:

Изначально опубликовано ald

PHP код:

Grid.dataSource(CD_BRAND_ds); 


Зачем ты устанавливаешь источник данных Grid`а в коде? Почему это не сделать при конструировании формы в AOT`е? А заодно и вынести нужные поля из источника данных на Grid.

[Berty Wooster]

Если на лету изменять DataSource у Grid, то надо изменять и у элементов на Grid DataSource и DataField. Но может быть вам тогда лучше использовать Table?

[mit]

Наверное будет проще создать форму на основе временной таблицы, и обовлять ее по кнопке

[RAks]

Привет, взгляни на SysTableBrowser...

[ald]

Использование нескольких классов в этом проекте мне не совсем понятно. Например xxCompiler. И вообще мне не нужно все так глобально. Есть определенное кол-во таблиц - 6 Их больше не будет. На форме надо отобразить содержимое одной из них в зависимости от параметров с которыми будет открываться форма. Все в общем-то просто.

[mazzy]

6 закладок, 6 гридов.
и не программируйте

[ald]

Над оригинальностью Ваших ответов действительно охото посмеятся!!!

[RAks]

Есть еще один вариант... пересмотреть ФД..... или БП.... критерий правильности - простота реализации....

[dn]

Цитата:

Изначально опубликовано ald
Использование нескольких классов в этом проекте мне не совсем понятно.

Посмотри в первую очередь класс SysTableBrowser метод run(). То что не нужно и не используй.

Цитата:

Есть определенное кол-во таблиц - 6 Их больше не будет. На форме надо отобразить содержимое одной из них в зависимости от параметров с которыми будет открываться форма. Все в общем-то просто.

Вообще, я почти готов согласится с Mazzy, сделай 6 гридов и не мучайся. Просто в зависимости от параметра скрывай ненужные.

[mazzy]

Цитата:

Изначально опубликовано ald
Над оригинальностью Ваших ответов действительно охото посмеятся!!!

долго думал перед тем как ответить.
не уверен, что ответ поможет вам. Но вдруг заставит задуматься других.
Извините, за сознательно резкий тон.

Итак, ald. Вы делаете динамическую форму, которая будет показывать 6 таблиц.
Я бы посоветовал вам следовать рекомендациям best practice и сделать 6 статических форм для каждой таблицы. Однако ж побоялся задеть ненароком и порекомендовал компромиссный вариант - одна форма с 6 закладками и 6 гридами. (И зря, кстати, побоялся)

Похоже вы таки хотите продолжать динамическое программирование.

Тогда подумайте вот о каких моментах работы пользователей:

• пользователь может настраивать порядок колонок в формах. Вы думали об этом, когда начали программировать?
• пользователь может настраивать внешний вид форм (скрывать и добавлять поля) при помощи кнопки настройка. Вы думали об этом когда начали программировать?
• пользователь может включать фильтры в любой форме. Вы думали об этом, когда начали программировать?
• пользователь по любой форме может получить автоотчет. Вы думали об этом, когда начали программировать?

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

Но уж о себе любимом программисте-администраторе вы наверняка подумали. Так ведь?

• Поля и таблицы могут физически включаться/выключаться при помощи конфигруационных ключей. Вы наверняка это предумотрели в своем суперкоде при программировании.
• В Аксапте есть горизонтальные фильтры - RLS. Вы наверняка это предусмотрели при построении query, не так ли?
• Доступ к полям и таблицам может быть ограничен security-ключами. Вы наверняка предумотрели вертикальное ограничение доступа. Программировали? А тестировали? А насчет прав доступа на форме на вычислимые поля думали? А тестировали?
• У вас одна форма, которая отображает разные данные. Вы знаете, что в Аксапте разным пользователям настроить разный доступ. Вы наверняка предусмотрели возможность когда один пользователь может посмотреть одну таблицу в вашей суперформе, а другой только другую. И наверняка это настраивается стандартными средствами.
• Вызвать вашу форму из другого места наверняка не составляет никакого труда... Как обычно вызываем созданный вами menuItem... А? нет? код надо писать? Args заполнять вручную... Не верю, что так сложно. Конечно же вы предусмотрели легкий вызов.
• В Аксапте есть функциональность dinalink. Это когда форма вызывается из другого места и показывает только связанные записи. Например, клиенты и заказы. Можно из клиентов вызвать форму с заказами. Тогда Аксапта сама покажет заказы только этого клиента. Специально программировать ничего не нужно. Но на вашей супер-перепрограммированной форме диналинк надо программировать руками. И вы конечно же это сделали. Правда ведь?
• и т.п.

Я правильно понимаю, что вместо того, чтобы накидать мышкой 6 форм или 6 закладок вы предпочитаете перехватывать у ядра и программировать руками перечисленный выше функционал?

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

К чему это я.
Не программируйте бездумно. Думайте, пожалуйста.

Как правило, когда программист начинает решать задачи динамического программирования, то он решает сугубо свои программисткие задачи, нафиг не нужные пользователям. Мало того, как правило, результат динамического программирования становится чуждым в системе. Пользователи и консультанты плюются и матюкаются когда встречают подобные программистские изыски.

ald, поверьте 90% сложностей и неочевиднгостей в Аксапте связаны с тем, что программист придумал свое программистское никому не нужное суперрешение.

Решайте задачи пользователей. Используйте статическое программирование. Постарайтесь вообще не программировать. Либо будтье готовы, что бюджет будет превышен в несколько раз (в Аксапте есть где развернуться программисту)

[dn]

Сергей, извини, не могу удержаться...

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

Цитата:

• пользователь может настраивать порядок колонок в формах.
• пользователь может настраивать внешний вид форм (скрывать и добавлять поля) при помощи кнопки настройка.

Не раз приходилось реализовывать запросы по отключению этих фитч в некоторых случаях.

Цитата:

• пользователь может включать фильтры в любой форме.

У пользователя останется эта возможность и в "динамической" форме, если использовать query.

Цитата:

• Поля и таблицы могут физически включаться/выключаться при помощи конфигруационных ключей. Вы наверняка это предумотрели в своем суперкоде при программировании.
• В Аксапте есть горизонтальные фильтры - RLS. Вы наверняка это предусмотрели при построении query, не так ли?
• Доступ к полям и таблицам может быть ограничен security-ключами. Вы наверняка предумотрели вертикальное ограничение доступа.

Аналогично, при использовании query это должно работать.

p.s. Я не сторонник бездумного программирования. Но не всегда разработчик может свести программирование к минимуму и не выходить за рамки стандартов. Иногда нужно действительно пересматривать ФД или БП, хотя и это не панацея...

[mazzy]

Цитата:

Изначально опубликовано dn
Думаю, что в этом конкретном случае ты скорее всего прав

Вполне может быть.

Я не против программирования вообще. Согласен, что иногда приходится программировать много. Но хотелось бы, чтобы ПЕРЕД этим думали, и чтобы решение программировать было осознано.

Цитата:

Изначально опубликовано dn
У пользователя останется эта возможность и в "динамической" форме, если использовать query.

Да. В общем случае. Но ты посмотри как строится query в исходном вопросе
В данном конкретном случае, похоже, вообще ни о чем не думали. Или просто не знали, что об этом можно думать.

Рядом вот говорили про то, что документации не хватает.
Но прочесть руководство разработчика и (хотя бы) best practice ведь можно?

Цитата:

Изначально опубликовано dn
p.s. Я не сторонник бездумного программирования. Но не всегда разработчик может свести программирование к минимуму и не выходить за рамки стандартов. Иногда нужно действительно пересматривать ФД или БП, хотя и это не панацея...

Согласен.

[ta_and]

Сергей просил думать о консультантах и о пользователях.
Целиком и полностью поддерживаю!!!
Хочу еще только добавить:
Думайте еще и о себе и о своих последователях-соратниках программистах!
Ваш код неразбери-поймешь динамической-супернаворочанной формы будет поддерживаться Вами или кем-то другим возможно еще долгое время.
Через пару месяцев я оооооччччень сомневаюсь о том, что Вы мгновенно вспомните, какие программистские решения используете сейчас!
И тем более другой программер будет с матами на устах разбирать Ваш ПРОЗРАЧНЫЙ УДОБНЫЙ и даже МЕСТАМИ ДОКУМЕНТИРОВАННЫЙ код. :))
Ахапта - многопользовательская среда.
Не только многоюзерская. Но еще и многопроггерская.
Принимая СТАНДАРТНЫЕ решения Вы облегчите себе и другим жизнь в будущем.
Возможно эти решения будут не совсем рациональными (в вашем сегодняшнем понимании). Но они будут СТАНДАРТНЫМИ. И тем самым снимется 90 процентов головной боли в будущем!
Лучше сделать 12 статичных форм, чем одну динамически формируемую.
Лучше сделать 20 статических отчетов вызываемых через один формирующий класс, чем супер-пупер навороченный отчет с динамически формируемыми столбцами, секциями и запросами....

Кидаю лозунг!
Изучайте Бест Практис!!!!
РТФМ, господа РТФМ и еще раз РТФМ. Тем более ее ТАК МАЛО....

ПС. Для непосвященных:
RTFM : Read The Following Manual
или
RTFM : Read The Fu....g Manual
Прочтите эту ....ую документацию!