Бродя по разным веточкам нашего славного форума, регулярно натыкаюсь на фразы о том, что надо бы ООП прикрутить к 1С. Долго думал, воскуривал фимиам и так и не допер, зачем он надо? Не так давно на Хабре проскочила очень занятная статья на эту тему (http://habrahabr.ru/post/147927/).
С автором статьи я по большей части солидарен, особенно если прикладывать к 1С, посему вопрос: Ребята, которые хотят ООП в 1С, можете примерно рассказать, для каких задач он надо вам?

но подчеркну, в целом эти байты не нагрузят память при правильной реализации

(135) а вот теперь подробнее

(136) Вот как раз об этом писал, когда меня гуру перебил. Всегда правильно реализовывать не получится. Будет много неоптимальностей. Как их есть и с нынешней парадигмой программирования.

(98), пиши функцию печати в модуль менеджера. И не нужно будет иначеЕсли дописывать

Со (130) в целом конечно согласен, но частности (в виде неоптимального кода) могут похоронить идею.

(137) а чего подробнее? для обьекта выделяется память под статические свойства и под описание самого объекта, где тут выделение памяти под данные?

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

Реализация 1с оперирирует только "кучей", любые другие способы требуют явной типизацией и не могут работать со сборщиком мусора (требубт явного удаления из памяти)

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

(140) ну это уже о том, что ООП дает кучу возможностей, и человека это окрыляет, а потом когда начинаются затыки, он либо начинает копать глубже и осознавать свои ошибки, либо начинает плеваться и говорить: "Этот ваш ООП"

это вопросы не к парадигме, а к уровню подготовки специалиста

(141) чопростите? объекту выделяется под статику? илите может доку покурите?

:))))
Ребят, это ТАМ все делается так, как пишите, как сделает (если возьмется) 1С одному Нуралиеву известно :)

(144) мы говорим об экземпляре объекта

(142) конкретный пример?)
в целом если проектирование неудачное такое может быть, но рефакторинг на то и существует)

тупая ветка

(143) Ну вот отсюда то и вывод, может и станет лучше, но далеко не всем. Может конечно то на то и выйдет, 1Сникам будут больше платить денег :) Ибо станет их меньше :)

(143)+100 порог вхождения в ООП на порядок выше чем в 1с

(146) в (141) речь о статических свойствах, я правильно понял?

пустые ссылки на записи в таблицы должны быть NULL
ссылки на неиницилизированные объекты в памяти должны быть Неопределено

(151) о статических данных (просто "свойство" - более привычно для ООП в плане доступа к данным)

(149) ну я приверженец идеального кода и стараюсь писать в соответствии с определенными принципами, соответственно с ООП многие вещи для меня стали бы проще, что касается рынка труда - я думаю хуже точно не станет, а если повысится порог, то все же будет выше средний уровень ... проще будет увидеть неспеца, хотя их и так видно

(152) ура!
(153) я просто понял что речь идет о классических статических свойствах класса, у объекта статических свойств нет

(141) Ну может у разных языков разная реализация, но допустим в яве сразу при создании объекта все инициируется значениями по умолчанию и память резервируется полностью под весь объект.

+(156) Да и мне кажется что если выделять под объект память по мере необходимости, память станет слишком дефрагментированной и минусы будут намного больше плюсов.

(100) Не совсем понятна связь между ООП и памятью? ООП используется на этапе разработки, после компиляции остается оптимизированный машинный код в котором нет не объектов не интерфейсов не других заморочек парадигмы. Разве не так?

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

(158) Читай ниже, там есть рассуждения на эту тему

пока нет ООП в 1С многие недовольны ) Как появится ООП в 1С, ИМХО останется тоже много недовольных )

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

(161) если в 1с появится ООП недовольных будет на порядок больше, по сколько неминуемо произойдет разделение на "системщиков" и "прикладников"

(163) да оно и сейчас есть, за системщиков выступают 1С, за прикладников - все остальные

Если появится возможность наследования одних объектов от других - это будет полный трындец. У 1С с совместимостью релизов дела обстоят - хуже не придумаешь.

Уже сейчас хватает проблем, когда 1С вдруг решает перенести процедуры из одного общего модуля в другой.

