Всем привет.
В Bex можно достать структуру настроек запроса. Нашел на форуме информацию как это сделать. Вот ссылка на обсуждение: http://sapboard.ru/forum/viewtopic.php? ... et#p455941. Достал XML структуру. Но там внутри узлов, допустим,
<T_DATAPROVIDER>
<RSR_SX_DATAPROVIDER>
<NAME>DP_1</NAME>
<REQUEST>
<DIM>
<RRX_XLS_DIM>
<IOBJNM></IOBJNM>
очень много тегов с настройками самого признака и т.п. Нигде не нашел описания какой тег для чего предназначен. Описания нет. Интуитивно понял кое-что про некоторые из них, но этого мало. Хотелось бы понимать, что в полученном XML содержится. Может кто обладает какой-либо информацией?

Не претендуя на истину хотел сказать, что (по своему опыту "ковыряния" этого XML) на мой взгляд он содержит в себе настройки отображения (представления вывода) запросов в рабочей книге на момент ее сохранения. ИМХО

Спасибо, за скорый ответ.
Т.е. как в настройках самого запроса задали, так и будет? Т.е. о чем я. Суть в том, что нужен универсальный алгоритм "склейки" текстов признака. Для этого необходимо понимать позицию признака в запросе. Вроде я видел там и оси X и Y, и тег <POSIT>, где позиция признака на оси. Только вот, если вдруг пользователь изменит развертку запроса средствами навигации, то ничего не меняется. Допустим, добавили в развертку впереди признака (который меня интересует) еще один признак. При этом, смотрю, а в XML нифига не меняется и позиция признака (интересующего), все также имеет ту же позицию в теге <POSIT>. Т.е. значения позиция признака жестко из настроек самого QUERY берется?

Я бы сказал, что берется значение на момент сохранения книги, т.е. если Вы измените позицию признака в запросе (именно его представление в книге, от его позиции в QD оно может отличаться) и сохраните книгу, то это значение и будет храниться в XML.
А текущее (не сохраненное) состояние запроса в книге можно попробовать считать через Bex-объект (BexApplication). Вот только делать это можно на свой страх и риск, ибо с любым новым патчем (как на FrontEnd, так и на BackEnd) есть вероятность того, что свойства и методы, которые Вы будете использовать, изменяться.

Длинные тексты лучше реализовать заменой.
Например, делаете текст значения признака такой: \\\\00894
Проходите все ячейки запроса и если значение начинается с четырех слешей, то ищете число на другом листе и заменяете значение ячейки текстом с другого листа.
На другом листе запрос над основными данными, который может использовать текущий запрос как преквери, чтобы поменьше основных данных выводить.

Десять строк VBA-кода и всё.

Всем, кто остался неравнодушным к моей проблеме , СПАСИБО. Попробую оба варианта.

А с BexRepositorySheet только один sript можно считать? Т.е. тот, который содержит настройки запроса (больше ничего не нашел )? Я к чему интересуюсь. Может есть какой-нибудь супер-супер скрытый лист или скрипт, в котором фиксируются изменения запроса? В голове сидит мысль о том, что в момент изменений наверняка же где то выполняется анализ изменений. И на важно сохранена книга или нет. Наверняка же как то можно отловить, как Bex перерисовывает лист с учетом изменений(например изменение развертки запроса). Но вот как отловить непонятно. Может есть у кого какие идеи на этот счет? Может есть дополнительные XML или может быть есть какие-то другие Bex-овские методы, позволяющие сделать это. Типа, которые в VBA в модуле xBEXapi. Может методов больше, нежели в модуле?

А цель какая?

мне нужно склеить тексты признаков. При этом нужен алгортим, который не будет статичным, т.е. не должно быть привязки к координатам, т.е. пользователь, который будет работать с отчетом, будет иметь возможность менять развертку, добавляя или удаляя какие-либо аналитики. Поэтому хочу понимать, как можно определить координаты признаков в несохраненной книге, если пользователь выполнил выше указанные изменения. И я полагаю, что Bex где-то фиксирует выполненные изменения, но где...это болшой вопрос! Информации не нашел на этот счет. Выше в сообщениях есть информация о том, как можно выяснить структуру запроса СОХРАНЕННОЙ КНИГИ (формат XML). Но там не фиксируются изменения пока книгу не пересохранить. Потом, пожалуйста. Но мне этот вариант не подходит.

Да. Сразу хочу заметить, что вариант:

"Длинные тексты лучше реализовать заменой. Например, делаете текст значения признака такой: \\\\00894"

мне не подходит тоже, потому как в самом запросе будут именно такие тексты, а мне этого не нужно, т.е. пользователь будет сам строить запрос в Bex и естественно будет видеть такое текст в нем. Будет много вопросов, а зачем и почему!

Пользователь этого не увидит. Замена будет производится в CallBack до того, как данные будут показаны пользователю.
Единственный возможный вопрос от пользователя -- лаг в секунд в 10 на больших объемах данных.

Я понимаю, что разобраться в кишках BEx -- круто. Но с длинными текстами вопрос решается не так уж и затейливо.

ну да, я в таком русле не подумал что то . Спасибо. Попробую.

Вот, для примера, реализация поиска из моих наработок:

Если к условиям поиска получится прикрутить стиль ячеек -- скорость работы возрастет.

Может не составит труда скинуть все наработки (или вообще всю реализацию на VBA) по этому вопросу? . Любопытно посмотреть на работу спеца, коим чувствуется вы являетесь. Если, конечно, не сочтете это за наглость)))

Для 7.Х я еще длинные тексты не делал, и всё что похожее было -- уже скинул (оно достаточно ценно, т.к. поиск обычным циклом слишком ресурсоёмок).
Делал для 3.Х но это было давно и исходников найти не смог. Поскребу по сусекам ещё. Допишу в это сообщение.