EE7.9.2
не выводит поля non-common property. Есть способ, как заставить Part Lister вывести те поля компонентов, которые мне нужны для формирования перечня элементов?

К тому же он еще и не группирует компонеты...

Сам долго мучился с данной проблемой.
В итоге получил следующий файл настроек:

Как мне заставить Part Lister выводить пользовательские свойства, выводит только системные свойства элементов!?

Всё оказалось проще простого... ввели пользовательские свойства в Library manager, далее верефикация листов схемы и апдэйт праметров.
Таки получилось!

Препоны просто на каждом шагу!

Почему эта чудо-программа не выводит свойства, которые создает cross reference?
Как мне вывести зону на листе, в которой находится компонент???

Я проверил, по умолчанию получается что размещенный XREF является Non-Common Property (в окне Property щелкните на названии атрибута и внизу увидите эту надпись и различные значения). Если же в окне Property добавить этот атрибут через выпадающее меню, то с него partlister считывает данные. Т.е. надо разобраться чем эти XREF отличаются.

XREF... Про собственно перекрестные ссылки я уже и забыл, т.к. Вы же сами мне объяснили, что на болтающихся нетах они не работают.
Я говорю про неперекрестные (direct) свойства. Я создал свойство LOCATION и пишу туда зону компонента на листе. Т.е. проблема явно не в имени, т.к. у нас с Вами эти свойства по-разному называются.
Естественно, я пробовал создать это свойство в definition editor-e.

Еще раз внимательно посмотрите на написанное мной. Название атрибута не принципиально. В любом случае при авто-расстановке атрибут размещается как Non-Common хотя он и есть в списке атрибутов. Можете даже запустить макрос Нажмите для просмотра прикрепленного файла и он удалит эти Non-Common Property (LOCATION в вашем случае) и сделает их common, но к сожалению почему-то при этом теряются значения (иначе это было бы полным решением проблемы).

Да я как бы и с первого раза понял.
Слыхал я, что non-common - это такие свойства, которые пришли в проект со стороны без участия единого хранилища этих свойств (как, например, при трансляции из 2005). И думается мне, что просто ментор, как всегда, не дописал\не проверил свой софт. Видимо, про скаут забыли, и, когда он вставляет свойства, общую базу проекта как-то не обновляют, или что-то наподобие того. А потом получается, что оно стало non-common со всеми вытекающими.
А вот макрос я запускать не буду. Плавали, знаем.

Нажмите для просмотра прикрепленного файла

Что Вы хотели сказать этой картинкой? У меня-то по-прежнему не работает. В макросе есть волшебная опция перевода свойств из non-common в common?

А... Вы выбрали руками? Надеюсь, мне Вы не предложите сделать то же самое раз эдак 250?

Я выложил макрос который ищет указываемые в диалоге (по имени) атрибуты и переводит их в Common. В описании написано что кроме этого он должен переписывать обратно и значения этих атрибутов. К сожалению у меня они не переписываются, возможно из-за того что они прописаны на уровне Instance. Насколько я понимаю, в нем можно исправить что-то, чтобы это решило вашу проблему. Вот и все.

Нет, это выше моих сил!

Я не поленился, и таки исправил. Пока что выкладывать не буду, ибо код перепахан брейкпоинтами для понимания, почему же половина его не исполняется. Оставим такие мелочи, как криво написанные функции без обработки исключительных ситуаций. Скажите лучше, что делать, когда после дня дебага и удачного переделывания non-common в common я увидел в партлистере для некоторых компонентов (hetero) в графе "зона" значение "#Multiple"?
Multpile, это какие конкретно значения, черт возьми? Что мне теперь, писать свой партлистер, который выводит их все, или, хотя бы, первое попавшееся, как это было в 2005?

Я знаю что надо исправить. Совет новичкам: не повторяйте чужих ошибок, лучше сразу снести этот чудо-САПР, и сэкономить себе кучу времени.

Для поля "зона" не пробовали ставить в поле Mode значение "Full" вместо "Compress"?

Пробовал. Ему пофигу. Также менял символ разделителя.

У меня работает Нажмите для просмотра прикрепленного файла
Зависит от всех настроек, например от выбора вторичных ключей.
У меня стоит:
Ref Designator - Primary
XREF - Secondary