И после этого вы хотите наследование?

давайте лучше это обсудим: v8: OFF: Даешь ФП в 1С!!!

(150) не льстите себе, подойдите поближе...

Есть такое мнение что ООП и разработана для быдлокодеров...

(167) в свое время разработал две полноценных компоненты для дельфи 2.0, пользовалось куча народу (уж не помню как точно назывались, что-то тип rGrid), точно могу сказать, что ООП на порядок сложнее в понимании процедурных языков...

(167) vde69 только к сорока годам переступил порог вхождения в ООП. Теперь ему осталось понять как ООП работает внутри, чтобы не писать ересь про выделение памяти в файлах проецируемых в память и про скомпилированый модуль, который получит новый функционал при замене базового класса.

(167) сильное, и не обоснованное заявление... за изучение ООП в основном принимаются те кто уже полностью "въехал" в функциональное программирование. И воткнуть в него поначалу очень не просто. А если еще учесть паттерны - быдлокодер их просто не поймет

"за изучение ООП в основном принимаются те кто уже полностью "въехал" в функциональное программирование"
глупости сходите по ссылке в (166) и сравните о чем здесь и там)

(171) Я имел ввиду нормальное изучение, а не хватание верхов без понимания как это работает и нафига оно надо, с последующими воплями что парадигма г..но

(172) изучение - это изучение, а вот результаты могут различаться

(172) есть следующие осноные виды программирования

1. Процедурное (например С, Паскаль)
2. Функциональное (например Лисп)
3. ООП (Например С++)
наверно есть и другие но живьем не сталкивался

с функциональным программированием вообще очень мало кто сталкивался... наверно ты имел в виду Процедурное?

(174) в шарпе функциональные вставки сделали

(172) Ага, попутал термены. В паскале кстати ООП довольно полноценно реализовано

(175) шарп отлично развивается

(176) угу, особенно linq впечятлил.

(175) в каком паскале? в 5.0 его не было вообще (вроде он появился в 5.5 или даже 6.0), реально ООП появился в дельфи...

(179) не помню версию турбо паскаля с которой мы начинали в инсте, но в ней конструкция object присутствовала и довольно не плохо работала :)

(179) ООП - это Объектно Ориентированный Программист?

Интересен комментарий:
"

К ООП тоже отношусь спокойно, отрицательно.

Так вот, написание кода - это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять куда-то намыливается... И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение!

Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как. И вот тут, в объектно-ориентированных языках типа Java, С# начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, монстроидальным шаблонным метапрограммированием, полиморфизмом, исключительными ситуациями... Увидев вызов простой функции, как правило сразу понятно что происходит, можно сходить и посмотреть, что она делает. В объектно ориентированных языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, не поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.

Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, не сомневаясь, удаляет его. Программа перестает работать. Что случилось? Оказывается, конструктор этой переменной устанавливает связь с другим объектом. Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но что написано пером - не вырубишь топором. В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на объектно ориентированном языке, не разберется никто. Посему, и надежность программ, размашисто написанных на таких языках, оставляет желать лучшего. Я уже не говорю про перекрытие операторов, конструкторов копирования и прочее. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события? Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на объектно ориентированных языках наломать дров проще простого, что мы и наблюдаем изо дня в день.

Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен, иначе человек, который заменит Вас через 2-4 года, не справится. Хотите проинициализировать переменную? Вызовите процедуру. Надо вызвать функцию? Вызовите ее напрямую. Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает около 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?

Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен. Наконец, необходимым требованием является 100% обратная совместимость библиотек. Ну скажите мне, хоть одна библиотека для Java удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о вопросах совместимости, инсталляции и прожорливости разных версий фреймворков под C# .NET и о том, что на изучение постоянно изменяющихся спецификаций различных новомодных библиотек может уйти полжизни, не говоря уже о проблемах стабильности их работы на практике.

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

