Форум пользователей Visio

Форум по вопросам применения и программирования в Visio
Текущее время: 29 мар 2024, 03:26

Часовой пояс: UTC + 3 часа [ Летнее время ]


Правила форума


При размещении файлов предпочтительным является формат vsd (а не vsdx/vsdm)
Размещая ваши вложения на форуме не используйте имена файлов содержащих кириллицу, в противном случае файл будет иметь имя .<расширение файла> !

Для форматирования ваших сообщений используйте BBCodes, описание используемых на форуме BBCodes.



Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу Пред.  1, 2, 3  След.
Автор Сообщение
 Заголовок сообщения: Стандарты разработки
СообщениеДобавлено: 14 янв 2022, 02:42 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
тут буду собирать стандарты разработки, шапка обновляемая.
? - в обсуждении
V - принято


Содержимое спрятано под спойлер ↓
Спойлер:
Мастер-шейпы УГО схем
основные требования к разработке:
УГО должно иметь следующие поля:
? Prop.sp_pos - столбец спецификации: Позиция
V Prop.sp_name - столбец спецификации: Наименование и техническая характеристика (может быть скрытым и формироваться из других полей)
V Prop.sp_type - столбец спецификации: Тип, марка, обозначение документа, опросного листа
V Prop.sp_code - столбец спецификации: Код оборуд., изделия, материала
V Prop.sp_manu - столбец спецификации: Завод изготовитель
V Prop.sp_ediz - - столбец спецификации: Единица измерения (скрытый или без возможности изменения)
? Prop.sp_col - столбец спецификации: Кол-во ( скрытое, если единичный то свойство со значением 1, если линейный размер (например метраж) то формироваться из длинны и других данных (например у меня в планах спуск проводов считается в зависимости от привязки к другому элементу и установки свойства высота прокладки) )
V Prop.sp_mass - столбец спецификации: Масса единицы, кг. (не обязательное)
V Prop.sp_prim - столбец спецификации: Примечание (не обязательное)
? Prop.sp_grup - группа (раздел) в спецификации
? Prop.sp_calc - для исключения подсчета (например для обозначения существующих элементов планов или схем и для дублирующихся ,например на плане и в схеме один и тот же элемент): может принимать три значения: новый, существующий, дубликат. Существующий и дубликат разделен для того, чтобы по этому свойству существующий делать другим оттенком (обычно серый цвет), а в дубликате не делать другим цветом

? Связывание свойства с внешними данными ориентируясь на версию Visio professional
? Сопоставление имени поля с столбцом спецификации для работы макроса задается в конфигурационном файле с именем: имя_макроса.conf

Мастер-шейпы УГО планов
основные требования к разработке:
? УГО должны иметь поля как УГО схем Prop.sp_*


Макросы
? макросы в отдельном файле без шейпов Macros.vssm

Базы данных
в обсуждении

Другие требования
? Документ содержит счетчик шейпов User.count_id_shape который содержит последнее значение id_shape для создания уникального идентификатора шейпа.
? присвоение уникального идентификатора шейпа User.id_shape автоматически макросом при вставке шейпа или вручную макросом перебором всех шейпов у которых это поле отсутствует или пустое и присвоение значения.
? использование стандарного инструмента уникального имени шейпа (только ориентироваться на версию Visio 2013 и выше)


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 14 янв 2022, 17:37 
Не в сети
Ветеран

Зарегистрирован: 26 авг 2019, 21:07
Сообщений: 267
Использую Visio c: 2019
Очков репутации: 11

Добавить очки репутацииУменьшить очки репутации
nbelyh писал(а):
Да, а зачем вообще определять эти поля? Разве они не будут зависеть от организации, от проекта?
Или Вы имеете в виду, что это поля, используемые в Вашей организации?
Эти поля из спецификации и для неё же используются
Содержимое спрятано под спойлер ↓
Спойлер:
Изображение

_________________
САПР-АСУ
https://github.com/gtfox/
YouTube


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 14 янв 2022, 20:24 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
Цитата:
Prop.sp_pos - столбец спецификации: Позиция - как я понимаю, это порядковый номер строки в спецификации, и знать мы его не можем, пока её не заполним... поэтому оно тут не надо.