Признаюсь, меня это взбесило, и я плюнул дальше смотреть.
Но, тем не менее, есть еще одна проблема. Я не смог (еще полдня потратил) нормально превратить в common значения тех компонентов, которые повторно используются благодаря иерархии. Уж чего только не делал, чуть ли не заново переписал этот скрипт, вставлял туда функции AddAttribute и AddOAT последовательно друг за другом, и т.д.
Там в скрипте есть место, которое проверяет наличие атрибутов с разными значениями, но одним именем. И это место срабатывает, т.е. такие атрибуты (экземпляры их, я тестирую только один атрибут LOCATION) находятся. Значение одного из них отражает зону, которую сделал скаут, а значение второго - пустота. Зачем скаут это делает - не понятно. В скрипте же при этом написано "TBD" и просто вывод в мессаги оповещения, что этот атрибут пропускается. Фантастика.
Это мне теперь надо написать новый цикл внутри этого с поиском таких значений и, если оно пустое, то пропустить его и взять не пустое...
Интересно, а скаут только такие комбинации создает?

Я могу задать еще тысячу подобных вопросов, но я задам только один: ментор вообще хоть как-нибудь, хоть чуть-чуть тестирует свои произведения? Они вообще сами пробовали плату-то развести и схему нарисовать.
Ощущение, что в последнее время все увлеклись новым GUI, а на остальное просто забили.
Поэтому, как ни прискорбно признавать, но переход на 2007 у меня не удался. Не вижу смысла работать в таком САПР, он отнимает слишком много времени на непроизводительную деятельность. Если хотите, перечислю все проблемы, с которыми пришлось столкнуться при переходе (пока свежо в памяти) где-нибудь в отдельном топике, авось кому полезно будет.

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

Вы очень часто отвечаете здесь на форуме в подобном стиле. У меня вопрос: зачем тогда делать все эти многочисленные возможности, которыми никто не пользуется? Зачем зияют эти бесконечные дыры? Не проще ли сконцентрировать свои усилия на написании полностью проверенного софта, пусть даже в ущерб функциональности? А то получается некая замануха. Если расчет на то, что потом трудно будет уйти к другим, то, поверьте, многим (особенно руководителям) все равно в чем там инженеры рисуют, лишь бы продукт был.

Так то-то и оно что те возможности которые интересуют многих работают как правило как надо. Если не хватает возможностей , то сами нуждающиеся пользователи вносят их в список предложений (сейчас их уже более 700) и по количеству проголосовавших за них оценивают степень заинтересованности в них. Если о вашей "дыре" никто за столько лет не заикнулся, то о чем это говорит?

Естественно, о том, что этим никто не пользуется. А если никто не пользуется, то зачем это делать было? Вот в чем вопрос.
Видимо, ментор думает, что сначала надо сделать все, что можно, а потом сидеть и собирать баги. Поверьте, баги будут и без этого, даже в том случае, если будет создан только необходимый минимум функционала, который, как Вы говорите, нужен большинству. Зато оставшаяся непроверенная никем часть не будет бросать тень на весь продукт. Любой нормальный юзер, все-таки, рассчитывает, что софт тестировался и работает. Так что Ваш аргумент не засчитывается.

Пользуются, но только не так как Вы.
Разве нельзя расставить аннотации по схеме или генерировать BOM с общими атрибутами?
Да, Вы пошли дальше - захотели в BOM включить и информацию об аннотации, а другие пользователи этого никогда не делают. Ну так оформите это предолжение на сайте предложений, может кто-то еще заинтересуется такой задачей и менторовцы ее реализуют.

Нет, пардон, чем это я так выделился? Как еще можно использовать эти аннотации (о зонах)? Что же это, все пользователи расставляют эти аннотации на схемах и сидят и любуются? Эту информацию же надо где-то дальше использовать, не может же она просто так добавляться и быть только в схеме? Какой тогда в ней смысл? Или Вы знаете другой путь, как ее выцепить из схемы (не через бом)? Или никто не пользуется direct reference с зонами?

1. Ну откройте стандартный файл генерации BOM и где там аннотации?
2. Откройте стандартный файл генерации скаута и где там аннотация на все элементы схемы?
3. Если бы все что нужно Вам было стандартным, то было бы стандартно включено в эти конфиг. файлы
4. Обычное использование аннотаций - это размещение их на символах перехода цепей по страницам. Чтобы было понятней где цепь продолжается при работе с бумажной документацией. Вот и все.
5. Если рассматривать наш регион, так вообще Ваше применение (размещение аннотаций на всех символах схемы) никому не нужно, т.к. 99% пользователей с которыми приходится контактировать тупо смотрят в ГОСТ на первую строчку пункта 3.19 и делают упорядоченную нумерацию по схеме. И зачем им тогда аннотации на символах схемы? На выход они тоже генерят "Перечень по ГОСТ" и где там аннотации предусмотрены?

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

