Сделай свою работу в Solidworks эффективнее

[ssv22 16]

Интересная статейка, может помочь))) кому-нить

..

А можно еще и макруху доработать, чтоб и в заметку сразу текст из свойства пихало

Прикрепленные файлы

Barcode.zip ( 8,25 килобайт ) Кол-во скачиваний: 3

А это для чего? (- Barcode.zip) ?

[streamdown 1 565]

А это для шифровки текста в баркод чел макрос для ворда/экселя/аксесса написал, там BAS - глядишь, можно и в SWP загнать.

Но можно и шрифт на просторах инета просто скачать.

[ssv22 16]

А это для шифровки текста в баркод чел макрос для ворда/экселя/аксесса написал, там BAS - глядишь, можно и в SWP загнать.

Но можно и шрифт на просторах инета просто скачать.

Дык, это вроде и в прошлом веке было известно...

[streamdown 1 565]

ssv22

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

[ssv22 16]

ssv22

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

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

Какой-то философ сказал примерно так:

"Если у тебя есть одно яблоко и у меня тоже одно, и если мы обменяемся ими, мы разойдемся каждый со своим одним яблоком. Но, если у тебя есть идея (мысль) и мы обменяемся ими, то уже разойдемся каждый с ДВУМЯ идеями".

[ssv22 16]

Да. Я специально сравнивал при обработке одной и той же сборки, примерно из 1500 компонентов, для своей спецификации. dll-ка отрабатывала за 0,3 сек, а *.exe за 3.2сек.

Shvg, извини, но истина дороже:

ИМХО такое сравнение - частный/однобокий случай

1) речь идет только об SW и приложениям к нему; тогда уж надо написать кучу плагинов на уровне и DLL и EXE и все их сравнить на "скорость"!

Вот тогда можно будет говорить о преимуществах одного над другим...

Но это нереально и бессмысленно, ИМХО.

2) осмелюсь сказать, что программа, написанная на Ассемблере будет работать на порядок быстрее, а в машинных кодах и еще на 1-2 порядка быстрее;

3) можно посмореть тут : <noindex>http://www.4synapse.com/ru/article/dll---d...-chast-1_5.html</noindex>

"...

**

(1.2.) Зачем нужны DLL?

(1.2.1.) Предпосылки к появлению DLL

Свою историю DLL ведут с средины 60-х годов прошлого столетия, однако по-настоящему широкое распространение динамически линкуемые библиотеки получили после появления операционной системы Windows.

Замечание:

Крис Касперски ("Техника сетевых атак", 2001) пишет: "Именно в MULTICS (1965-69 гг.) появилась возможность динамического связывания модулей в ходе выполнения программы, более известная современному читателю по этим пресловутым DLL в Windows. Такой прием логически завершил эволюцию совершенствования оверлеев, обеспечив единый, унифицированный интерфейс для всех программ, позволяя сэкономить значительную часть оперативной памяти и процессорных ресурсов..."

По крайней мере, доподлинно известно, что операционные системы Windows 3.1/3.11 уже содержали программы, использующие DLL. В связи с тем, что в те времена емкости оперативной памяти и жесткого диска были значительно меньше, чем сейчас, использование DLL предоставляло ряд преимуществ:

экономия дискового пространства за счет многократного использования кода (reusing). Если приложения используют один и тот же код, нет необходимости поставлять его в коде каждого приложения. Достаточно разработать DLL.

экономия физической памяти (RAM) за счет загрузки в нее единственного экземпляра DLL. Именно тогда появились счетчики ссылок пользователей DLL - при каждом вызове функции ОС проверяет наличие загруженного в память экземпляра библиотеки. В случае положительного ответа счетчик ссылок пользователей данной DLL увеличивается на единицу. Если же экземпляр данной DLL в памяти не обнаружен, то операционная система загружает файл в память и присваивает счетчику значение "1". Механизм разделения кода носит название memory mapping (отображение в память). При выгрузке DLL из памяти уменьшается значение счетчика числа пользователей, в случае равенства его нулю DLL немедленно выгружается.

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

Самое удивительное (время не стоит на месте!), что ранее политика Microsoft позволяла (и даже приветствовала) размещение DLL в системных директориях (таких как Windows\System, Windows\System32).

Это порождало периодические проблемы конфликта версий при замене DLL (см. раздел "DLL Hell").

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

