ок. Попробуем пойти по пути 3.

Вопрос: в классе "Поленастройки" в процедуре "РазобратьПутьКДанным" используется понятие "родитель". Насколько я понимаю эта как раз та таблица к которой должен/может интегрироваться отбор (то о чем я писал несколькими постами выше).

Так вот, я предлагаю уйти от такого рода привязок, как раз чтобы отбор был более "самостоятельным".

Понятно написал?

Чтобы реализовать п.3 надо сейчас надо внести изменения в класс "ПолеНастройки". Дело не в пресловутом родителе или другом поле. Просто иначе надо малость реализовать подход.
Я хочу попробовать внести некоторые изменения сегодня в класс, так сказать положить начало п.1 тогда я смогу объяснить будущую стратегию как надо вносить изменения. Ну по крайней мере на мой взгляд.

vandalsvq писал(а) 27. Марта 2012 :: 04:27:

ПоставщикДанных.Версия = "4.3.1 30.12.2011"

конфа давно уже не типовая. и работает данный класс не с типовым объектом.
если нужно, могу выложить конфу с этими объектами.

так как же все таки отменить удаление элемента справочника?

При отключении иерархии и последующем включении открывается группа в которой были до переключения иерархии, а не та к которой относится текущий элемент списка.

Поставщик данных - справочник номенклатура с доп. полями остаток и резервов. Используется для подбора.

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

пожалуйста подскажите как исправить  - это важно

версия поставщика 1Cv7_ext_TF_008

То что я возьмусь счас доделывать - в прикрепленном изображении. Т.е. по сути это п.1 и п.2 из то что я говорил.
Вам (если есть желание) останется самое "вкусное" на закуску. Хотя честно признаюсь, я наврядли буду сам пользоваться когда либо более 1-го уровня вложенности.

Главное изменение - необязательность наличия имени в элементе или группе отбора. Главный объект - идентификатор (Guid). По нему происходит вся работа.
- Есть небольшой вопросик... как быть с предопределенными отборами?
Предлагаю реализовать так, как приведено на картинке. Т.е. в спец. группе "Предопределенные". Удалять ее нельзя будет, изменять можно. Все как сейчас только с нюансом что в специальной группе.
- Еще в форме будет перетаскивание между Табличными полями с добавлением в соотв. группу.
- Еще в объекте "Отбор" будут изменены все существующие методы + добавлены новые.

В принципе я оцениваю степень готовности - 40-50%. Т.е. мне бы немного времени (2-5 дней) и был бы первый тестовый вариант.

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

vandalsvq писал(а) 29. Марта 2012 :: 17:27:

Саш, да ты проще сделай - в тему с классами в первое сообщение добавь текст вида "donation в поддержку разработчика принимаются " и яндекс-кошель или еще что. И будет все прилично, анонимно и кто скока может/хочет.

Не совсем понятна суть вопроса. Ты имеешь ввиду, делать ли отдельный класс для "доступных полей", или просто дерево значений научить?
Мне казалось что для этой цели достаточно просто спец. обработки (по типу ПоставщикДанных.РедактированиеСписка.ert). Не?

Цитата:


Я вроде так и написал  

В общем просто обработки может быть недостаточно. Например если она будет ты сможешь редактировать список отборов (правая часть скриншота), но для отображения доступных полей (левая часть) тебе придется писать заполнение самостоятельно. Если учесть что я его написал, вытащить его наружу мне не сложно, другое дело как это сделать.
Но судя по тому что собственный поставщик - избыточен тогда я наверное ограничусь заполнением поставщика "ДеревоЗначений"

2 dimm73, постараюсь не забыть.