Способ проектирования в среде Компас и программа для его осуществления

Автор Валерий Изранов, 27.04.22, 09:03:10

« предыдущая - следующая »

0 Пользователей и 1 гость просматривают эту тему.

СВ

 Сия умная мысль (про учеников 1-го класса) по сути правильная, по ситуации - не к месту.
И пример нужен не про письмо, а про математику: она уже всеми выучена, вопрос идёт о практическом применении к расчётам: АСКОН создал свою систему, вы - свою. И то, и другое - не идеал. Давайте совершенствовать!!!

IgorT

Цитата: Валерий Изранов от 29.04.22, 08:32:53IgorT
Ученики в 1 классе просто изучают письмо и чтение.
Понимание зачем это нужно приходит к 10 классу.

Монитор конечно нужно купить. Да и Компас бы освежить.
Про первый,десятый и понимание. Я тупой, поясните свою умную мысль, что сказать то хотите?

Про монитор. Ну да, купите мне монитор! Побольше!  И Компас обновите.
+ Благодарностей: 2

Кирямба

Цитата: IgorT от 29.04.22, 08:18:43для работы программы требуется экран не менее 24 дюйма с разрешением 1920х1080..."
А почему именно 24"? Например, я прекрасно вижу и на 17", но с 1920х1080. Диагональ монитора влияет только на шаг пикселей. Есть даже 17-дюймовые ноутбучные 4K мониторы, но можно и 40-дюймовый 4K-телевизор подключить.

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

Валерий Изранов

24 дюйма-это конечно условно. Можно и 17, продвинутые используют два по 24 дюйма.
Значительно-в разы-сокращается время "перематывания картинки".

Цитата: Кирямба от 29.04.22, 21:06:51По сути, нужен инструмент, который мог бы по необходимости библиотечные файлы собирал бы в папку проекта и изменял путь к файлу с абсолютного на относительный. И наоборот.

Именно это и выполняет обсуждаемая в теме программа АгентК016.

СВ

 Т.е. ссылки на переменные между файлами будут именно внутри созданной папки? Это проверено?

Валерий Изранов


Валерий Изранов

Цитата: Валерий Изранов от 27.04.22, 09:03:10У широко известного способа проектирования, при котором компоненты сборки размещены в многочисленных сторонних папках, при всех его неоспоримых преимуществах есть существенные недостатки.
1 сторонние папки, созданные когда-то очень давно никогда в будущем невозможно ни переименовать, ни перенести в другое место.
2 уязвимость: при повреждении одной сторонней папки все сборки, в которых используется компонент из нее так же будут повреждены.
Предлагается способ проектирования и программа для его осуществления, при котором все компоненты сборки располагаются в одной с ней папке.
Полная формула предлагаемого способа проектирования приведена в Руководстве конструктора.
Помощь в создании программы была получена от Михаил88.
Все здесь.
https://disk.yandex.ru/d/g2iIgcP-C-a1pg


Просто напомню,что обсуждается в этой теме.
В связи с праздниками несколько дней я не смогу появляться на форуме.
До встречи!

Валерий Изранов

Первомайские праздники как-то быстро прошли. Пора за работу.
До сих пор не объявился Пионер - человек, проверивший работу программы АгентК016 на практике.

Очень точно в своем сообщении способ проектирования оценил Кирямба.

Цитата: Кирямба от 29.04.22, 21:06:51В целом, если копировать все нужные файлы из библиотеки в целевую папку проекта, то будет разрастаться число копий, они будут занимать место и в них сложно будет вносить коррективы. С другой стороны, эти недостатки являются и достоинствами - папка проекта самодостаточна и можно локально изменять входящие в нее файлы, не боясь испортить библиотеку.

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

Все здесь.
https://disk.yandex.ru/d/g2iIgcP-C-a1pg

СВ

 Другими словами, файлы проекта, собранные вашим способом, будут "весить" в несколько раз больше, чем изначальный, это хотите сказать?

Валерий Изранов

СВ, да нет конечно же.
Файлы проекта собранные в одну папку "весят" ровно столько же, что и разбросанные по родовым папкам.
Дополнительный расход памяти на диске будет при использовании этих файлов во втором проекте.

СВ

 Тогда возникает противоположная проблема: связь с входящими исчезает. Входящие изменились - и что теперь? Это серьёзно!

Валерий Изранов

СВ, суть предлагаемого способа в том, что Главная сборка и ВСЕ ее компоненты находятся в одной папке.
"Внешних" никаких связей нет вообще.

СВ

 Типа - редактируемый Комплектовщик? Маловато будет, без связей...
Разве что если во всём лучше Комплектовщика...

Валерий Изранов


YNA

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

СВ

Цитата: Валерий Изранов от 05.05.22, 11:23:13... связи это что и зачем они нужны.
Связи - двух типов.
Первый: входящие детали и узлы. С этим понятно: если входящие изменили (хотят изменить), то нужно проверить как это отразится во всех местах применения.
Второй: к примеру, какие-то переменные одной детали/узла ссылаются на переменные другой детали/узла. Сейчас при переименовании эти ссылки будут идти на "старую" деталь и может получиться всякое безобразие. Не думаю, что вы исправили Компас в этом плане. Предположу, что про этот тип связей вы и не задумывались...

СВ

Цитата: YNA от 05.05.22, 11:35:00Тут видимо всё дело в стиле работы и привычках пользователя.
Лично мой стиль - ни когда не заимствовать файлы из другой папки другого проекта!
...
Исходя из этого появляется понятие применимости библиотеки в зависимости от стиля работы.
Есть немало мест, где заимствования только приветствуются, и это в целом является плюсом. Вот эту ситуацию я и обрисовываю Валерию.
А так - да, ситуация, где его продукт пригодился бы - редка. Разве что удобства переименовывания ...

Валерий Изранов

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

СВ

 Валерий, мы обсуждаем ситуацию, когда
Цитата: Валерий Изранов от 28.04.22, 08:09:51Компоненты могут быть в одной папке со сборкой, могут быть разбросаны по другим папкам ...
т.е. понабрали файлов из разных мест. А у них СВОИ связи! В "старых" местах. Да пусть и в новых, неважно. Потом запустили переименования и вот уже диаметр вала не видит ссылку на диаметр втулки - потому что у втулки новое имя. Параметризация сбивается ...

graphdark

ИМХО. На самом деле, считаю, что это просто хороший тон конструктора. Когда под каждую сборку-своя папка и в ней все файлы по сборке. В одной сборке в 3х подсборках у меня была втулка. И в каждой папке была эта втулка с чертежом. Да тофтология, да места дофига. Но. Я любую подсборку папкой отдам кому угодно, я имею весь проект хорошо структурированный. А у коллег-нет, на винте ад и израиль. Раньше, я писал нечто подобное без привязки к САПР. Помимо Компаса в проекте всякое было просто.