...

(п.1.3.) Что лучше: один EXE-файл и никаких DLL или компактный EXE-файл и много DLL?

Вероятно известный вам Бьерн Страуструп в своей книге "Язык программирования C++" дает после каждой главы ряд полезных советов, один из которых звучит так: "Пользуйтесь здравым смыслом...". Этот же совет можно предложить и при использовании DLL в программе.

Если вы считаете, что вам нужна DLL - сделайте ее, если нет других причин сделать иначе. Разумеется, не стоит каждую отдельную функцию размещать в DLL и затем экспортировать (хотя это и возможно). Со временем такой проект превратится в трудноуправляемого монстра, инициализация которого будет занимать порядочное время. Правда, экспортирование только одной функции из DLL может быть продиктовано следующей логикой: серверное приложение сканирует определенную директорию на предмет нахождения в ней файлов с определенным расширением. В случае нахождения такого файла сервер полагает, что это - DLL, которая экспортирует функцию с определенным именем (скажем, CplApplet или mexFunction), и, соответственно, он сможет ее загрузить. Таким простым образом возможно динамическое расширение функциональности приложения - именно такой подход проповедуется в случае Панели управления (Control Panel) и системы MatLab (Matrix Laboratory).

Не стоит также бояться использовать те плюсы, которые может принести использование DLL в программе (см. раздел "Что такое DLL").

Логически отделенная библиотека, часто используемая в совместных проектах - верный кандидат на размещение в DLL. Это позволит:

- поставлять различным клиентам приложения с различной функциональностью;

- модифицировать (оптимизировать, изменять) код DLL без повторной перекомпиляции клиентских приложений, использующих DLL. А это значит, что при модификации или исправлении ошибки достаточно изменить DLL (сама Microsoft часто именно так и делает - см. постоянно появляющиеся пакеты Service Pack);

- разделить разработку большого проекта на отдельные, независимые группы;

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

- использовать различные языки при написании DLL и клиентского приложения. Например, клиент может быть написан при помощи m-языка (тип интерпретируемого скрипта, используемый в системе MatLab), а DLL - при помощи языка C++. Это позволит провести дополнительную оптимизацию кода без потери его качества.

Разумеется, каждая DLL требует определенного процесса инициализации и, соответственно, затрат на него. В случае наличия большого количества DLL процесс инициализации может занимать порядочное время (правда, не обязательно все DLL инициализировать сразу - см. раздел "Как приложение загружает DLL", а также необязательно вообще инициализировать DLL - ведь иногда из DLL нужно получить не код, а находящиеся в ней ресурсы, - например, в случае использования DLL как хранилища локализованных строковых параметров -см. раздел " DLL, содержащие только ресурсы").

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

Таким образом, здравый смысл - ваш верный помощник (как говорит один наш коллега - "Крайности вредны!"). Помните об этом.

Кроме того, помните, что определенные проблемы проектирования без использования DLL (например, связанные с установкой ловушек - см. раздел "Внедрение DLL и перехват вызовов API-функций") решить вообще нельзя.

Еще можно вспомнить так называемые ISAPI-расширения - высокоэффективные модули, используемые при написании Web -приложений. Ну, и, наконец, такая система как MatLab позволяет использовать собственноручно написанные и скомпилированные модули в виде DLL для повышения быстродействия работы Ваших программ. Так что использование DLL может быть продиктовано еще и вопросами оптимизации.

Подытоживая сказанное выше, можно сделать следующие выводы.

Случай использования одного большого EXE-файла:

+ относительная быстрота инициализации - каждая DLL требовала бы отдельного процесса инициализации;

+ все в одном файле (нет внешних зависимостей) - такой файл может поставляться без внешних библиотек;

- постоянное дублирование кода (за счет увеличения размера *.exe-файла);

- полная перекомпиляция при любом изменении;

- все в одной куче: отсутствие разделения реализации логики различных (по функциональному наполнению) объектов;

+ идеально для небольших проектов (утилиты, тестовые приложения и пр.).

Случай разделения EXE и DLL:

+ физическое разделение логически-независимых объектов (классов, функций и пр.). Это позволяет проводить независимую разработку и последующее тестирование подобных DLL. На момент сбора объекты будут иметь достаточно предсказуемое поведение, чтобы быть сразу же использованными другими разработчиками;

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