нет, это позиция на плане или схеме
Цитата:
Prop.sp_col - столбец спецификации: Кол-во - это количество одинаковых элементов в спецификации, и знать мы его не можем, пока её не заполним... поэтому оно тут не надо.
некоторые элементы не единичные, а например линейные (кабель, труба) и по этому это свойство нужно, а для того чтобы не проверять наличие и не писать лишнее условие то единичные тоже ставить
Цитата:
3) Остальные столбцы - соответствуют спецификации и нужны. (Я не использую массу... А примечания заполняю редко и уже в готовой спецификации, поэтому у меня этих полей нет)
почти согласен.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 14 янв 2022, 20:30 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

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

понял, добавить надо поле с выбором значений: новый, существующий, повторный
Цитата:
Для уникальных идентификаторов последние 20 лет обычно используются GUID-ы.
где почитать про них подробнее?


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 14 янв 2022, 20:44 
Не в сети
Content manager
Content manager
Аватара пользователя

Зарегистрирован: 02 окт 2009, 01:01
Сообщений: 5043
Откуда: оттуда
Использую Visio c: 1998
Отрасль: Интеграция системных интеграторов
Должность: Дизайнер по оформлению документации
Уровнь квалификации: Форматирование документов MS Word
immortal писал(а):
где почитать про них подробнее?
в справке от МС

_________________
База знаний ShapeSheet
Мой Youtube-канал @surrogate-tm
Мои трафареты


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 00:04 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
ещё наверно нужно поле группы, чтобы объединять в группу в спецификации.
и позиция может иметь 2 значения, позиция на плане (тогда значение нужно) и позиция в спецификации.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 00:21 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
Цитата:
IMHO, c данными названиями IMHO есть некоторые объективные проблемы. Например, они не подчиняются особой логике:
есть "sp_type" (полное название на английском) и "sp_manu" (необщепринятое сокращение с английского), и "sp_ediz" - колхозный транслит.
Также префикс "sp" в мире Microsoft часто используется для "share point", возможно неправильное понимание.

Еще, если назвать свойства подобным образом, они возможно не будут нормально (автоматически) связываться с данными (встроенная функция)?
Может лучше уж тогда или вообще без префикса, или "_visDM_" которые "визард" в Visio создает.

Да, а зачем вообще определять эти поля? Разве они не будут зависеть от организации, от проекта?
данные поля спецификации. Просто названия для того чтобы исключить возможные конфликты с другими шейпами которые разрабатывают другие юзеры.

Цитата:
Красным - есть у всех элементов схемы электрической принципиальной
Черным - уникальные поля
Желтым - данные из БД (или вручную)
Зеленым - отображение и нумерация
на основании этого формируется спецификация?

Цитата:
Для уникальных идентификаторов последние 20 лет обычно используются GUID-ы.
Они решают большинство известных проблем с уникальной идентификацией, для этого собственно и были придуманы, зачем использовать что-то другое?

почитал по ним скудную справку, их вообще где посмотреть кроме как из VBA? и как ручками задать?
кстти по описанию идентефикатор уникальный в пределах многих документов, из мана: "Если объект Shape имеет уникальный ID, ни одна другая фигура в другом документе не будет иметь того же ID."
интересно если я приношу документ с другого компа как это будет выглядеть?


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 00:45 
Не в сети
Content manager
Content manager
Аватара пользователя

Зарегистрирован: 02 окт 2009, 01:01
Сообщений: 5043
Откуда: оттуда
Использую Visio c: 1998
Отрасль: Интеграция системных интеграторов
Должность: Дизайнер по оформлению документации
Уровнь квалификации: Форматирование документов MS Word
immortal писал(а):
ещё наверно нужно поле группы, чтобы объединять в группу в спецификации.
полей хоть over9000 можно добавить при необходимости, надо подумать за механизм как все это добавлять фигурам
immortal писал(а):
Просто названия для того чтобы исключить возможные конфликты
Николай писал о том, что надо придерживаться единой идеологии именования полей (aнглийский/транслит/полные имена/сокращённые)
immortal писал(а):
разрабатывают другие юзеры.
до этого ещё дожить надо :)
immortal писал(а):
их вообще где посмотреть кроме как из VBA
если вы их при создании в какую нибудь ячейку не запишете то никак!
immortal писал(а):
как ручками задать?
как вы себе это представляете? Комбинация из 32 символов/цифр !!!
В первом абзаце справки было написано:
Цитата:
Gets, deletes, or makes the GUID that uniquely identifies the shape within the scope of the application. Read-only.

https://ru.m.wikipedia.org/wiki/GUID

