Смешно видеть элементарнейшие глюки (и при этом крайне вредные), которые живы вот уж 10 лет.
Сам мало в нём работаю.

Да. Как и весь EE.

:-)) В принципе согласен, но всё-таки это субъективное мнение граждан, презирающих ментор, к коим и я отношусь.. :-)))

А вопрос был в другом. Считает ли сам ментор что DC - тупик, и все должны перейти на ДхД?

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


Кстати, а что за глюки, да еще десятилетние? Заинтриговали. Я всегда считал, что DC весьма неплохой продукт, глюки есть, безусловно, но они добавлены в виде бонусов к сомнительным улучшениям относительно недавно.

Один из самых злобных:
Если передвинуть какую-либо микруху, к которой прицеплено много проводов, и при этом сдвинуть немножко не так, как хотел (точно сдвинуть, как в пикаде, в DC невозможно), то провода естественно запутываются. Но после UNDO некоторые (многие) так и остаются запутанными. Это происходит всегда. А ИНОГДА UNDO не срабатывает вообще, а вместо этого делает ТАКОЕ, чего сроду не было. Обычно это сопровождается таким спутыванием проводов, что редактировать уже бесполезно - нужно либо перерисовывать, либо откатываться к бэкапу.

Есть ещё парочка почти таких же невыносимых глюков, а более мелкие и считать уже устал.

Типичная проблема пользователей работающих постоянно в одной системе и изредка в другой. И т.к. в другой системе какие то задачи делаются по другому у них возникают проблемы.
В DC при перемещении символа, цепи к нему подключенные перестраиваются с сохранением ортогональности (в отличие от PCAD) при этом могут возникать дополнительные шаги оптимизации цепей (выполняемые системой автоматически), которые не могут быть напрямую UNDO т.к. уже не являются записанными выполненными командами пользователя. Об этом надо просто знать и перед перемещением символа просто подумать где могут возникнуть такие моменты - у пользователей постоянно работающих в DC это происходит на автомате - у вас нет. Увидев возможные проблемы бывает достаточно (для достижения нужного результата) кроме этого символа выбрать еще и отрезок(и) цепи(ей) или\и доп. символ(ы) и перемещать таким образом не только один символ, а и его окружение.

Приведите еще ваши глюки - вероятнее всего опять окажется что они являются итогом выполнения операций "как в PCAD".

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

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

Насчёт "сохранения ортогональности". :-)) ДА, пикад даже не пытается этого делать, за что ему большой респект. DC пытается, но не может :-))) за что ему большой анреспект. Не умеешь - не берись.

"Знать и думать" я как раз имею возможность в пикаде, так как там:
1) всегда видно, что и куда я двигаю, а в DC при захвате блока (начиная с некоторого количества компонентов) он весь превращается в рамку, и его внутренности не видны.
2) в пикаде я могу двигать блок стрелками - 1 клетка сетки на нажатие, и таким образом могу поставить его точно куда мне надо, чтоб ничего не запуталось. В DC этого нельзя - только мышкой: рука дрогнула, промахнулся на клетку и всё запуталось. (Ведь ещё и не видно, ЧТО двигаешь :-)) И UNDO уже не поможет.. :-)))


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

нууу вы еще DxD не щупали. вот картинка - сразу пачка глюков в одном флаконе.

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

Как не щупать? :-)) Щупал, правда, тоже лет 10 назад.. :-)))) Приятно слышать, что и там ничего не изменилось.. :-))))))

а где картинка ?


как правильно заметил fill - дело привычки

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

просто к хорошему быстро привыкаешь не считаясь глюками

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

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

1. Ну если обижаться вам проще чем понять, что я пытался описать причину проблемы и то как с ней бороться, тогда действительно зачем терять время.
2. Если же конструктивно подходить, то ничто не мешает после выбора "блока" покрутить колесом мышки, сделав такой масштаб чтобы даже при дрожании руки это не приводило к смещению на несколько клеток, схватить ЛКМ за любой (удобный для контроля перемещения) элемент выбранного и переместить на одну клетку.
3. Я согласен что по умолчанию перемещения стрелкой в DC нет. И если вам эта функция действительно очень необходима, то это большая проблема.
Могу вас успокоить - в DxD (другом редакторе схем) функция перемещения стрелками присутствует.




Если в исходном проекте текст перевернули, при этом в старом релизе отображение 0=180, а в новом есть галочка (которую вы включили) что теперь угол поворота текста 180 это перевернутый текст (т.е. 180 не тоже самое что 0), то в чем здесь глюк.

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

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

Проект - типа учебный от ментора. То, что он такой небрежный - это к индусам из Ментора. Я в нем ничего не менял (сетки, привязки и прочее), просто иногда играюсь, на нем все глюки виднее. А про риперы - в 2007.8 эти же рипперы вполне кашерно двигались вместе с шиной, не отрываясь от нее, и на них действовала магическая кнопка "Snap to Grid", поломали это, не заметив в 7.9.

А то, что имена цепей двигаются с символами компонентов? Это тоже так задумано? Не думаю...

пост риторический, ответа не предполагает.

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

еще раз хочу сказать, что я не тот пользователь, который меняет сетки как попало, наживая себе проблемы.
Я просто беру менторовский учебный проект, выполненный весьма небрежно, и делаю попытку его причесать-облагородить, в учебных целях, набить руку, получить навык... ведь этот проект для этого и предназначен. Но! оказывается сделать это (причесать-облагородить) в текущей версии DxD практически невозможно. А в 2007.8 - было возможно. Но в 2007.8 была маниакальная перерисовка экрана на каждый чих мыши, и объяснялось это видите ли необходимостью записи проекта! И даже ходили слухи, что по-другому просто невозможно. Однако, наморщили ум и преодолели! Я вполне даже допускаю, что при создании нового дезайна добиться такой корявой работы надо сильно постараться.

Что касается рипперов, то предположения Ваши вполне возможны, как и любые другие предположения. Когда риппер был встроенным спецсимволом, он вместе с шиной поддавался действию "snap to grid", а как стал изменяемым пользовательским - не поддается.
все примитивы (bus, symbol, net, ..) поддаются выпавниванию по сетке, а вот риппер - нет.
В контексте учебного проекта "DxPADS_2007WS" налицо потеря функционала.

а вот мое предположение - это просто головотяпство.

Могу рекомендовать использовать другие учебные проекты: во всяком случае в двух ("DxDesigner™ для маршрута Expedition™" и "DxDesigner® для Маршрута PADS®" ) все схемы рисуются от начала до конца - и руку набъете и поймете основной набор команд рисоования.