Комментарии 47
А профессиональные системы разработки КД не используете?
Вещь интересная, но обычно использование скриптов по умолчанию отключено и даже запрещено.
И да, забыли про ГОСТ Р ИСО/МЭК 26300-2010, да пока всё ещё не обязателен к исполнению, но все же.
Ещё напомню, что были внесены изменения в ГОСТ Р 7.0.97, откуда было удалено использование проприетарных шрифтов и рекомендовано использовать свободные.
Все это из другой области и не имеет отношения к ЕСКД.
Инструкции не пишите?
РЭ не пользуетесь?
В ЕСКД аналогичные требования к проприетарным шрифтам вводит ГОСТ Р 2.105-2019 см. пункт 5.5.1
Никто не утверждает, что обязательно использовать ГОСТовские шрифты. Это вообще мелочи жизни. ГОСТ 2.105 в 5.1.1 - рекомендует использовать "имеющиеся шрифты". Что вообще можно трактовать и как возможность использования какой нибудь "вязи арабской". Но мы же серьезные люди!!
Для технических документов, типа таблиц, схем - мне лично больше нравится ГОСТовский шрифт. Для текстовых РЭ и инструкций, обычно, применяю Times New Roman 14.
Это элементарно меняется в шаблоне и на работу макросов никак не влияет.
:)
В этом ГОСТ нет п. 5.5.1. Есть 5.1.1 который давно уже поправлен, и есть примечание которое предупреждает пользователя о том, что TNR не будет на российских ОС. Запрета использовать другой шрифт нет.
Самое интересное, что как правило VBA рабоает с приложением через COM сервер, поэтому его легко заменить на Python или С#.
В принципе, да.
Однако, еще один плюс VBA в том, что если нажать волшебную кнопку "Запись макроса" и начать делать с документом всякую ерунду - во встроенной IDE появляется тело функции = текст программы, содержащей базу всех действий, которые мы хотим совершать над документом. Далее, ее остается только привести в порядок. И не надо запоминать всякие встроенные константы, методы и конструкции.
Это, на мой взгляд, ускоряет реализацию идей автоматизации документа.
Стандартные страницы документа ЕСКДСлегка передёрнуло. Простите.
А в LibreOffice draw можно сотворить нечто подобное? Пытался "записать макрос" и не смог.
А почему Вы решили заполнять документы MS Word из Word'а? Столкнувгись с этой же проблемой мне показалось более простым решением заполнять из Excel'а. Так же через макросы VBA, но там данные прокидываются через функционал закладок. Т.е. в Word'е встраиваются закладки, а макросом этим закладкам присваиваются данные из таблицы Excel.
Rem -= Открываем файл скопированного шаблона по новому пути и заполняем его=-
Set Wapp = CreateObject("word.Application"): Wapp.Visible = False
Set Wd = Wapp.Documents.Open(ИмяФайла)
NameOfBookmark = arrСсылкиДанных(1)
ContentOfBookmark = Worksheets("Данные для проекта").Cells(3, 3)
On Error Resume Next
UpdateBookmarks Wd, NameOfBookmark, ContentOfBookmark
Dim ContentString As String
For i = 4 To Кол_воЭл_овМассиваДанных Step 1
If Len(arrСсылкиДанных(i)) > 1 Then
NameOfBookmark = arrСсылкиДанных(i)
ContentString = CStr(Worksheets("БД для АОСР (2)").Cells(i, НомерСтолбца))
If ContentString = "-" Or ContentString = "0" Then ContentString = ""
ContentOfBookmark = ContentString
On Error Resume Next
UpdateBookmarks Wd, NameOfBookmark, ContentOfBookmark
End If
Next i
Rem -= Обновляем поля, что бы ссылки в документе Word так же обновились и приняли значение закладок, на которые ссылаются =-
Wd.Fields.Update
Rem -= Сохраняем и закрываем файл =-
Wd.SaveAs Filename:=ИмяФайла, FileFormat:=wdFormatXMLDocument
Wd.Close False: Set Wd = Nothing
Sub UpdateBookmarks(ByRef Wd, ByVal NameOfBookmark As String, ByVal ContentOfBookmark As Variant)
On Error Resume Next
Dim oRng As Variant
Dim oBm
Set oBm = Wd.Bookmarks
Set oRng = oBm(NameOfBookmark).Range
oRng.Text = ContentOfBookmark
oBm.Add NameOfBookmark, oRng
End SubЧего только не придумают чтобы не использовать LaTeX. См. пакет eskdx.
Да это же мрак мрачный. :))) Не, это не наш путь. Неудобно.
Мрак мрачный пытаться набирать в ворде структурированный текст более 2ух страниц, в инструменте, где форматирование и вид документа зависит от версии ПО, подключенного принтера, погоды в конкретном месте офиса, в инструменте, где невозможно управлять положением рисунков, таблиц, подписей к ним, где работа напоминает борьбу с инструментом. О каких удобствах идет речь?
Лучше бы поддержку скриптов на JS бы сделали бы.
JuSt for fun?
Для врачей разных народов, владение латынью обязательно. А для программистов разных языков программирования JS тоже обязательно, в общем просто приходится с ним иметь дело. А VB навязывание какое то. Например технологии IOT сейчас осваивают JS. Даже есть пословица: "Все что может быть написано на JS, обязательно будет написано!".
Сомнительное утврждение, на мой взгляд. То что JS сейчас стал использоваться где надо, и где не надо, вовсе не осзначает, что его обязаны знать все, кто занимается программированием. Желательно, может быть. Но обязательно - это вряд ли. Впрочем, относится это вообще к любому популярному языку программирования, будь то Phyton, C++ или Java к примеру. Хорошему программисту скорее важнее правильно выбирать язык под задачу, нежели ставить костыли из разных ЯП, потому что так проще в текущий момент. Иле того хуже - чтобы демонстрировать свою сопричастность мэйнстримам.
Вы не поняли, ОБЯЗАТЕЛЬНО это не в смысле принуждения, а в смысле того что это факт знания. А о факте я говорю о том что людям просто приходится с ним иметь дело. Всем программистам ПРИХОДИТСЯ с ним иметь дело, даже если они этого не хотят.
А в корпоративном секторе JS используется вместе с Node.JS, даже если в задачах разработки нет продукта на JS.
А суть в том что библиотеки по коррекции ошибок, сборщики пакетов, проверки типов, сравнения данных, конроль версий, обновление библиотек, и прочаая рутина автоматизации кода делается на JS как правило.
Даже если ты не хочешь делать на JS, то это ни кого не интересует, открытые библиотеки в свободном доступе для выполнения разных задачь как правило на JS.
А суть поговорики жаль что Вы не поняли. "Если может быть написано на JS. То обязательно оно будет написано на JS" и не потому что это кому то делать не чего. А потому что это упрощает и избавляет от многих проблем.
А раз вы тут со мной спорите, то значит Вы не занимались вопросами автоматизации в программировании.
А более того Adobe уже разработала и дорабатывает Photoshop на JS. И она его разрабатывает не как лижбы работало. А с поддержкой обработки данных на GPU, с работой компилируемого кода в браузере на WebAssebly. Т.е. WebPhotoshop будет по скорости аналогичен десктомному. А потом будет переделывать и другие свои продукты на JS.
Вы наверно не понимаете, веббраузер постепенно превращается в операционную систему для программ. До этого далеко, но важность JS осознают большинство разработчиков и уже сейчас без него не куда.
Так и я не про принуждение, а про факт знания. Приходится, не потому что надо, а потому что многие по некомпетентности пихают решения на JS, туда где он не особо и нужен. А почему пихают? Потому что язык слабо типизированный, прощает неграмотность программистов, на начальных стадиях (что потом превращается в жуткую головную боль), и этим удобен для решения многих по началу легких задач. Я не великий специалист по Node и корпаративному софту, но тем печальнее для этого самого софта, так как быстрота создания решения, очень быстро перекрывается необходимостью поиска костылей, для всякого рода специфичных задач, которые надо как то в этот Node потом добавлять. Вообще странно, когда корпоративные решения на интерпретируемых языках пытаются решать. Чревато потом огромными доп. затратами на расширение аппаратной части.
Что до моего знания автоматизации. Я более 25 лет занимался автоматизацией различных процессов в госструктурах. Еще более 6 лет, уже в самостоятельном режиме, занимаюсь автоматизацией построения чертежей для станков чпу под CorelDraw и всякой типографической автоматизацией, там же. Как раз на этом самом VBA. Крайне не люблю этот язык, но у него огромный плюс по сравнению с С#, для построения плагинов - намного более гибким к изменениям в API оказался. Поэтому и продолжаю работать с ним. А во время работы в госструктурах, делал схожую автоматизацию в офисе майкрософта, пока не купили СЭД. Так что - о чем говорю, знаю не по наслышке, так как в программировании я уже более 30 лет, и програмировать на С++ начал ещё под DOS в 89 году.
Про Adobe и технологию WebAssemble, так кто против то? Это нормальное направление использование VM, но причем тут JS? Очень сомневаюсь, что сам код написан именно на JS.Хотя как по мне, так вся эта надежда на онлайн инструменты ещё та потенциальная бомба. Перекроют каналы, или просто упадёт интернет, и работай как хочешь. Десктоп и коробочные версии, всё таки понадёжнее, как по мне.
Ну а по поводу вывода, что всё что можно написать на JS надо писать на JS, то даже спорить не буду. Я так не считаю и думаю, что десктоп приложения никуда в ближайшее время не денутся, так же как никуда не денутся и компилируемые языки программирования, которые куда как удобнее и надежнее JS для серьезных и высоконагруженных приложений, нежели JS и даже Phyton. Очерендная попытка натянуть сову на глобус, котрые я пережил уже не один десяток.
Новый Фотошоп он новый не в том смысле что новую версию делают на js. А в том что это параллельная версия фотошопа. Он будет работать в браузере, а при необходимости в браузере Вы наживаете кнопку установить, и эта веб страница устанавливается как обычная программа. Внешне не отличишь. На уровне кода JS он будет автономен от интернета.
Ознакомьтесь с отечественным софтом "Мой офис" это аналог MS Office. Самые обычные программы. Только внутри написанные на JS и Html.
В любом проекте есть 2 этапа. 1. Режим старт аппа, сделать на коленке с ошибками, но чтобы работало. 2. Этап, сделать правильно, с типизацией и прочее. Если бы многие проекты делаются сразу с 2го этапа то тесты вообще бы не были сделаны ни когда.
Это когда например ваши дети будут собираться на утренник. И организатор создает группу в ВК чтобы все было в курсе расписания и прочего. То по Вашей логике, организатор ладан создавать отдельный сложный сайт. JS это язык для стартапа. Где надо быстро запустить что либо. Поэтому все стартапы будут держать на js.
Уже сейчас ВК, Почтовики, работают без интернета. Вы можете письмо написать в нём и нажать отправить, а отправится когда появится интернет. Я не пробывал, но говорили что должно работать.
Что то вы уводите в сторону. Я изначально вам и так сказал: мое мнение, что под разные задачи, уместно использовать разные языки. А не пытаться из одного, сделать сверхуневерсальный. Не выйдет, так как он сразу станет и сверхгромозким и сложным. И тогда смысл его использования пропадает. Я не слишком знаком с JS, не буду врать, но и из того, что успел освоить вижу, что как раз его разработчики наворотили по мере возрастания его популярности много чего, что не идёт ему на пользу. Само собой, что его можно использовать и для десктопов, и бз привязки к сети. Вопрос только зачем? Просто потому что можно использовать специалистов, которые до этого писали для браузеров? Ну, в ряде случаев, для небольших задач вполне сгодится, хотя конечно обычно выходят монструозные приложения на сотню мегабайт, которые будучи откомпилированы из С++ занимали бы от силы один-два. Это уже к вопросу того, насколько правильно используются программисты и насколько правильно ведётся продакшен планирование на перспективу.
Я бы например выкинул к чёрту автоматизацию в Corel на VBA, но к сожалению - альтернатива ещё более печальна. Поэтому что есть, то есть. Но вот онлайн версию своих разработок придётся писать на JS, если решусь на этот кошмар по переходу в независимую от Corel плоскость.
JS не воротили, JS 100 подумают что бы чтото добавить туда. Просто у этого языка другая концепция. Функция это объект. А так там нет ни чего лишнего. И сам JS в первую очередь приравнивают к компилируемому коду. Т.е. в него намеренно не вводят типизации, интерфейсы и прочее, так как это проблема разработчиков а не браузера. Если требуется корпоративное приложение писать или как то МОЙ ОФИС то разумеется пишут на TypeScript. Еще раз повторю, что JS 100 раз подумают, чем чтото новое добавить. В отличии от другого языка где пофиг что добавлять, где после компиляции все равно будет лишнее выкинуто.
Язык JS для десктопа используют по одной причине: программу придется писать 1 раз. Это достоинство перекрывает все остальные достоинства других языков. Разумеется если приложение расчитано на интерфейс пользователя. Лучше написать 1 приложение, чем 5: Web, Windows, Linux, Android. Спрашивается какое приложение пострадает под какую платформу, все ли приложения под платформы будут качественными?
Давным давно жил был SilverLight как универсальная платформа. Но его закрыли, так как JS лучше. Flash закрыли по той же причине, он тоже универсальная платформа.
А МойОфис написан на JS потому что у него ест Web версия, которую можно встроить в свой CRM например и установить на свой вебсайт, и все документы могут работать онлайн в облаке одновременно с несколькими юзерами сразу в одном документе.
JS интерпретатор более производительный и емкий чем VBA. У JS есть проблемы, возможно что то переделают. Но JS развивается быстрей чем что либо еще. А если это так, то в ближайшее время он обойдет другие языки. Можно уже найти компиляторы в x86.
Это сейчас уже есть стандарты JS, а я вполне себе помню времена, когда там был полный хаос и разброд и разные браузеры один и тот же код исполняли совсем не однотипно. Ну да ладно, чего про те времена говорить. Язык действительно развился, и популярен. Но ещё раз говорю - популярен он не за свою универсальность, а за то, что очень многое прощает на начальных стадиях разработки. Чем очень сильно снижает на самом деле уровень профессионализма программистов в целом.
Что до вашего высказывания что на JS десктопное приложение придется писать один раз, то это как? В смысле, что написал, оно не заработало и начинай писать на чём то другом, чтобы потом не мучаться? Почти любое современное приложение расчитано на GUI, и само собой требует серьезного объёма по дизайну и сопровождению этого интерфейса. Но считать, что JS при этом даёт какие то особые приимущества (за счёт DOM модели и CSS, что ли?) перед другими средами и языками, это немного неверно. Почти все продвинутые среды программирования двано имеют визуальные редакторы, которые сравнительно просто увязывают внешний вид, расположение контролов и код обработки. JS тут не лучше и не хуже. А вот то, что придётся учитывать специфику работы в песочнице и вопросы безопасности, это уже может в ряде случаев иметь куда более весомые аргументы в разработке десктопного софта.
Ну а сравнивать VBA и JS имхо не совсем удачная мысль. Первый уже можно сказать много лет как заброшен майкрософтом и скорее живой труп. Ну а JS не слишком то дружен с COM+ , чтобы его рассматривать как серьёзную альтернативу именно под Windows. Поэтому в автоматизации всё больше смотрят на C#, но и там свои проблемы.
Я программист на C# и XAML.
И знаю что приложения бывалют разные: Консольные, сервисные, серверные, оконные(интерфейс).
Разумеется использовать JS для всех приложений кроме оконных глупо. но в оконных приложениях, это имеет большое приемущество.
(Это Вы мой отзыв минусовали? :))
(Ну раз майрософт забросила VBA, значит были причины).
Каждое оконное приложение состоит из кода: бизнес логики, интерфейса, окружения. Так вот на JS можно писать бизнес логику и интерфейс, это (>90% кода для приложения), а код окружения(под линукс, виндовс и прочее) пишится отдельно, причем этот код достаточно писать 1 раз и он не будет менятся в процессе развития приложения.
JS не лучше и не хуже в плане возможностей стилей и интерфейсов. У WPF можно кнопку в виде звездочки сделать, причем она будет по доступности настоящей кнопкой. Но JS покрывает хорошо всякие платформы.И если нет потребностей по дизайну делать звездочки вместо кнопок, то выгодней испльзовать JS.
У меня такое ощущение, что спорят 2 программиста в технологии которые оба мало разбираются в ней, но те представления которые имеют находятся с разных сторон. Вы пообщайтесь с разработчиками яндекс на JS, или разработчиками Мой офис.
Они бы Вам рассказали бы что писать настольную версию Мой офис на C#, это дополнительные расходы, нужны создавать отдельный отдел программистов. А если сказать иначе, то нужно увеличивать штат программистов в 2 раза.
Разумеется когда я буду писать прогу под Windows я выбиру C#.
Но если надо писать под вебплатформу и под Windows, то тут статет вопрос чтобы писать 1 раз сразу на обе платформы. Я разве Вам говорил что под Windows лучше JS? Я говорил что JS лучше как универсальная платформа.
А если мыслить дальше, то под Windows уже написано то что можно было написать. А под JS будут писать, так как JS расширяет покрытие.
Раньше C# хотел вылезти в веб, но потом Silverlight закрыли. А значит JS будет лезть в десктоп. Уже сейчас JS можно управлять USB устройствами без драйверов, с прямым доступом к устройству. На текущий момент оптимизируют доступ сайтов к доступу файлов диска. Чтобы и безопасность сохранить, и при этом дать доступ приложению сайта работать с файлами.
В 99 версии хром появится возможность использовать сайты в оконных приложениях полностью используя панель заголовка окна по своему усмотрению, т.е. в панели заголовка можно будет распологать кнопки, строку поиска и прочее.
JS прощает ошибки, разумеется так должно быть.
потому что не надо путать JS как платформу, как синтаксис и как возможности.
Я называл JS подразумевая платформу. Т.е. под JS подразумевал JS и TypeScript. Сам же JS это должен прощать все, так как в этом случае стоит приоритет пользователя, у пользователя должно работать плохонаписанный код. А чтобы пользоватся возможностями синтаксиса, проверок, то надо использоват TypeScript. В яндекс и в мойофис пишут на JS. Но они же пишут на JS через TypeScript. Т.е. на чистом JS они не пишут. Просто это подразумевается по умолчанию как очевидность. Так как с точки зрения платформы(окружения) это одно и тоже, а с точки зрения проверок и синтаксиса это разные вещи. Поэтому когда говорят о платформе то подразумевают что TypeScript это тот же JS.
Ну, значит мы просто немного не поняли друг друга, учитывая что формат общения всего лишь комментарий, без развёртывания своей мысли в простыню на несколько страниц.
Я в принципе про то же и писал: каждой задаче - свой инструмент. Если задача ориентирована на сеть (интернет), то логичнее сейчас не городить огород на десктопе, а использовать браузер. Но, если исторически задача решается на десктопе и в офлайн, то обычно онлайн решения проигрывают, в силу громозкости исходной задачи (например CAD или те же графические редакторы). Какие-то возможности вполне уже нормально реализуемы и на JS благодаря возможностям часть перенести в WebAssemble и используя возможночти GPU, но большинство вопросов всё таки более привычно и быстрее (да и надёжнее), решаются в десктоп решениях, и попытки притянуь это всё в браузер, сродни натягиванию глобуса на известно кого.
Ну а что до автоматизации десктопов через скриптовые языки, опять же надо понимать, какие инструменты проще для разработчика того, что автоматизируется. Тут при всех минусах VBA (просто чудовищных), есть один простой но огромный плюс - он заточен под COM+, и притянуть туда почти любую библиотеку из зарегестрированных в Windows, не то что просто, а очень просто. Если бы это так же фантастически легко решалось в каком то другом языке, то его бы давно уже использовали, а не продолжали "тянуть осла за уши"! JS тут ещё долго не будет достойным конкурентом, так как для его использования мало того что надо как то движок в свой софт добавить, так и подготовить интерфейсы под JS. Phyton ,LUA и прочие среды - аналогичная ситуация. C# - немного лучше, но жесткая привязка к версии API исходного софта, почти сводит на нет все преимущества. Что ещё можно использовать столь же удобно - даже не знаю. Поэтому, я думаю, в плане автоматизации у серьёзного софта ещё довольно долго особых конкурентов для VBA не будет.
ЗЫ. Во первых, я никогда не минусую оппонентов, тем более когда их точка зрения обоснована, пусть и не совпадает с моей. Во вторых, я тут чисто читатель и моя карма не дает таких возможностей. как голосовать за или против комментариев. Это не я минус влепил. Честно.
Спасибо! Это очень полезная статья! Очень жду продолжения!
Честно почему нельзя в компасе сделать свои правила проверки основной надписи, оформления таблиц, размеров. Работа бы стала намного приятней
Почему нельзя? Можно. Кто мешает то?
Кстати перспективная тема, дарю идею - передача текста макросом с привязками в файлы DWG/Компасс
А у меня есть связка с AutoCAD. Через атрибуты блоков.
где можно почитать об этом? не про вставку таблички, а про вставку/замену отдельных, заранее настроенных, что бы не слетало форматирование, блоков текста?
В автокаде?
да, как подтягивать текст в Автокад через макрос.
Поищу по сусекам. Если найду - опишу в следующей статье. (С автокадом давно не работал, архив надо посмотреть).
Про большие фрагменты текста - не помню точно, что там было у меня - но точно был такой подход:
Блоки основной надписи содержат атрибуты, имя которых соответствует названию переменной/поля, такое же, как содержится в том же ворде. Так как я хотел, чтобы распознавание полей автозаполнения в автокаде было автоматическим, то я при анализе блоков автокада принял умолчание - "если атрибут начинается с буквы "v" то это переменная, которую надо заполнять из внешнего источника, а именно Excel-файла, и все атрибуты с таким именем в любом блоке чертежа будут одинаковыми. Причем обрабатываются все блоки, как на вкладке Model, так и на всех вкладках Layout.
Табличные документы - каждая строка идет как один блок. Он заполняется через Excel-файл: выделяется набор имортируемых строк (с листа Excel - должно просто совпадать количество столбцов, форматирование не имеет значения) и после вызывается макрос, который лезет в Excel и по количеству выделенных строк создает блоки и в них помещает текст.
По текстовым документам - кажется аналогичный был подход, но с постраничным импортом из Word.
Последние два пункта неактуальны, так как табличные документы переехали в Visio, а текстовые - в Word.
Т.е. для автокада актуально только заполнение основных надписей на чертежах, типа поэтажных планов.
Поищу по сусекам. Если найду - опишу в следующей статье. (С автокадом давно не работал, архив надо посмотреть).
Буду благодарен =) благо тема сейчас актуальная.
Т.е. для автокада актуально только заполнение основных надписей на чертежах, типа поэтажных планов.
Вот тут не соглашусь, т.к. на однотипных чертежах/схемах, например на дефектах, здорово экономит время, когда у тебя рисунок один и тот же, а надписи разные. Потом никто же не запрещает чертить условные схемы линейных объектов с привязкой к проценту выполненных работ, при условии что мы привязаны к пикетам. Или же рисовать по отметкам профиль трубы и земляных масс. Опять же вывод подготовленных текстовых спецификаций.
Наверное проектировщику так нельзя относится к документам, но вот уже ПТОшнику - можно и даже нужно, т.к. все то, что сэкономит время должно экономить время
Автоматизация разработки конструкторской документации средствами VBA