_________________
База знаний ShapeSheet
Мой Youtube-канал @surrogate-tm
Мои трафареты


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 01:21 
Не в сети
Ветеран

Зарегистрирован: 26 авг 2019, 21:07
Сообщений: 267
Использую Visio c: 2019
Очков репутации: 11

Добавить очки репутацииУменьшить очки репутации
immortal писал(а):
на основании этого формируется спецификация?
Почти...
Содержимое спрятано под спойлер ↓
Спойлер:
Изображение
"Поз." - номер строки в спецификации
"Кол." - количество элементов на схеме/в проекте, либо количество метров провода/трубы (оно не может содержаться в конкретном шейпе потому, что суммируется по всей схеме/проекту)

_________________
САПР-АСУ
https://github.com/gtfox/
YouTube


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 01:29 
Не в сети
Ветеран
Аватара пользователя

Зарегистрирован: 28 апр 2013, 14:03
Сообщений: 963
Откуда: Вена, Австрия
Использую Visio c: 1998
Очков репутации: 100614

Добавить очки репутацииУменьшить очки репутации
Цитата:
Цитата:
Для уникальных идентификаторов последние 20 лет обычно используются GUID-ы.
где почитать про них подробнее?


Чуть выше Александр привел ссылку на википедию, там IMHO достаточно обстоятельно описывается (со ссылкой на RFC).
По сути GUID это просто 128-битное число, уникальность которого гарантируется.

Руками GUID задавать не нужно, обычно он генерируется программно (специальным алгоритмом).
То есть, руками можно только скопировать (при необходимости).

_________________
Полезные инструменты для создания диаграмм Visio:
https://unmanagedvisio.com/


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 02:17 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
Цитата:
Николай писал о том, что надо придерживаться единой идеологии именования полей (aнглийский/транслит/полные имена/сокращённые)

Цитата:
IMHO, c данными названиями IMHO есть некоторые объективные проблемы. Например, они не подчиняются особой логике:
есть "sp_type" (полное название на английском) и "sp_manu" (необщепринятое сокращение с английского), и "sp_ediz" - колхозный транслит.
Также префикс "sp" в мире Microsoft часто используется для "share point", возможно неправильное понимание.

предлагайте, сделаю, у меня в этом направлении фантазия плохо работает.
Цитата:
как вы себе это представляете? Комбинация из 32 символов/цифр !!!
В первом абзаце справки было написано:
не ,я имею ввиду добавлять вот как тут написано "По умолчанию форма не имеет уникального ID. Форма приобретает уникальный ID только в том случае, если задать его свойство UniqueID.", то есть как задать свойство UniqueID при редактировании шейпа или шейплиста, а не его значение
Цитата:
"Поз." - номер строки в спецификации
"Кол." - количество элементов на схеме/в проекте, либо количество метров провода/трубы (оно не может содержаться в конкретном шейпе потому, что суммируется по всей схеме/проекту)

то есть в стандарте могут использоваться в качестве "поз." - номер строки в спецификации и позиция на чертеже.
"кол." - вот тут не согласен, ведь у Вас всё равно есть значение длинны в шейпе, просто длинны считает макрос, но тут сложно учитывать например спуски, да и это поле у Вас есть в шейплисте ,только стандартное поле длинны которое макрос собирает.
Кстати у Вас собирает макрос из полей Буквенное обозначение и поля номер элемента или это собирается в одном поле шейплиста?
на мой взгляд для универсальности надо чтобы нейплист собирал из полей, а макрос уже брал готовые поля для спецификации.
Как называются свойства которые макрос берет для спецификации, ведь уже они придуманы и используются, мы возьмем это тогда в стандарт.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 03:54 
Не в сети
Ветеран

Зарегистрирован: 26 авг 2019, 21:07
Сообщений: 267
Использую Visio c: 2019
Очков репутации: 11

