Здравствуйте.
Имеется журнал, тип: обычный. В состав входят 2 документа (Возврат и АктПриема).

При выполнении:

ПоставщикДанных = СоздатьОбъект("ПоставщикДанных");
	ПоставщикДанных.ТипЗначений = "Журнал.Возврат"; 

Появляются ошибки, вот первая:
ПоставщикДанных.Журнал::УстановитьПоставщикаДанных() : Meta name parser: неизвестное метаимя или алиас "$ДокАктПриема"

Сейчас сам пока разбираюсь. С журналами где в составе один документ -- все тип-топ, но с 2 и более -- ошибки.

Спасибо за быстрый ответ!
Скорее косяк в журнале.
ПоставщикДанных.Журнал::УстановитьПоставщикаДанных() : Meta name parser: неизвестное метаимя или алиас "$ДокАктПриема"
Не нравится ПоставщикуДанных ДокАктПриема.

Подключил аналогичный журнал с большим составом документов -- все работает.

Цитата:


Все графы отбора определены. Создал аналогичный журнал, с теми же графами отбора. Блин -- все работает.   

Выложена новая версия:
3.03.005 от 12.12.09 г.
- Объект «ПоставщикДанных.ПрямойЗапрос» обновлен до версии 1.05.002 от 07.12.09 г.
- Исправлена ошибка при получении списка значений поставщика данных «СписокЗначений». Не правильно проставлялись пометки в списке.
- Исправлена ошибка при подготовке запроса объекта «ПоставщикДанных.Журнал» при условии что в него входят документ у которых идентификатор входит в идентификатор другого документа данного журнала. Например: Счет, СчетФактураВыданный.
- Исправлена ошибка при построении строки сортировки у объекта «ПоставщикДанных.Регистр»

JohnyDeath писал(а) 16. Декабря 2009 :: 14:22:

Хорошее предложение по поводу автосоздания колонок. Только вот АвтоСозданиеКолонок как признак мне не очень нравится.

А вот такой вариант:
JohnyDeath писал(а) 16. Декабря 2009 :: 14:22:

пне нравится даже больше. Более того я бы сказал что это очень заманчивый вариант. Поскольку открываются большие горизонты по перекладыванию пользовательского кода на классы. Например:
реализация параметра ПрямойЗапрос, в поставщике ИТЗ который может принимать объект ПрямойЗапрос, с которым работает программист. И соответственно создание таблицы по тому результату что дает данный класс. Типизацию колонок поставщика и их создание можно переложить на класс. Т.о. можно избавиться вообще от всех проблем разом, которые ты описал в том сообщении.
Например:

ПоставщикДанных = СоздатьОбъект("ПоставщикДанных");
ПоставщикДанных.ТипЗначений = "ИндексированнаяТаблица";
и т.д.
Данные = ПоставщикДанных.Данные;
ПрямойЗапрос = СоздатьОбъект("ПрямойЗапрос");
ПрямойЗапрос.Текст = "select * from Справочник.Контрагенты";
Данные.ПрямойЗапрос = ПрямойЗапрос;
Данные.ЗаполнитьИзЗапроса(); 

При этом если сам КОП найдет соответствие ИДКолонки - Типизация то он типизирует колонки, если нет, то их тип = Неопределенный.

Вот эта идея мне нравится.
Кстати если начало 10-го года будет реализация пользователи 1С 7.7 еще останутся?  

Пы.сы. ПрямойЗапрос как атрибут можно не реализовывать, а сделать просто его параметром метода. Причем параметром можно сделать как объект Запрос (1С) так и ПрямойЗапрос (КОП).

vandalsvq писал(а) 16. Декабря 2009 :: 15:24:

Перечитал несколько раз. Не дошло.

JohnyDeath писал(а) 16. Декабря 2009 :: 15:29:

1. Я буду 3-мя руками и 5-ю ногами против зависимости поставщика от прямого запроса . Модульность должна быть. Избежать на 100% этого не получиться. Но как я писал, если сделать объект-источник - параметром метода, то зависимость уменьшается в разы. А при желании можно допилить до получения объекта ODBC, 1sqlite, Запрос и ПрямойЗапрос.
2. Про проблемы с типизацией - это я про параметры метода НоваяКолонка, там ведь есть ТипВид, Длина, Точность, и эти параметры отвечают за редактирование табличного поля. И про проблему типизации, я говорил именно эту. А не типизацию результата запроса
3. А про 10-й год, в смысле на дворе НГ. Вот в каникулы и намечен релиз %). Если все сложится... держим пальцы крестиком

В твоем случае пользовательского кода на 2 строчки больше 
Но твой вариант более универсальный и не надо нести большую ответственность в твоем классе за разные типы ПрямыхЗапросов (да и потяжелее это будет)