[Дима_]

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

[Кулик Алексей aka kpblc]

Если коротно - то головняк и геморрой. Добраться до допустимых свойств дин.блока, и их значений возможно. Если свойства индексированы, то работа с БД возможна. Но вот внесение новых значений в дин.блок... Что делать, если сначала были допустимы значения параметра 1: 1, 2, 3, 5; а после обновления - 1.5; 6; 18? А в файле уже вставлены блоки с первыми значениями параметров? В ADT, например, приходится руками по новой импортировать описания стилей AEC-объектов (прародителей дин.блоков) для корректной работы с ними.
ИМХО прежде чем ваять код, надо с БД разобраться по полной программе, и всю технологию проработать.

[Дима_]

Технологию взаимодействия я вижу примерно так -
[ATTACH]1188890180.JPG[/ATTACH]

... ну и как я догадался штатных средств синхронизации нет.

[Кулик Алексей aka kpblc]

Прошу прощения, но это не технология, а просто 1 [почти] штатная кадовская форма, и не больше.
Вопрос-то не столько в оформлении, сколько во внутренностях софта. Какова структура БД? Насколько она нормализована (или там все в одной таблице болтается)? Кто имеет права на ее изменение? Что делать со вставленными ранее блоками при изменении БД? Что делать, если состав блока пришлось менять, вводить новые параметры (в том числе и видимости) - в смысле, как поступать с уже вставленными блоками? Как отслеживать соответствие изменения БД и неоткрытых файлов? Как быть с файлами, содержащими внешние ссылки?
Меня пугает не столько трудность написания, сколько количество вопросов, на которые нет однозначных ответов.

[Дима_]

Попробую описать - я думаю что для большинства задач не больно нужна гибкая структура данных (данный пример, как я уже писал, сделан в экселе - соответственно нормализации там никакой нет "все в одной таблице болтается") - алгоритм примерно такой (напишу на словах ну не блок-схему же рисовать).
1. Находим и открываем первый блок.
2. Проверяем есть ли в нем настраиваемые параметры и связи.
3. Берем атрибут блока - его считаем номером поля (строки таблицы), в принципе правильней будет придумать контрольное слово например "строка х", где х - и есть номер.
3а. Если не хочется заморачиваться с атрибутами то можно воспользоваться штатной связью (там есть выборка) - но по моему с атрубутом более гибгко получится.
4. Берем имя 1-го настраиваемого параметра - ищем такое же в строке и осуществляем импорт (в случае экспорта либо меняем "атрибутную" запись, либо создаем с номером атрибута).
5. Аналогично с другими параметрами.
6. Аналогично со всеми блоками.
В результате получаем следующее - подготавливаем дин. блоки, а далее что нужно - либо с них спецификацию снимаем, либо рисунок строится на основе полей - ну чем не САПР.

[Кулик Алексей aka kpblc]

Жалко, до abok.ru не достучаться... Есть там тема "автоматическое создание спецификаций", подобные вопросы и там тож поднимались. Првда, с привязкой больше к внешним ссылкам, но все равно.

[Дима_]

Да как раз то спецификации - это дело вторичное (сдесь и полями обойтись можно и штатные средства есть), вопрос скорее в построении по б/д - просто у меня очень много однотипных задач (да я думаю не только у меня) и хочется все это "оцифровать" - дин. блоки уже почти везде сделал, но по ним прыгать муторно - а так в таблицу данные ввел и 80 процентов работы сделал.
P.S. - абок молчит.

[Дима_]

Абок ожил - но там я ничего не нашел.

[Кулик Алексей aka kpblc]

Тема http://forum.abok.ru/index.php?showtopic=14612

Сообщение от Дима_ Попробую описать - я думаю что для большинства задач не больно нужна гибкая структура данных (данный пример, как я уже писал, сделан в экселе - соответственно нормализации там никакой нет "все в одной таблице болтается") <...>