Добавить очки репутацииУменьшить очки репутации
immortal писал(а):
то есть как задать свойство UniqueID при редактировании шейпа или шейплиста
Никак. Работа с UniqueID только через VBA. В этом сообщении есть картинка
Содержимое спрятано под спойлер ↓
Спойлер:
Изображение
в которой мы в одной строке (желтой) присваеваем шейпу UniqueID и получаем его значение в переменную SSS
immortal писал(а):
то есть в стандарте могут использоваться в качестве "поз." - номер строки в спецификации и позиция на чертеже.
Тут вопрос сложный. У нас в конторе так потому, что если жестко придерживаться ГОСТ, ЕСКД, СПДС, то для АСУ нет нужных табличек, или места в них, или не удобно... Например при общении с заказчиками или поставщиками мы говорим: позицию №25 надо заменить или когда вы ее наконец доставите...
Позиционные обозначения элементов схемы мы запихнули в столбец "Код продукции" т.к. это какой-никакой код :) и в этом поле есть место и оно пустует...
immortal писал(а):
просто длинны считает макрос
У меня пока это не написано, но план такой:
1) Провод (как источник данных) появляется на схеме электрической, соединяя шкаф и датчик/привод
2) Этот же провод (в виде другого шейпа) размещается на плане размещения оборудования, где макросом считается его длина/опуски/запасы
3) Он же появляется на схеме внешних проводок (другой шейп) где отображается его марка и длина
4) Ну и в кабельном журнале тоже, где используются данные: откуда-куда и способы прокладки
Содержимое спрятано под спойлер ↓
Спойлер:
Изображение

immortal писал(а):
Кстати у Вас собирает макрос из полей Буквенное обозначение и поля номер элемента или это собирается в одном поле шейплиста?
Да, обозначение собирается формулами в ShapeSheet
Содержимое спрятано под спойлер ↓
Спойлер:
Изображение

immortal писал(а):
Как называются свойства которые макрос берет для спецификации, ведь уже они придуманы и используются, мы возьмем это тогда в стандарт.
Тут 2 варианта.
1) Если хотите чтобы Ваши шейпы работали в САПР-АСУ, то в них нужно иметь такую же структуру данных
Я не претендую на стандарт. У меня в именах бардак: английски/транслит вперемешку + нет единого подхода.
2) Если Вы делаете свое приложение - то именуете как хочется
Пока я писал "движок" САПР-АСУ у меня было нарисовано несколько ключевых шейпов, в которых формировалась и отлаживалась структура данных.
Когда ядро САПР-АСУ было написано, я начал рисовать кучи шейпов, зная что мне не придется их всех потом переделывать... (наивный, да... :mrgreen: )

Я пока не могу понять что Вы хотите сделать в конечном итоге...
Просто по мне, так сказать, мы делим шкуру не убитого медведя...
Я бы, на Вашем месте, взял эти названия переменных (из первого сообщения) и сделал бы что-то дальше

_________________
САПР-АСУ
https://github.com/gtfox/
YouTube


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 13:37 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
Цитата:
Никак. Работа с UniqueID только через VBA.
вычеркиваем. изобретаем свой велосипед.

Цитата:
1) Если хотите чтобы Ваши шейпы работали в САПР-АСУ, то в них нужно иметь такую же структуру данных
Я не претендую на стандарт. У меня в именах бардак: английски/транслит вперемешку + нет единого подхода.

это уже сделано, по этому предлагаю принять это за стандарт. Имена полей в студию!

Цитата:
2) Этот же провод (в виде другого шейпа) размещается на плане размещения оборудования, где макросом считается его длина/опуски/запасы
зачем макросом? на мой взгляд проще считать в шейплисте, можно тогда собирать через стандартные отчеты
Цитата:
Тут вопрос сложный. У нас в конторе так потому, что если жестко придерживаться ГОСТ, ЕСКД, СПДС, то для АСУ нет нужных табличек, или места в них, или не удобно... Например при общении с заказчиками или поставщиками мы говорим: позицию №25 надо заменить или когда вы ее наконец доставите...
Позиционные обозначения элементов схемы мы запихнули в столбец "Код продукции" т.к. это какой-никакой код :) и в этом поле есть место и оно пустует...
имеет место быть. просто это должно быть учтено и всё, то есть формирование спецификации должно быть настраиваемо.
Цитата:
Я пока не могу понять что Вы хотите сделать в конечном итоге...
хочу чтобы в рамках данного сообщества этого форума разработчики имели некий стандарт разработки, например у Вас есть инструмент создания спецификаций, чтобы этот инструмент работал и для шейпов других разработчиков.
Понятно что у меня свое видение, у Вас свое в разработке, но я полагаю надо выработать базовые правила разработки.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 14:44 
Не в сети
Administrator

Зарегистрирован: 30 авг 2009, 11:02
Сообщений: 2253
Очков репутации: 100626

Добавить очки репутацииУменьшить очки репутации
Цитата:
хочу чтобы в рамках данного сообщества этого форума разработчики имели некий стандарт разработки, например у Вас есть инструмент создания спецификаций, чтобы этот инструмент работал и для шейпов других разработчиков.