Вообще, за последние 20 лет вышла масса литературы на тему дизайна программного обеспечения. Авторы книг статей постарались на славу. Были выделены и формализованы основные конструкции в виде паттернов проектирования. Сформированы основные практики и рекомендации. Однако, у этой большой и красивой медали есть обратная сторона – очень редко говорится О РЕАЛЬНОЙ НЕОБХОДИМОСТИ ПРИМЕНЕНИЯ тех или иных методик, а также о трудозатратах при этом. Подавлющая масса молодых программистов из-за отсутсвия опыта воспринимает все подобные материалы совершенно неадекватно, стремясь де-факто реализовать в одном месте практически все то, о чем они когда-либо читали и слышали (а слышали они в силу возраста как раз все последние веяния). Им трудно дифференцировать рациональные зерна от бесполезных "бантиков" и программирование превращается не столько в создание требуемого функционала, сколько в продумывание деталей как это будет написано. Внешнее и второстепенное выдвигается на первое место. Значительную часть времени начинает занимать бесполезный рефакторинг программного текста и мысли о том как же организовать очередное хитрое зацепление классов, в то время как создание полезнго функционала уходит на задний план. Например, в игровой индустрии подобные повадки особенно вредны. Нужен функционал, не нужен лишний текст. 99% текста выполняют 100% работы.

Например, когда-то одному разработчику был дан проект очень незатейливой игры. Предполагалось, что эта игра займет около месяца разработки. Но месяца не хватило. Спустя шесть недель выяснилась причина. Программист попался очень педантичный и вместо того чтобы взять чистый СИ и написать игру, он 80% времени занимался тусовкой классов в сложнейшей иерархии. Когда посчитали – оказалось порядка 210 классов. Движок получился, была написана чудовищная гора текста. В объекты было завернуто все, начиная от объектов межпоточной синхронизации и кончая экранными виджетами со своей собственной системой сообщений. Да только вот беда — сама игра была в совершенно зачаточном состоянии и не работала. Старые игры для GBA, C64, NES, SNES, Megadrive, ZX Spectrum, Atari, N64 всегда, с неизменным постоянством работали как часики. Можно конечно сейчас сказать "ну знаешь ли, не сравнивай сложность продуктов". А ничего подобного! Просто нужно знать как писались эти вещи и на чем писались. Раньше ведь даже не было IDE, и дебаггеров с одним тычком мыши. Не было самих мышей. Загружались с дискет (а еще раньше с кассет!). Иногда не было возможности отлаживаться или даже запускать код на самом устройстве. Так может уделять внимание эффективности, задачам которые пытаемся сделать?

Информация к размышлению: http://www.softpanorama.org/SE/anti_oo.shtml"

(182) Какой то взрыв мозга неудачника.
Бери простой язык Басик, напиши и попробуй сопроводи на нем чтонибуть больше 1000 строк кода.
А благодаря ООП развиваются проекты с миллионами строк, понятно что разобраться в них это не в 100 басиковских, но зато реально.

я пишу на пхп исключительно классами - тупо кода меньше.. и он мне понятнее

(182) Насчет шариться по куче файлов: а разве в 1С без ООП сейчас этого делать не надо? Разбор одной обработки проведения документа заставляет залезть в десятки общих модулей, и разобрать функции с дикими параметрами (вроде структур формирование которых размазано по километру кода). Офигительное упрощение читабельности...

(185)
>>разобрать функции с дикими параметрами
Что же поделать, если все эти параметры нужны. Не 2+2 ведь складываем.

Да, многие процедуры вынесены в общие модули и, частенько, мудрено устроены и мудрено взаимосвязаны. Сторонним программистам кажется, что это все необоснованно мудрено, но они то всего лишь пытаются проанализировать как работает какой-нибудь частный случай, какой-нибудь отдельный документ. А вся мудреность была создана, чтобы работал "общий случай", чтобы были единые, более менее универсальные механизмы для множества документов, чтобы была везде была примерно одинаковая метода построения кода. Это значительно упрощает развитие и поддержку конфигурации, если, конечно, изучить её внутреннее устройство на нормальном уровне.

(186) Да но параметр в виде объекта целиком описанного в одном месте несколько понятнее чем например такая фиговина:

Параметры = Новый Структура;
Параметры.Вставить("Хрень", ...);

//десяток строк кода

Хрень2 = Новый ТаблицаЗначений;
// добавлены колонки
// десяток строк кода, запрос..
//заполнение таблицы значений

Параметры.Вставить("Хрень2", Хрень2);

//Еще десяток строк