1. Не очень понял, о чем Вы. Но - да, часто они не используются. Надеюсь, из-за этого Вы не предложите мне примкнуть к большинству?
2. Откройте сами. Увидите команду direct_reference с размещением зон. Вопрос: накой она там, если ее далее никак не выцепить?
3. Неужели? Возьмем стандартный файлик allegro.cfg. Там, как мы (точнее, Вы, я пока не проверял) выяснили записана проверка поля ALT_SYMBOLS, которая не работает. Чтобы она заработала, нужно править конфиг. Вопрос: это и есть "стандартно включено в эти конфиг. файлы"?
4. А зоны при работе с бумажной документацией - это не обычное использование аннотаций? По ним никто не ищет на бумаге расположение компонентов? Зачем нужны зоны по-Вашему?
5. Откройте ГОСТ и увидите разные формы шаблонов для перечней, СП, ВП и др.: с графой "Зона" и без.


Да ничего особенного, все как у всех. Компоненты, и на них пытаюсь проперти проставить...

Я прошу прощения, vitan, но Вы как то уж слишком жестко пишете. Возможно у Вас накопилось раздражение, но fill на самом деле здесь уже не первый и даже не пятый год, и помог сотни раз реально. Предлагаю снизить уровень и категоричность Ваших постов. Иначе начнем флудить

Жестко? Так ведь и времени я убил на все это немало. Ценность советов fill-а я не оспариваю, сам говорил ему спасибо несколько раз, но я ничего не выдумываю, и говорю как есть. Сам я тоже пытаюсь помогать, когда могу. Правила форума я не нарушаю, иначе сам fill первый же меня по-модераторски отфутболил бы.
Так что, жестко - это да. Что вижу, то пою.

Да, по задумкам САПРописателей аннотация предназначена исключительно для облегчения навигации по схемам и больше ни для чего, а при правильной ее реализации замечательно с этим справляется. Так что Vitan, Вы опять в меньшинстве...

1. Откройте новый проект и запустите Partlister - увидите стандартный набор:
# QTY Part Number Description Value Ref Designator
это и есть стандартно используемые данные для BOM.
Вы же создаете уже не BOM, а несколько иной документ.
2. Тоже самое, посмотрите стандартный файл настроек скаута - в нем аннотации на символах размещаются только на определенных символах форматки и Композитных
3. Возьмите, и где там спец. проверка для ALT_SYMBOLS? Допускаю что строчку внесения в нетлист данного атрибута добавили с появлением такого свойства в Allegro, но не предусмотрели, что его значение может содержать знаки запрещенные для всех других атрибутов. Те кто пользуется данным атрибутом просто внесли исправление в свой конфиг. файл и забыли об этой "проблеме", т.к. стандартными конфигами как правило пользуются только начинающие пользователи.
4. Не допускаете что обычно просто используют для того чтобы при общении например по телефону указать другому человеку "посмотри на лист такой-то в такую-то область" и не более того?
5. Да, виноват, забыл. Действительно есть вариант с графой зона, но только сколько я ни смотрел присланные мне перечни\спецификации из других компаний (а их много), во всех если и есть эта графа, то девственно чистая.

PS. Что касается скаута, то была информация что его хотят полностью переделать.

1. Т.е. Вы хотите подойти к делу формально, говорите, что если я чего-то поправил в конфиге для бома, то это уже и не бом? Думаю, большинство (к которому Вы так любите апеллировать) с Вами тут не согласится. Даже в менторовском хелпе есть раздел о том, как настроить бом, и от этого он не перестает оставаться бомом.
2. Да-да. Команды аннотации зон для компонентов и пинов закомментированы. Я ж говорю: замануха.
3. Сорри, неточно выразился. Самой проверки в чистом виде нет. Но свойство-то передается, оно указано в разделе AttPassList. И при передаче оно генерит эту несчастную ошибку. А вот, Ваше утверждение о том, что "кто пользуется данным атрибутом просто внесли исправление" говорит как минимум о том, что это не тестировалось. А как максимум - это мой случай, мне не удалось без посторонней помощи это исправить, ибо это нифига не тривиально, с учетом отсутствия какого-либо хелпа на эту тему. Все это говорит о качестве.
4. Ух! А по емейлу, значит, мне уже нельзя сказать соседу, куда ему смотреть? Информацию из схемы в компьютере может считать только человек, но не компьютер?
5. Ну опять же, разговоры о большинстве. И они были бы обоснованы, если бы ментор не предлагал кучу доп. возможностей, которыми пользуется меньшинство, при этом их не тестируя.


О май гад. Это будет, наверно, последний гвоздь в крышку гроба.


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