На мой взгляд, цель недостижима. И не только в шейпах дело.
Вот, например, спецификация. Кому-то достаточно простого списка. Засунуть в рамку и обозвать спецификацией. А строго по ЕСКД спецификация имеет кучу разделов и в каждом разделе несколько уровней сортировки, отличающихся для разных разделов. А есть еще групповые спецификации.
А у нас, например, еще и требовали, чтобы обозначение элемента при заказе строго соответствовало примеру, приведенному в ТУ. Значит обозначение никак нельзя вводить руками, а нужно выбирать его из базы. И отслеживать эту базу, так как даже ТУ время от времени меняются. Ну и т.д.
Это я к тому, что спецификацию для одного предприятия можно сделать. Стандарт для нескольких предприятий сделать не получится.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 14:58 
Не в сети
Administrator

Зарегистрирован: 30 авг 2009, 11:02
Сообщений: 2253
Очков репутации: 100626

Добавить очки репутацииУменьшить очки репутации
Цитата:
на мой взгляд для универсальности надо чтобы нейплист собирал из полей, а макрос уже брал готовые поля для спецификации.

Пара слов о подходе. Не столько конкретно в данном случае, сколько вообще...
Я считаю, что формулы шейп-листа хороши при отображении данных и для управления поведением шейпов. В основном, внутри одного шейпа. Закладывать в шейп лист функции, которые можно сделать макросом, не очень хорошо. Макрос гораздо прозрачнее, чем связи в шейп-листе. С ним даже начинающий программист разобраться может. Так что, если думать о последующем сопровождении и доработке продукта, то макросо-ориентированные решения будут менее трудоемки.
Мне приходилось дорабатывать чужую разработку с передачей данных через шейп-лист страницы между шейпами на одной странице в шейпы другой. Жуть! А если наложить сюда еще и наследование от мастер-шейпов, да еще и при периодической доработке мастер-шейпов...
Короче, если уж все равно разрешены макросы, то лучше нагружать их, чем сложности в шейп-листе.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 15:21 
Не в сети
Ветеран

Зарегистрирован: 26 авг 2019, 21:07
Сообщений: 267
Использую Visio c: 2019
Очков репутации: 11

Добавить очки репутацииУменьшить очки репутации
immortal писал(а):
вычеркиваем. изобретаем свой велосипед.
immortal писал(а):
зачем макросом? на мой взгляд проще считать в шейплисте, можно тогда собирать через стандартные отчеты
Я вижу отчаянные попытки уйти от VBA... могу сказать, что велосипед получится с квадратными колесами :mrgreen:
immortal писал(а):
Имена полей в студию!
В теме САПР-АСУ есть ссылка на скачивание... всё там, шейпы, макросы...
Опять же... я еще не делал шейпов электрики и прочего для планов помещений... может там появится какая-то своя специфика, это выяснится в процессе разработки
immortal писал(а):
формирование спецификации должно быть настраиваемо.
В каком объеме? Просто у меня так, у Вас так, придет еще 10 человек которым понадобится еще что-то.
Есть макрос который берет данные и сует их куда надо. Если кому-то надо по другому - открываем макрос, переписываем под свои нужды и пользуемся. В этом и прелесть OpenSource.

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

immortal писал(а):
хочу чтобы в рамках данного сообщества этого форума разработчики имели некий стандарт разработки
"Их есть у нас"... 2,5 человека :mrgreen: но это не точно 8-)

immortal писал(а):
Понятно что у меня свое видение, у Вас свое в разработке, но я полагаю надо выработать базовые правила разработки.
Хм... я уже отвечал на подобный вопрос на форуме, но найти не смог...
Речь не идет о написании САПР по чьему-то ТЗ... Я пишу ее, в первую очередь, для себя и делюсь наработками... Загонять сам себя в какие-то рамки я не хочу, но я прислушиваюсь к советам с форума

_________________
САПР-АСУ
https://github.com/gtfox/
YouTube


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 15 янв 2022, 16:37 
Не в сети
Content manager
Content manager
Аватара пользователя

Зарегистрирован: 02 окт 2009, 01:01
Сообщений: 5043
Откуда: оттуда
Использую Visio c: 1998
Отрасль: Интеграция системных интеграторов
Должность: Дизайнер по оформлению документации
Уровнь квалификации: Форматирование документов MS Word
Tumanov писал(а):
На мой взгляд, цель недостижима
согласен!
Tumanov писал(а):
Стандарт для нескольких предприятий сделать не получится

