Какие есть варианты добавить Табличную часть на форму справочника.
с 1С++ не работаю.
Может есть какой обходной способ?

(P.S. конкретно задача
- в Спр.Номенклатура есть поле Спр.ТипТовара;
- у Спр.ТипТовара есть подчиненный Спр.НаборХарактеристик;
- У Спр.НаборХарактеристик есть подчиненный Спр.Характеристики.
...Требуется получить в карточке Номенклатура при выборе ТипаТовара определенный НаборХарактеристик для заполнения Характеристиками.
Пример:
Товар "Велосипед Merida TFS 100"
- входим в карточку товара;
- выбираем ТипТовара = "Велосипед";
- в требуемой Табличной части заполняются соответствующие НаборыХарактеристик (рама, вилка, тормоза и т.д.);
- остается заполнить Характеристики для конкретного НаборХарактеристик (рама=А, вилка=RS, тормоза=Shimano и т.д.);
- ну и запомнить все это для конкретного товара.

Вариант а. ТЗ на форме
Вариант б. ТП на форме

А чё пример такой беспонтовый? хотя бы 500-ю надо было :)

А по теме - конечно ТЗ. Хотя ТП удобнее, но нет - так нет.

(0) ещё один подчиненный справочник "Номенклатуре", в котором поля "Характеристика" и "Значение";
открытие через кнопку в пределах подчинения либо создавать ТЗ на форме ПриОткрытии() и доваблять, изменять, удалять кнопками
также в справочник "Характеристики" в отдельном поле можно задать маску для ввода значений, а особо продвинутым - механизм типизации значения

+(3) в 8.2 - это планы видов характеристик - почитай - может поможет разобраться в механизме)

Как вариант, подчиненный справочник характеристик.
формексом присоединить форму подчиненного к форме основного.

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

(5) не, это сложно и визуально не очень. Я как-то игрался, в итоге бросили эту затею.

(3) Не вариант. Представь, надо базу набивать с сотнями (а то и тысячами) позиций. А эти подчинённые формы в 1С имеют дурную привычку самостоятельно выбирать себе родителя. Там такого назаносят... Да и нажимать каждый раз на кнопку - это утомительно.

(8) активизация при открытии в жесткой иерархии здесь тебе поможет)

(9) Ничё не понял, ну да ладно...
Всё-же лучше когда вся информация вводится в одном месте. Есть такое понятие usability, и  им не надо пренебрегать. Делать надо не как программисту проще, а как удобнее пользователю, и не важно сколько гемора это доставит программисту.

+(9) в Номенклатуре ПриОткрытии() - открыть форму подчиненного справочника - через контекст передать родителя
там же ПриЗакрытии() - переоткрыть форму справочника с пустым контекстом
В подчиненном ПриОткрытии() - ИерархическийСписок(1,0), а в ПриПовторномОткрытии():

Если ПустоеЗначение(Форма.Параметр) = 1 Тогда
   Форма.Закрыть(0);
КонецЕсли;

Если это не устраивает - я тогда пас

(10) если через ТЗ бушь делать - не забудь Формекс подключить - для её растягивания соразмерно форме)

(11) ага, понял
но вот недавно был случай: пришла девочка в торговую компанию, на достаточно ответственную должность, в т.ч. ценообразованием заниматься. Ну и сидит она, вникает пока что. В частности, сравнивает цены на похожие товары. А там ТиС, и цены как раз так вот открываются. Через полчаса такой работы у неё сносит башню просто :)  Пришлось быстренько сделать им в номенклатуре закладку "Цены". Что интересно, все сказали "блин, как же мы раньше-то работали?!!"

(0)
Подчиненный спр для хранения
ТЗ на форме - для редактирования
Но правильные пацаны юзают табличное поле из 1С++

юзабельность выше на 95%

(15) Это при условии что цены обновляют вовремя. Цена в документе <> справочник цен.

Для хранения значений (Товар+Характеристика->Значение) не обязательно использовать подчинённый справочник.
Если нам не нужен отбор по характеристикам определённого товара, то можно просто использовать отдельный справочник, где поле Товар будет основным (первым, а код и наименование - в топку) и по нему же будет осуществляться отбор, а характеристика и значение - будут просто полями (конечно, можно значение сделать "отбираемым", если кто-то захочет искать по значению).
Что мы получаем, отказавшись от подчинённости - мы получаем отдельную форму, которая никак не привязывается к форме справочника владельца, то есть никто из-вне никак не повлияет на эту форму и не сможет её открыть методом "открыть подчинённый".
Теперь нужно сделать "ИспользоватьСписокЭлементов" и пририсовать на форму списка поле для выбора товара (или отображение его). Получаем видоизменённую форму для редактирования характеристик товара с растяжением таблицы и отслеживанием внешних изменений без танцев и бубна.
Также можно этот справочник сделать подчинённым справочнику "ТипыТовара", чтобы можно было отбирать по определённому значению характеристики для определённого типа товара.

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

(17) это для любящих вырезать гланды через задницу - при установленом отборе возникает проблема ввода нового элемента - - снимать отбо нужно - делать для ентого кнопку - ну не знам ...

сложно изучить ТП в 1С++?

(20)Используй лучше не ТП, а класс ПоставщикДанных (по сути, он наследник от ТП).
если знаешь снеговика - освоищь без проблем. Если не знаешь, но освоищь - легче со снеговиком будет..

+(21) вообще, работает как правило, совсем без проблем.
Хорошая документация в комплекте, а примеры - на форуме

(20) Ну, дня два потратишь на это, как минимум, скорее недельку. Но оно того стоит. И к ТП надо бы привязки ещё, а то не интересно.

(17) Как хранить - дело вообще десятое. Способов множество, и все в общем то равнозначны. Главное то дело именно что в интерфейсе.

(18) Я предлагаю, по крайней мере, избавится от кнопки "Открыть подчинённый справочник", которая чаще всего мешает пользователям успешно вводить данные.
Ну не подумали в 1С, когда делали реализацию подчинённого справочника через связку двух форм - если в одной поменять позицию выделенного элемента, то в другой тоже происходят изменения - на самом деле - это грубое нарушение правил интерфейса Windows, когда одно дочернее окно оказывает влияние на другое дочернее равноправное ему окно.

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

(25) Насколько я понимаю, в (0) обычный справочник характеристик товара для интернет-магазина, где каждому товару можно поставить набор некоторых описаний, представляющих собой соответствие Имя->Значение.
Причём, значение пока предполагается вида сферического коня в вакууме, так как никто не думал, что там могут быть строки произвольной длины или ссылки на объекты базы.

а кто-нить уже предложил перейти на снеговика? там ведь реализовано :)

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

(28) так и в снеговике это сделано так же. Просто управляется средствами платформы.

(29) Там его тоже надо доделывать, так как напрямую в регистр писать не будешь, а для табличной части справочника нужно писать фильтр выбора типа характеристики в зависимости от ТипТовара

(29) как ни называй отношение "один ко многим" оно от этого не изменится.
(27) а снеговик ваш - отстой. Там не то что шаг - полшажка в строну - и сразу расстрел.

(31) вот так вот))))) под стволом получается ходим)))