О нескольких документах в одном файле

[Omu]

Тема избитая, кажется много раз поднималась, так что могу в чем-то повторится, но есть кое-какие соображения.
Создание многолистовых документов решило многие реальные проблемы конструирования http://forum.ascon.ru/index.php/topic,1442.0.html, как то создание ассоциативных видов, автозаполнение осн.надписи и некоторые другие, но попутно возникли новые вопросы или остались неразрешенными старые.
Задачи (сформулированы мною лично и нужность их решения может быть оспорена другими читатеями):
1) Произвольная компоновка листа. Визуально лучше, когда несколько листов занимают прямоугольную площадь с соотношением стором как в окне документа, чтобы при уменьшении изображения были видны все документы при том, чтобы они занимали максимальную площадь окна.
2) Перенос содержимого листа вместе с листом (привязка содержимого к листу). В идеале, конечно, чтобы листы можно было таскать по окну как виды, но хотябы при изменении формата предыдущих листов.
3) Объединение в одном документе нескольких документов, например, спецификация и сборочный чертеж как наиболее очевидный вариант. Хотя иногда хочется туда же скидать прорисовки и чертежи деталей. Многим эта затея кажется спорной, но, согласитесь, конструктору решать, как ему упорядочивать свою документацию.
4) Объединение в одном документе моделей (сборки и деталей), чертежей и спецификаций.

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

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

[POMAH]

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

Я бы сказал разрешить возможность автоподбора форматки под содержимое (виды, разрезы, ТТ и т.п.) и, конечно, с возможностью редактирования её после изменения этого содержимого. Реализовано в TF. Опция вкл. и выкл. автоподбора.

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

Было бы здорово в плане скучкования множества файлов (я представляю как EXCEL, кстати в Inventor реализовано), но только надо оставить связь с отдельными 2D-документами и спецификацией. Отдельно файлы для 2D и 3D.

[Romeo]

Мои предложения (может немного повторюсь)
1. Один универсальный файл детали включает в себя вкладку модель и чертеж. (при необходимости можно использовать только лист чертежа)
2. Один универсальный файл сборки включает в себя вкладки сборка, сборочній чертеж, спецификация.
3. Код, название, материал читаются напрямую из файла детали при подключении детали в сборки без "объектов спецификации" с возможностью в свойствах детали ставить галочку в какой раздел спецификации ода должна относится.

[Pav]

Некоторые причины, говорящие о том, что не средства Windows не Компас не удовлетворяют в полной мере потребности конструкторов.
А также предложено некоторое решение.
http://forum.ascon.ru/index.php/topic,5177.0.html
..................................

[Марианна Золотарева]

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

Тема действительно уже обсуждалась..
Хочу немного углубиться в технический вопрос. 
Дело в том, что механизм "связывания" документов спецификация+модель+сб.чертеж давно имеет реализацию. Как правило это делает любая уважающая себя САПР, и  Компас в том числе. Следуя правила "1 документ- 1 файл" мы разрабатываем  и сохраняем графику документа, а дальше мы "обвязываем" эти файлы, используя средства САПР. В этом случае в служебных частях файла, содержащего, например,  электроную структуру (спецификация, 3D модель сборки) изделия, создаются ссылки на файлы чертежей/ моделей ДСЕ, входящих в них.
Соответственно, при открытии ссылочно-связанных файлов, САПР их читает, производит поиск и открытие файлов или выдает соответствующее сообщение.
Кроме этого, ссылки читаются другими автоматизированными системами, например PDM  или электронного архива, для получения дерева - состава изделия, автоматического создания архивной карточки на документ с получением в свои атрибуты информации с основного  штампа. Они также могут отслеживать обрыв этих связей, например, если был изменен отдельно взятый файл (со сборочного убрали деталь, в спецификации - забыли)

Так что скорее всего "черные ящики" не будут поддерживаться разработчиками САПР и PDM.
Я знаю, что на предпрятиях, внедривших у себя электроный архив, сдача бумажной КД производится вместе с электронным комплектом (ЭКД) с проверкой правильности такой "обвязки". Возможно до вас это еще не докатилось.

[Georg]

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

[Omu]

Тема действительно уже обсуждалась..
Хочу немного углубиться в технический вопрос. 
....