Даже если этот стандарт спустят сверху из какого нибудь министерства/федерального агентства и т.п. Получится только если за нарушение этого стандарта будут карать: 7
годами расстрелов на урановых рудниках при -40с
gtfox писал(а):
Просто у меня так, у Вас так, придет еще 10 человек которым понадобится еще что-то.
А именно так и будет, если кто-то всё таки придет!
gtfox писал(а):
2,5 человека но это не точно
если вы про меня, то я даже на половину не тяну...
gtfox писал(а):
я прислушиваюсь к советам с форума
советовать я ещё могу!

_________________
База знаний ShapeSheet
Мой Youtube-канал @surrogate-tm
Мои трафареты


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 16 янв 2022, 01:46 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
Цитата:
Короче, если уж все равно разрешены макросы, то лучше нагружать их, чем сложности в шейп-листе.
тогда исключаются стандартные отчеты.
Цитата:
Я вижу отчаянные попытки уйти от VBA... могу сказать, что велосипед получится с квадратными колесами
в данном случае не уйти ,а просто оставить стандартный инструмент визио: "Отчеты", другой вопрос: а надо ли?
Цитата:
В каком объеме? Просто у меня так, у Вас так, придет еще 10 человек которым понадобится еще что-то.
Есть макрос который берет данные и сует их куда надо. Если кому-то надо по другому - открываем макрос, переписываем под свои нужды и пользуемся. В этом и прелесть OpenSource.
переписываем макрос или переписываем config файл настройки макроса? вот в чем вопрос, на мой взгляд должен быть у макроса в данном случае конфиг файл, который соотносил поля шейпа с полями спецификации.Речь не идет о написании САПР по чьему-то ТЗ... Я пишу ее, в
Цитата:
первую очередь, для себя и делюсь наработками... Загонять сам себя в какие-то рамки я не хочу, но я прислушиваюсь к советам с форума
почему загонять? сделать для себя стандарт который удобен и понятен в использовании, именно по этому я не стал сначала делать (некоторые переделывать), а вынес на обсуждение, чтобы учесть максимально все ньюансы.

Но друзья, у нас дискуссия сводиться к:
- нахрен это никому не нужно
- если нужно то 2-м людям
- всё учесть невозможно и по этому нахрен это никому не нужно.
- всё хреново

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


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 16 янв 2022, 01:49 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
добавил в шапку:
? Сопоставление имени поля с столбцом спецификации для работы макроса задается в конфигурационном файле с именем: имя_макроса.conf
1. высказываем мнение по этому поводу
2. как это будет выглядеть в коде.


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 16 янв 2022, 02:32 
Не в сети
Ветеран

Зарегистрирован: 26 авг 2019, 21:07
Сообщений: 267
Использую Visio c: 2019
Очков репутации: 11

Добавить очки репутацииУменьшить очки репутации
immortal писал(а):
стандартные отчеты: а надо ли?
Считаю не надо

immortal писал(а):
Но друзья, у нас дискуссия сводиться к:
- нахрен это никому не нужно
- если нужно то 2-м людям
- всё учесть невозможно и по этому нахрен это никому не нужно.
- всё хреново
:mrgreen:

immortal писал(а):
давайте по существу
Согласен. Сделаю макрос, посмотрим что надо для его переделки и что надо для прикручивания туда конфига.

_________________
САПР-АСУ
https://github.com/gtfox/
YouTube


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Стандарты разработки
СообщениеДобавлено: 16 янв 2022, 03:19 
Не в сети
Постоянный участник

Зарегистрирован: 21 май 2010, 21:21
Сообщений: 75
Использую Visio c: 1999
Очков репутации: 2

Добавить очки репутацииУменьшить очки репутации
Цитата:
Считаю не надо
ещё у кого мнения будут? или вычеркиваю стандартные отчеты?

Цитата:
Согласен. Сделаю макрос, посмотрим что надо для его переделки и что надо для прикручивания туда конфига.


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


Пожаловаться на это сообщение
Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 45 ]  На страницу Пред.  1, 2, 3  След.

Часовой пояс: UTC + 3 часа [ Летнее время ]



Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы можете начинать темы
Вы можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Вы можете создать форум бесплатно PHPBB3 на Getbb.Ru, Также возможно сделать готовый форум PHPBB2 на Mybb2.ru
Русская поддержка phpBB