3. Я же нашел данную информацию через документацию и knowledge database - стандартный набор которым пользуются офиц. пользователи.
4. Наступили на больной мазоль - как было бы проще мне работать если бы все офиц. пользователи общались со мной исключительно по почте. Открою Вам глаза - 99% вообще не имеют доступа к интернет (ибо секретность). Да и телефон на раб месте это тоже зачастую роскошь - общение выглядит следующим образом:
- звонок: вопрос
- ответ :сделайте на компе то то и то
- ответ: щас сбегаю до компа ....



Никто не считает это ересью. Просто то что Вам так важно, другими не используется. Соответственно и не тестируется, и не исправляется.

Ну почему сразу порицание? У меня Ваши старания вызывают сочувствие например... Все пытаетесь что-то сделать, а не получается. Мне правда в 90% случаев непонятно зачем Вам это надо сделать и как это помогает в работе и ускоряет процесс проектирования.

Ок, по пунктам 1, 2, 5 - иппон?
3. Knowlеgde base - это прекрасно. А что Вы скажете на то, что в этой части конфиг не меняется на протяжении уже нескольких лет? Проще записать все в эту base, и пусть кому надо рыскает по ней. Хотите сказать, что эта маленькая проблемка, и ей некогда\невыгодно заниматься? И занимаются только действительно важными проблемами? Это все хорошо, только поймите, что для каждого юзера свои проблемы гораздо важнее общих проблем ментора. То, как ментор классифицирует багу и какой ей дадут приоритет, ровно ничего не меняет для конечного юзера: ему надо тут и сейчас сдать проект. Поставьте себя на место юзера, что бы Вы сделали в такой ситауции, когда потрачено уйма времени на переход, и в конце не удается получить документацию в том же виде, что была до перехода? Что сказать начальству? Себе?
4. Дык и я почти такой же. У меня только почта есть. Но суть не меняется: имеем схему в электронном виде, но считать из нее информацию можем только глазами. Это 21 век, между прочим.


Вот спасибо, пожалели беднягу...
Очень полезно иметь зоны в перечне. Особенно при ремонте и регулировке. Поступает сообщение: "Сгорел R123, не работает канал XYZ". Открываем перечень, видим имя резистора, говорим складу, чтобы приготовили новый. Тут же открываем схему, по зоне находим его и проверяем, что это за резистор, на что он влияет и т.д. При этом неважно в каком виде схема и перечень, на бумаге или в эл. виде. Т.е. физически Вы можете сидеть за своим компом, а можете бегать с комплектом КД по цехам или вообще в командировке.

Вы никак не поймете одного, чтобы что-то было сделано, нужно чтобы кто-то из пользователей запустил весь этот бюрократический процесс внесения изменений:
- создал SR
- по нему создали DR
- внесли изменения в ПО согласно требованиям DR
В вашем случае НИКТО не сподобился на это.

По поводу перехода 2005->2007. Офиц. пользователи при возникновении проблем обращаются непосредственно в support и быстро решают возникшие проблемы.
Кроме того менторовцы создали как документы по вопросам миграции, так и спец. форумы где пользователи обмениваются как опытом миграции, так и полезными скриптами, автоматизирующими такой переход.



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



А зачем вообще тогда лезть в Перечень, если можно просто открыть схему в эл. виде, нажать find и увидеть перед собой нужный резистор, на котором и прочитать его имя.
Только для случая "бумага+произвольная нумерация на схеме" ваш способ действительно дает некоторый выигрыш. Проблема в том что как было уже сказано 99% у нас используют нумерацию по схеме и тогда выигрыша уже практически никакого.

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


А аллегро тупо открывает старую версию файла pcb в новой версии САПР. Возникает информационное сообщение об этом и на сем мучения пользователя заканичваются. За 15 лет использования этот механизм не сглючил у меня ни разу. Чувствуете разницу? Никаких форумов, никаких скриптов, техподдержки и др. Две секунды и готово.


Ну я ж говорю: чтобы не зависеть от того, в каком виде документация. Разве не очевидно, что это полезно?

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



Так ExpeditonPCB (или DC\DV) также без проблем открывает старые релизы за те же 15 лет.
А проекты DxD2007 также без проблем открываются в новых релизах в течении 5 лет.
И это происходит во всех программах где не было коренного изменение внутренней базы построения системы.
Процесс DxD2005-->2007 не даром называется "Миграцией", а не просто открытие проекта в новой версии софта.
Чтобы далеко не ходить посмотрите на "оркадчиков" - насколько легко у них происходит миграция из Layout в новый релиз (Allegro)?



Полезно, не означает что обязательно нужно.