Логика понятна. Сделать так, чтобы неправильно сделать было нельзя.
Но Вы поймите, одно дело какой-то архив (мне дела с электронным документооборотом иметь не приходилось, поэтому представляю его себе абстрактно), где каждый файлик на учете, порядочек, все чистенько. Другое дело процесс разработки, когда структура файлов меняется постоянно, появляются новые файлы, удаляются старые, возникает необходимость делать копии документов, чтобы проработать разные проходные идеи. Через месяц работы папка проекта превращается в такую свалку, иллюзия порядка в которой поддерживается только могучим разумом конструктора. Чтобы понять что к чему относится требуется время, силы и память. Иногда внимание или память подводят и при чистке папок удаляются нужные файлы, и толку что сборочный чертеж "знает" про спецификацию, если ее уже нет в живых. Или при копировании проекта могут быть не скопированы какие-то файлы или не разорваны связи со старыми, что приводит к порче старых файлов. Приходится постоянно делать архивные копии и открывть сборки, чтобы посмотреть не испортилось ли чего. Объединение нужно просто для упрощения навигации в этой куче.
А при сдаче можно и разделить снова. К тому же, почему Вы говорите, что PDM не прочитает? Кто ее, эту PDM пишет? Вы же пишите, вот и напишите чтобы читало. Можно ввести правило, чтобы объединялись только файлы, которые существуют и имеют смысл только совместно. Например, бесчертежные детали просто не имеют смысла без сборки, их никто отдельно сдавать не будет.

[Pav]

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

Как я вас понимаю...
Очень хочется, чтобы об этом позаботился АСКОН и разработал инструмент которым можно решить все эти проблемы.

[klimvv]

Ребята и девчата!
ну сама по себе идея объединять все в одном файле ничем не отличается от собственно обычной папки. Ну какая, скажите, разница если весь этот "бардак", возникающий в ходе разработки, будет в одном файле, а не в одной папке?
Кстати если Вы не используете PDM попробуйте использовать какую-нибудь систему контроля версий (ту же Subversion - отличная вещь, свободная, хорошо работает с бинарными файлами, в отличие от CVS...) и Вы будете точно знать кто, когда и что менял в вашей ПАПКЕ 

[Omu]

Ребята и девчата!
ну сама по себе идея объединять все в одном файле ничем не отличается от собственно обычной папки.

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

[Alisa]

Ребята и девчата!
ну сама по себе идея объединять все в одном файле ничем не отличается от собственно обычной папки. Ну какая, скажите, разница если весь этот "бардак", возникающий в ходе разработки, будет в одном файле, а не в одной папке?

Разница огромная. При хранении проекта в папке вы имеете прямой доступ к файлам компонентов. При хранении проекта в одном файле, как это сделано, например, в TF, вы не доберётесь до детали, пока не откроете всю сборку. Деталь из папки бы можете вставить в другой проект, третий... Деталь из файла вы в другой проект можете вставить только в виде копии. Если вы перенесли проект, в котором были детали, использованные в другом проекте, эти другие проекты начинают ругаться. С деталью в файле сборки такое в принципе невозможно. Конечно, за это приходится платить весом файлов и пространством диска, но это уже вторичное. При хранении проекта в папке, в нём, как правило, куча ненужных файлов - отвергнутые варианты. При хранении проекта в одном файле в нём принципиально нет ничего лишнего. Так что разница-а-а.

[klimvv]

... Деталь из файла вы в другой проект можете вставить только в виде копии.

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

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

ну ИМХО вопросы о несанкционированном копировании файлов не касаются собственно САПР-системы, этим должны заниматься соответствующие службы (я имею ввиду программные)...

...Конечно, за это приходится платить весом файлов и пространством диска, но это уже вторичное. При хранении проекта в папке, в нём, как правило, куча ненужных файлов - отвергнутые варианты. При хранении проекта в одном файле в нём принципиально нет ничего лишнего. Так что разница-а-а.

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

P.S. тут кстати вверху упоминался механизм OLE (сейчас кажется его принято называть СОМ)? Вы пробовали внедрять в один файл другой? Лично я предпочитаю этим не пользоваться из-за громоздкости и неповоротливости всей этой системы. Мне больше по душе простой и ясный файловый подход UNIX-систем 

[Alisa]

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

Нет, вы просто делаете копию нужной вам детали.

...ну ИМХО вопросы о несанкционированном копировании файлов не касаются собственно САПР-системы, этим должны заниматься соответствующие службы (я имею ввиду программные)...

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

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

Может быть, не знаю. Куча вариантов одной детали - это цветочки. Ягодки начинаются, когда вы наплодите конфигураций и деталей, и перекроите раза три-четыре всю сборку. У меня в папке, прежде чем я пройду один этап, 15-20% файлов - мусор, причём половину этого мусора используют другие сборки. Количество деталей - 4-5 тыс.