Хрень3 = и т.д.

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

(186) реализация в ООП будет примерно такая

Расчетчик = Новый ПодсистемаВалют.РасчетКурсов;

Расчетчик.ВалютаИсточник = ВалютаДокумента;
Расчетчик.ВалютаПолучатель = ВалютаРегламентированоУчета;
Расчетчик.ДатаКонвертации = ДатаДокумента;

Для каждого эл из Документ.Товары Цикл
НоваяСуммаПоСтроке = Расчетчик.Конвертировать(эл.Сумма);

+(186) меня, например, убивает вот такая читабельность кода:

СтрокаТабличнойЧасти.ЕдиницаИзмерения     = СтрокаТабличнойЧасти.Номенклатура.ЕдиницаХраненияОстатков;    
СтрокаТабличнойЧасти.Коэффициент = СтрокаТабличнойЧасти.ЕдиницаИзмерения.Коэффициент;

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

(188) а можно будет сделать новый класс

ПодсистемаВалют.РасчетКурсов.ВРегВалюту

(187) ну так все равно все сложное содержимое объекта так или иначе будет где-то инициализироваться, все будет заполняться, каждое поле.

Так и тут, структуру заполнили и гоняем её потом.

(183) И чем-же в объектах разбираться проще чем в процедурах и функциях?

(190) а какие принципиальные преимущества перед просто универсальной процедурой для пересчета, как сейчас в 1С?

Для меня главное чтобы каждый "элемент прикладной логики" был зашит в одном месте, объект это или процедура - это уже не важно.

(192) например тем что присвоение ппараметров делается через свойства, и первичную проверку типов, корректности с другими параметрами можно сделать внутри объекта и не парить людям мозг :)

ну и еще кучу чего можно просто скрыть...

(193) его можно подменить на другой и использовать также  - паттерн стратегия
хотя конечно в данном случае вряд ли это востребовано

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

(192) смотря кто писал, тут уже вопрос к именованию ...
но в целом для меня проще увидев объект и его методы понять что же он делает, чем методы которые отделены от данных и фактически мне нужно больше времени на ту же процедуру

(192) почему, например на основании этого делаем классы

РасчетчикРублевый, РасчетчикУправленческий

оно будет сильно читабельнее :)

(196) мы прямо синхронно выступили))

200

(196)
>>надо скурить весь процесс формирования этих диких структур в функции
также придется скурить и формирование этих диких структур в объекте

(201) Повторюсь я вижу все описание объекта в одном месте. Структура же зачастую формируется километром кода и всю её я сразу увидеть не могу

(198) ну так то да, главное не переборщить :)

Но! в 1С то точно также делаем, две процедуры для пересчета в Регл и Упр валюты, которые внутри себя вызывают уже центральную процедуру пересчета, и всё.

(202) ну случаи растягивания на километры кода боюсь не от этого зависят, а от
1. реальной сложности алгоритма

+(204) 2. криворукости

(203) разница в том, что если я в ООП в обьект Расчетчик добавлю свойство "Кратность" оно сразу появится и в унаследованых обьектах РасчетчикРублевый, РасчетчикУправленческий и его можно будет использовать СРАЗУ...

(204) и опять речь не об этом. я вижу функцию с параметром, я хочу знать что этот параметр должен содержать, в случае параметра объекта я просто смотрю список его полей не заходя в отладку и не читая простыни кода... в случае с 1с если функция не откоментированна я хз что этот параметр должен получить, я даже типа данных его не вижу

(206) или например свойство "бивалютная" и будет расчитыватся бивалютный курс :)

(207) а, ну в смысле, что в средах разработки отображается состав объекта в отдельном окошке? да, удобно

(208) ну да, ООП тут рулит.

Я применяю в 1С такие псевдообъекты:
Делаем общий модуль, в нем конструктор структуры, которая содержит данные объекта. Далее в модуле уже идут процедуры-методы, первым параметром у которых идет структура.

Инициализируем экземпляр структуры-объекта, и потом вызываем процедуры, засылая в них в них этот экземпляр.

(0) очень интересное мнение с описанием деталей всей этой кухни

(212) лажовым описанием ...