Ага, а потом будешь долго голову ломать, как добиться корректной работы при резко возросшем количестве записей. Я б советовал (так, навскидку) все же работать через хоть какую-то БД, создав в ней всего 3-4 таблицы: таблица имен блоков, таблица состава блока, таблица имен дин.свойств блока и таблица допустимых значений свойств дин.блока. Примерно так, наверное:

Код:

[Выделить все]

CREATE TABLE tblDynBlocks(ID Autoincrement primary key, Name char(50) not null unique);
CREATE TABLE tblDynBlocksContent(ID Autoincrement primary key, lnk_tblDynBlock long not null, EntityName memo not null);
CREATE TABLE tblDynBlocksPropName(ID autoincrement primary key, lnk_tblDynBlock long not null, Name char(70) not null);
CREATE TABLE tblDynBlocksPropValues (ID Autoincrement primary key, lnk_BlockName long not null, lnk_PropName long not null, arValues memo);

Код написан для MS Access. Без подробной проработки. Назначение полей по идее понятно из имен. Но это особо не важно. Важно то, что, выполнив SQL-запрос примерно такой, наверное:

Код:

[Выделить все]

SELECT tblDynBlocks.Name, tblDynBlocksContent.EntityName, tblDynBlocksPropName.Name, tblDynBlocksPropValues.arValues
FROM ((tblDynBlocks INNER JOIN tblDynBlocksContent ON tblDynBlocks.ID = tblDynBlocksContent.lnk_tblDynBlock) INNER JOIN tblDynBlocksPropName ON (tblDynBlocksContent.ID = tblDynBlocksPropName.ID) AND (tblDynBlocks.ID = tblDynBlocksPropName.lnk_tblDynBlock)) INNER JOIN tblDynBlocksPropValues ON (tblDynBlocksContent.ID = tblDynBlocksPropValues.ID) AND (tblDynBlocks.ID = tblDynBlocksPropValues.lnk_BlockName) AND (tblDynBlocksPropName.ID = tblDynBlocksPropValues.lnk_PropName)
WHERE (((tblDynBlocks.Name)='ИмяБлока'));

Ты сможешь узнать все возможные варианты для этого блока.
А вариант

Код:

[Выделить все]

SELECT tblDynBlocks.Name, tblDynBlocksContent.EntityName, tblDynBlocksPropName.Name, tblDynBlocksPropValues.arValues
FROM ((tblDynBlocks INNER JOIN tblDynBlocksContent ON tblDynBlocks.ID = tblDynBlocksContent.lnk_tblDynBlock) INNER JOIN tblDynBlocksPropName ON (tblDynBlocksContent.ID = tblDynBlocksPropName.ID) AND (tblDynBlocks.ID = tblDynBlocksPropName.lnk_tblDynBlock)) INNER JOIN tblDynBlocksPropValues ON (tblDynBlocksContent.ID = tblDynBlocksPropValues.ID) AND (tblDynBlocks.ID = tblDynBlocksPropValues.lnk_BlockName) AND (tblDynBlocksPropName.ID = tblDynBlocksPropValues.lnk_PropName)
WHERE (((tblDynBlocks.Name)='ИмяБлока') AND ((tblDynBlocksPropName.Name)='ИмяСвойства'));

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

Сообщение от Дима_ алгоритм примерно такой (напишу на словах ну не блок-схему же рисовать). 1. Находим и открываем первый блок.

Наверное, имеется в виду первое вхождение блока?

Сообщение от Дима_ 2. Проверяем есть ли в нем настраиваемые параметры и связи.

Как проверять-то? Ну есть в этом блоке свойство "Diam", дальше что? Блока такого нет в БД, вносить?

Сообщение от Дима_ 3. Берем атрибут блока - его считаем номером поля (строки таблицы), в принципе правильней будет придумать контрольное слово например "строка х", где х - и есть номер.

Я б на атрибуты поменьше заморачивался.

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

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

[Дима_]

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

[Кулик Алексей aka kpblc]

Еще один вопрос - как определяется, "связан" блок или нет?

[Дима_]

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