И ещё один момент. Subversion, насколько я поняла, внешнее приложение. Почему оно не может быть внутренним? В составе того же Компаса?

[Pav]

Я против объеденения нескольких документов в один файл, хотя не котигорически. Задачу объеденения прекрасно решает "папка Windows". Но проблемы которые, вы думаете, решит объеденение в один файл действительно есть и достаточно актуальны.
Повторюсь, что должно быть средство Компас которое решает проблемы целостносто проекта именно на стадии разработки это и управление ссылками, связями исполнениями и еще много всего. Я предложил некоторый интерфейс который условно можно назвать "мини PDM", который поможет пользователю решить данные задачи и должен быть неотъемлемой частью среды разработки в данном случае "Компас". Компас-Менеджер решает задачи на стадии хранения документации, но не разработки. Мои "сырые" мысли по этой "мини PDM" сдесь: http://forum.ascon.ru/index.php/topic,5177.0.html

[klimvv]

что-то мы с Alisой никак не поймем друг друга 
скопировать деталь из ее общего файла можно, а скопировать файл из моей    папки Windows нельзя и из-за этого получаются перекрестные ссылки?

и еще: есть такой подход к программированию - UNIX-way (я все время упоминаю UNIX потому что надеюсь в один прекрасный день увидеть КОМПАС на этой системе). смысл в том что каждая утилита делает какое-то определенное действие, но делает его хорошо. Там даже операции архивирования/компрессирования выполняют разные утилиты, поскольку это разные операции (пользователи Windows обычно это не подозревают). В результате появляется возможность гибко компоновать систему под свои нужды, а не плодить монстров вроде MS Office. В том что Subversion программа внешняя, а не внутренняя это ее скорей "+" а не "-": у меня так, у Вас эдак - кому что нужно

[Alisa]

что-то мы с Alisой никак не поймем друг друга 
скопировать деталь из ее общего файла можно, а скопировать файл из моей    папки Windows нельзя и из-за этого получаются перекрестные ссылки?

Да нет, просто вопрос в схеме построения ссылок

[Omu]

При хранении проекта в одном файле, как это сделано, например, в TF, вы не доберётесь до детали, пока не откроете всю сборку.

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

Деталь из папки бы можете вставить в другой проект, третий... Деталь из файла вы в другой проект можете вставить только в виде копии.

А которые надо заимствовать, храните отдельно - дело хозяйское

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

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

ЗЫ вначале не совсем понял чью "сторону" Вы занимаете в данном споре. Но прочитав дальше, понял, что у нас одинаковый взгляд на проблему множественных ссылок. Это приятно.
ЗЫЫ Хотел пояснить свое видение, конечно инкапсуляция не решает конкретно эту проблему, но вот множественость ссылок не может препятсвовать инкапсуляции из-за этой проблемы.

[Gek]

Позвольте немного встрять. Приведу пример из моей электронной области. Как, например, организованы библиотеки элементов в Пикаде. Есть 1 файл библиотеки. В нем может быть сколько угодно символов, корпусов и элементов. Каждый из этих объектов без проблем добавляется, редактируется, удаляется, переименовывается. Одну такую библиотеку может использовать сколько угодно проектов. И никакого засорения папки bak'ами и прочим хламом.
Имхо, отличная реализация. Как считаете?

[Alisa]

Позвольте немного встрять. Приведу пример из моей электронной области. Как, например, организованы библиотеки элементов в Пикаде. Есть 1 файл библиотеки. В нем может быть сколько угодно символов, корпусов и элементов. Каждый из этих объектов без проблем добавляется, редактируется, удаляется, переименовывается. Одну такую библиотеку может использовать сколько угодно проектов. И никакого засорения папки bak'ами и прочим хламом.
Имхо, отличная реализация. Как считаете?

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

[2VMS]

Позвольте немного встрять. Приведу пример из моей электронной области. Как, например, организованы библиотеки элементов в Пикаде. Есть 1 файл библиотеки. В нем может быть сколько угодно символов, корпусов и элементов. Каждый из этих объектов без проблем добавляется, редактируется, удаляется, переименовывается.

Раз уж затронули мой любимый ПИКАД, то и я встряну. Но в ПРОТЕЛЕ или ОРКАДЕ используется понятие ПРОЕКТ, где все составляющие ПРОЕКТА: схема, печатная плата, библиотеки обединены общим проектом, но имеющие каждый свои файлы. Поэтому в каждом САПРе свои подходы к этому вопросу. Если в девятой или десятой версии КОМПАСа будет введено понятие ПРОЕКТ, то это обрадует одних, но опечалит других. Или я не прав?