Дорогой, я не умею готовить твоё любимое блюда, вообще зачем оно тебе надо объясни? Может я не буду учиться его готовить, а ты поешь яичницу.

и ваще надо писать на ассемблере.. все остальное происки жиреющих империалистов :)

(122) - за такой запрос руки бы поодбивал.

(189) - Посмотри конфу от раруса - там есть в каждом модуле объекта документа - процедура - ОбработкаРеквизита + она же есть в общем модуле - идея следующая если происходит изменение реквизита то лезем в ОбработкуРеквизита с нужными параметрами - если реквизит спецефический то в этой процедуре выполняем нужные действия - если реквизит какой нить общий (пример - Номенклатура) - лезем в общий модуль в одноименную процедуру ОбработкаРеквизита и там чего то меняем уже - итог - изменение логики = изменение одной строчки.

(217) плачу от умиления, какой шикарный костыль

(217) шикарно...

потом приходит человек незнакомый с этой логикой и начинает править непосредственно в том месте где поменялась логика..

потом приходит третий человек который знает про этот костыль...

(218) - согласен что это не идеальное решение, но что есть то есть.
(219) - самому сначало было не привычно - потом ниче - даже удобно стало, а про людей не знающих - да могут дров наломать.

+(219) а еще лучше так - приходит  второй  и делает подписку на событие
приходит третий - выносит в общий модуль изменение логики
приходит четвертый - правит прямо на месте
приходит пятый и ох.евает...

(221) - имхо было 5 человек - после того как вкурили что к чему - изменения делали единообразные согласно структуре.

(221) - с вашей точки зрения как было бы верно реализовать сию фигню ?

(223) если честно то я вобще не понял накой хрен это нужно...

типа был реквизит "Номенклатура" а его поменяли на "контрагенты" или что?

(221) - и если не затруднит то ответьте пожалуйста на такой вопрос - как с помощью подписки на событие отловить изменение реквизита в открытой форме ?

(224) - Ниже пример - единицу измерения заполнять нужно всегда не зависимо от документа - а цену к примеру только в определенном документе.

Форма документа

Процедура ТоварыНоменклатураПриИзменении(Элемент)
   ОбработкаРеквизита("Товары.Номенклатура",ЭлементыФормы.Товары.ТекущаяСтрока,ЭтаФорма);    
КонецПроцедуры

Модуль объекта документа

Функция ОбработкаРеквизита(Имя,ТекСтрока=Неопределено,ЭтаФорма=Неопределено,ДопПараметры=Неопределено) Экспорт
Если ИмяРеквизита = ......
ИначеЕсли Имя="Товары.Номенклатура" Тогда
  Рез = дкОбработкаРеквизита(ЭтотОбъект,Имя,ТекСтрока,ЭтаФорма,ДопПараметры); /// Вызов процедуры из ОбщегоМодуля
  Рез = ОбработкаРеквизита("Товары.Цена",ТекСтрока,ЭтаФорма,ДопПараметры) И Рез;
  Рез = ОбработкаРеквизита("УстановитьРозничнуюЦену",ТекСтрока,ЭтаФорма,ДопПараметры) И Рез;
  Возврат Рез;
КонецЕсли;
КонецФункции

Общий модуль

Функция дкОбработкаРеквизита(ЭтотОбъект,Имя,ТекСтрока=Неопределено,ЭтаФорма=Неопределено,ДопПараметры=Неопределено) Экспорт
Если ИмяРеквизита = ......
ИначеЕсли Имя="Товары.Номенклатура" Тогда
/// Тут у примеру заполняем единицу измерения
Возврат Рез;
КонецЕсли;
КонецФункции

(226) Не дай бог такое сопровождать.

(226) полный п.здец...

и эти люди требуют ООП в 1С?

выжигать их каленым железом...

(227) - 5 лет :) сопровождал сие чудо - кстати это Управление торговлей от Раруса

(229) - конфа мож как то и по другому называется сейчас уже не упомню.

(228) - Алексей вы не ответили на вопрос в (225)

(228) дада, лучше ФП

(232) - ИМХО - каждому свое.

(231) при записи объекта посмотреть что изменилось например.. но в контексте пересчета ТЧ который вы показали это конечно же неприменимо...

(234) - спасибо.