+ идеально для больших проектов (повторное использование кода + отсутствие его дублирования);

+ легкость update'а и замены.

А что использовать в каждом случае - это дело конкретной задачи.

4) в случае связки SW + DLL, память для DLL должен будет выделять SW; В случае EXE - выделение памяти - забота самой OS.

Т.о. чем больше DLL запущенно из под SW, тем больше памяти затребует сам SW от OS и ее (памяти) в какой-то момент может и не хватить;

5) <noindex>http://www.progz.ru/t40464/</noindex>

"

...

(5.4.) Как экспортировать функции и переменные не из DLL, а из EXE?

Немногие программисты знают об этом, но функции и переменные можно экспортировать не только из DLL, но и из EXE-файла. В самом деле, ведь формат DLL- и EXE-файлов одинаков - это обычный Portable Executable (PE) файл, и различаются они только одним-единственным битом в поле Characteristics заголовка. А раз так, то ничто не мешает нам экспортировать функции и переменные из EXE-файла точно так же, как и из DLL - компоновщик создаст в EXE-файле секцию экспорта и запишет в нее экспортируемые имена. Более того, точно так же, как и для DLL, компоновщик создаст lib-файл, который можно использовать для неявного связывания с другими модулями.

...

(5.5)Импорт функций и переменных из EXE-файла также не отличается от импорта их из DLL - достаточно подключить к проекту соответствующий lib-файл для неявного связывания. Поясним сказанное простым примером. Для простоты создадим консольное приложение со следующим кодом:

<div class=\'codetop\'>Код C++</div><div class=\'codemain\'>// TestExport.cpp : Defines the entry point for the console application.

"

6) так что ИМХО совет Бьерна Страуструпа: "Пользуйтесь здравым смыслом..." вполне имеет место быть...

PS. ничего себе: сколько я написал?! (вообще-то эта инфо у меня была уже)

[Shvg 67]

Shvg, извини, но истина дороже:

ИМХО такое сравнение - частный/однобокий случай

1) речь идет только об SW и приложениям к нему; тогда уж надо написать кучу плагинов на уровне и DLL и EXE и все их сравнить на "скорость"!

Вот тогда можно будет говорить о преимуществах одного над другим...

Но это нереально и бессмысленно, ИМХО.

ssv22, ну что ж тут поделать, извиняю.

А, если серьезно, то я говорил только об SW и только о dll, как об add-ins'e к SW. Когда я ушел с VB, тебе большая благодарность за азы в Васике, в .NET (C#) меня просто убила тупизна нетовских exe-файлов для SolidWorks, особенно для сборок. В C++ тогда я был тупей тупого (хотя и сейчас еще из крепкой породы, ну дуб в смысле, правда уже не полный ). Попробовал add-ins (dll) - результат поразил после *.exe. С тех пор ярый сторонник add-ins'ов (dll-ок). Ну, а чтобы ты меня понял, попробуй эти четыре проекта, практически один и тот же код. Надеюсь, VS у тебя стоит. Проекты C# - VS2005, SW2011SP1, C++ - VS2003, SW2011SP1. Мой результат файл MyTest.txt в архиве. Программы просто считывают сборку и подсчитывают кол-во одинаковых компонентов. В проекте на C# (add-ins) можно раскомментировать вызов формы с ListView для вывода результата.

For_ssv22.rar

[ssv22 16]

ssv22, ну что ж тут поделать, извиняю.

А, если серьезно, то я говорил только об SW и только о dll, как об add-ins'e к SW. Когда я ушел с VB, тебе большая благодарность за азы в Васике, в .NET (C#) меня просто убила тупизна нетовских exe-файлов для SolidWorks, особенно для сборок. В C++ тогда я был тупей тупого (хотя и сейчас еще из крепкой породы, ну дуб в смысле, правда уже не полный ). Попробовал add-ins (dll) - результат поразил после *.exe. С тех пор ярый сторонник add-ins'ов (dll-ок). Ну, а чтобы ты меня понял, попробуй эти четыре проекта, практически один и тот же код. Надеюсь, VS у тебя стоит. Проекты C# - VS2005, SW2011SP1, C++ - VS2003, SW2011SP1. Мой результат файл MyTest.txt в архиве. Программы просто считывают сборку и подсчитывают кол-во одинаковых компонентов. В проекте на C# (add-ins) можно раскомментировать вызов формы с ListView для вывода результата.