Специально, сейчас задал вопрос одному очень дотошному пользователю - они перед переходом всячески тестируют новый релиз, и только потом если все нормально (по их маршруту работы) ставят его у всех в компании. При выявлении ошибок они создают SR для исправления. Кроме того они дописывают дополнительные функции, которые им необходимы.
Его ответ по зонам - "Нет, в перечень из СхЭ мы не выводим графу "Зона". Нам это просто не надо".
Т.е. Вам в данном случае не повезло, если бы они работали по вашему маршруту, то эта проблема была бы давно выявлена и устранена.

Скажите, пожалуйста, годами висящее в базе знаний решение проблемы (копеечное) - это не повод уже таки внести это решение в релиз?


Имея такие примеры, это никого не вдохновляет. Прискорбно.


Ну замануха в чистом виде. Оркадчики хотя бы знают, что переходят на полностью новую систему, которая даже называется по-другому. Здесь же отовсюду сквозит плавный и беспроблемный переход, который на деле вывливается в бесконечную ловлю багов. Хотите в корне поменять внутреннюю структуру софта - пожалуйста, кто вам может запретить? Только при этом не забудьте столь же подробно проверить все ваши коренные изменения, а то со стороны похоже на детский садик.


Действительно. Если ты работаешь в менторе, то далеко не факт, что тебе надо улучшать качество своей документации, ибо ты знаешь, во что это может вылиться.


И что? Тогда уж будьте до конца принципиальны, попросите этого пользователя ввести SR на тему удаления из софта аннотации по зонам.

точнее на 99%

vitan плиз объясни для чего это нужно ???

Спешл фо ю: http://electronix.ru/forum/index.php?showt...t&p=1086434

С чего вы взяли что там висит SR-DR

Там всего лишь вопрос "Как задать альтернативные символы для Allegro" и ответ как Нажмите для просмотра прикрепленного файла

Если бы пользователь сформулировал SR приблизительно так как Вы : "В стандартном файле конфигурации отсутствуют настройки для правильного использования атрибута ALT_SYMBOLS", тогда бы появился бы и DR, а затем исправление в релизе.



Можно конечно попробовать.

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

Спасибо за файлик. Но почитайте его: где упоминание про проверку для ANY?


Т.е. к ментору нужно еще подход найти... Все отдали на откуп юзерам, загородились бюрократией и спокойно живут, не следят за своим творчеством. Система...


Вот и посмотрим. Уверен, что это должно натолкнуться на непонимание со стороны менеджеров, т.к. тупо урезается функциональность. И тогда, возможно, начнется-таки разбирательство. Мда...

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


Посмотрите внимательно в описание:
вместо правки проверки ANY
предлагается добавление строчки
CHKVAL _NAME_CHK PKG ALT_SYMBOLS ERR 0 "A-Z0-9_-()" "" 1 79

Предложенное мной решение с ANY было сделано методом "научного тыка", до того как я нашел выложенный вариант из базы знаний.



В менторе работает более 5000 человек. Чтобы управлять процессом и контролировать, что сделал каждый, введена определенная последовательность работы с применением базы обращений, задач и т.п.



Естественно SR не будет выглядеть так как вы написали. Для того чтобы сформировался DR нужно чтобы в SR содержалось описание того что софт работает не так как написано в документации и это было выявлено\подтверждено на тестовом примере. Поэтому в SR написано что скаут формирует Non-Common Property, которые не обрабатывает Partlister? поэтому нужно поменять скаут (для получения common property) или поменять Partlister (чтобы он читал Non-Common Property).

Что-то мне это напоминает:

- Кто сшил костюм?
- Мы!
- Кто это мы?
- Специализация у нас узкая: один пришивает карман, другой – проймочку, один – рукав. Я лично пришиваю пуговицы. К пуговицам претензии есть?
- К пуговицам претензий нет. Пришиты насмерть, не оторвешь. Кто сшил костюм? Кто вместо штанов мне рукава пришил? Кто вместо рукавов мне штаны пришпандорил? Кто это сделал?!
А. Райкин, «Ателье»
http://www.youtube.com/watch?v=2wxL3DYen5g

Моё ощущение, что предыдущие версии DxD (до 2007) продумывались как целостный продукт и создавались специалистами не только в программировании, но и в предметной области.
Современный же DxD (после 2007) компилируется манагерами из набора фич для достижения заявленного функционального наполнения. Отсюда и все бесконечно обсуждаемые нескладухи. Но это видимо требование времени, современного ведения бизнеса.

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

1. Исправленный скрипт удаляющий указанные Non-Common Property и вставляющий их обратно как Common с сохранением их значений Нажмите для просмотра прикрепленного файла
2. По данному поводу зарегистрирован DR.