Вот сейчас не могу опробовать - недавно OS перустановил и VS еще не ставил.

Вернее, ставил VS2010-й, так он мне всю OS загубил - пришлось восстанавливать из образа...

Кстати, если dll-плагин уже есть, наличие на ПК VS разве обязательно? Или это для отладки?

PS. вобще-то есть у меня VS2008 Express, как думаешь возьмет он эти твои проекты?

(скачать-то я их скачаю...)

Да вообще насчет VS - у меня еще туман в голове...

[Shvg 67]

Вот сейчас не могу опробовать - недавно OS перустановил и VS еще не ставил.

Вернее, ставил VS2010-й, так он мне всю OS загубил - пришлось восстанавливать из образа...

Кстати, если dll-плагин уже есть, наличие на ПК VS разве обязательно? Или это для отладки?

PS. вобще-то есть у меня VS2008 Express, как думаешь возьмет он эти твои проекты?

(скачать-то я их скачаю...)

Да вообще насчет VS - у меня еще туман в голове...

На счет add-ins'ов. Скомпилированные в C++ подключаются просто через File->Open-> (и выбираем тип add-ins(*.dll) и указываем на нашу dll). Но тут может быть проблема с версией SW. Если она была скомпилирована в более ранней, то все должно пройти нормально. Если в более поздней, то возможно будет проблема с вызовом функций SW. Если нетовская dll, то лучше через инсталятор, так как она за собой еще много чего тянет. В справке API SW сказано, как собирать проект в VS.

Насчет VS2008Express. Проекты на C# она перекомпилирует, только, в зависимости от версии, переподключить библиотеки SW, по всей видимости, придется.

С проектами на C++ сложнее. Express, вроде как, не поддерживает ATL и WTL.

[Юрий 1]

Прошу прощения, немного не по теме, но тоже касается DLL и EXE.

Никто не пробовал вместо InProc сервера делать локальный в качестве Add-Ins-а к SW?

У меня не получилось. Получил сообщение от SW о том, что он не может загрузить...

И не удивительно. Это вообще не его функция (загружать COM сервер), для этого есть ОС.

Но, видимо, в SW этого не знают, и загружают dll сами, получая ее адрес из CLID. А может и знают, но тогда вообще непонятно, что творят и почему. Неужели и так граблей не хватает.

Если у кого есть солидовский шаблон для VS C#, киньте, пожалуйста, текст исходника проекта в личку или на yurysoft@yandex.ru, а то в справке ссылаются на сайт, а там спец. вход.

[Shvg 67]

Если у кого есть солидовский шаблон для VS C#, киньте, пожалуйста, текст исходника проекта в личку или на yurysoft@yandex.ru, а то в справке ссылаются на сайт, а там спец. вход.

А API SDK для SW разве вы не ставили? Им ставятся все шаблоны для C# и C++. Их даже Visual C# Express цепляет.

P.S. Версию SW указывайте. Шаблоны в них немного разные.

[Юрий 1]

SW 2010.

API SDK я ставил, но прочитать там блокнотом ничего не могу.

Я никогда не работал с NET. Хочу понять по коду, как мне прицепиться к SW из Delphi.

[Shvg 67]

SW 2010.

API SDK я ставил, но прочитать там блокнотом ничего не могу.

Я никогда не работал с NET. Хочу понять по коду, как мне прицепиться к SW из Delphi.

К, сожалению, я в Delphi никогда не работал.

Для SW2010 шаблона C# уже нет (дома), есть для SW2011. Разница только (по памяти) в реализации функций AddCommandMgr() и RemoveCommandMgr()

Еще может посмотреть справку по API SW (Using SwAddin to Create a SolidWorks Add-In). Это из справки API SW2008.

Using SwAddin to Create a SolidWorks Add-InYou can create a SolidWorks add-in using the SwAddin object instead of using a SolidWorks add-in wizard.When you use the SwAddin object to create a SolidWorks add-in, the add-in must include some specific functionality and code. It is also important to understand what the SolidWorks software does for the add-in. Click a link to read that section.What does the add-in have to do?What does the SolidWorks software do?What does the add-in have to do?The add-in DLL must be created as a COM Server and it must:Implement a co-creatable object that supports SwAddin.Call regsvr32 during installation. Register the add-in CLSID in HKEY_LOCAL_MACHINE\SOFTWARE\SolidWorks\AddIns and set the following registry keys:Default to 1 or 0, where 1 enables the add-in in the add-in manager so that it loads when the user starts the SolidWorks software.Description to a text description of the add-in that is displayed in the add-in manager.Title to a text title of the description that is displayed in the add-in manager.Define event handlers as needed.In its implementation of SwAddin::ConnectToSW, the add-in can:Call SldWorks::SetAddinCallbackInfo and pass the instance handle of the add-in and the object that supports the callback methods. The SolidWorks software holds onto this object and makes callbacks.Call SldWorks::AddMenuItem3 and pass the callback method associated with the menu item.Call SldWorks::AddToolbar4 and pass the callback method associated with the toolbar button.Back to topWhat does the SolidWorks software do?When the end-user starts the SolidWorks software, it: Checks the registry for add-ins.Creates an object associated with the CLSID of the add-in.Performs a QueryInterface on the add-in looking for the SwAddin object.Calls SwAddin::ConnectToSW and passes a pointer to the SolidWorks session and the add-in ID.When the user closes the SolidWorks software or disables an add-in in the add-in Manager, the SolidWorks software:Calls SwAddin::DisconnectFromSW, providing the add-in an opportunity for cleanup.Destroys the object it created with the add-in CLSID.If the end-user disables an add-in in the add-in manager, the SolidWorks software does not reload the next time the SolidWorks software starts. If the end-user closes the SolidWorks software with an add-in enabled, the SolidWorks software reloads the add-in the next time it starts.You must register your add-in before it can be used.

swcsharpaddin.zip

[streamdown 1 565]

Юрий

uses

... COMObj;

procedure TForm1.Button1Click(Sender: TObject);

var swapp:variant;

swdoc,n:idispatch;

begin

try

swapp:=GetActiveOleObject('SldWorks.application'); {пытаемся подключиться к Солиду}

except

begin showmessage('SolidWorks not run');close();end; {если не получается, выдаем сообщение об ошибке и мирно закрываем свое приложение}

end;

... //нужный код

end.

[Юрий 1]

Спасибо всем.

Это из справки API SW2008.

К сожалению, эта выдержка актуальна только для Win32.

Будем разбираться. Непонятно, где нужно (и нужно ли) регистрировать COM-серверы в NET., который не использует реестр Windows.

[ssv22 16]

Спасибо всем.

К сожалению, эта выдержка актуальна только для Win32.

Будем разбираться. Непонятно, где нужно (и нужно ли) регистрировать COM-серверы в NET., который не использует реестр Windows.

А у Вас что? (предупреждать надо...)

Если у Вас все 64х, то и справка д.б. соответствующая.

ИМХО

Причем тут SW, ИМХО надо начинать с азов (типа): "разработка собственных приложений на такой-то платформе".

Ищите специализированные сайты по программированию на 64х.

[Shvg 67]

Спасибо всем.

К сожалению, эта выдержка актуальна только для Win32.

Будем разбираться. Непонятно, где нужно (и нужно ли) регистрировать COM-серверы в NET., который не использует реестр Windows.

Давайте продолжим в другой теме, если не возражаете. <noindex>http://fsapr2000.ru/index.php?showtopic=27...st&p=368456</noindex>

[breeze 3]

Добрый день, подскажите или пошлите туда где подскажут :)

Есть многотел, с которого делается сборка

В свойствах многотела я прописываю всю лабуду, для чертежей (ну там, чертил Иванов, проверил - Петров, материал и т.д. )

Все детали, полученные из многотела перенимают свойства родителя, но в чертеже прописывается, например: "fromparent+Иванов" или "fromparent+Сталь 3". Возможно ли убрать лишнее?

Спасибо

[alexlpr 4]

добрый день.

как в макросе узнать путь к директории из которой он запущен?

что-то типа такого strDir = ExtractFilePath(paramstr(0))

[Maze 16]

Dim MyAppID As Variant

Dim Sourrce As String

Dim swApp As Object

Sub main()

Set swApp = Application.SldWorks

' Run the custom property application

Source = swApp.GetCurrentMacroPathName ' Get macro path+filename

Source = Left$(Source, Len(Source) - 3) + "exe" ' Set source filename

MyAppID = Shell(Source, 1)

AppActivate MyAppID

End Sub