ObjectARX. Получение/изменение из AutoLisp свойств чертежа (Summary Info) (Страница 1 из 3)

> Пастух
:) А почему только текущего?

Спасибо бОльшое, завтра попробую на свежую голову.

> kpblc
:) Ага. Значит кому-то моя программка пригодилась. А то полная тишина... Сделаю.

> Александр Ривилис
Я ж говорил, что пользуюсь, за что безумно благодарен. Адрес тот же?

Все крутятся вокруг Summary Info. В то время как жутко нужна программа умеющая работать с полями Summary Info. Это была бы программа, которая логично завершила бы архивы файлов dwg без привлечения громоздких и ненадежных в эксплуатации архивов основанных на БД и СУБД. О коммерческом значении этой программы прогнозы делать не буду, но на мой взгляд вполне "тянет" на этот статус. По крайней мере, на западном рынке.

> Forma
Ничего не понял (как обычно). :( Какие поля? Что нужно с ними делать? Внутри AutoCAD или вне? Если внутри - то почему не годится моя функция? Если вне - я пас.

> Forma
Это мне не интересно.

> Forma
Неисповедима душа фрилансера..."Самое смешное то, что я бы мог написать подобную программку"
Не слишком ли уверенное заявление?
Всем давным-давно ясно, что необходимо иметь дополнительную информацию о файлах. Желательно с неограниченным количеством "полей" (метаданных, то есть "данных о данных"). Файлы бывают двух видов - текстовые, в которые ничего дополнительного не воткнешь, и двоичные, в которые в принципе можно записать что угодно.
Аутодеск, например, стала сохранять в DWG превьювы, другие программы пишут что-то свое. Но "неисповедимые программистские души" в каждом приложении сочиняют собственный формат. "Мультимедийщики" пишут свои метаданные, "автокадчики" - свои, а большинство вообще ничего не пишет.
Аутодеск сначала начала писать SummaryInfo в словарь DWG-файлов. Это было очень плохо, так как доступна была информация только из AutoCAD, или при наличии AutoCAD - через COM. А без AutoCAD - с использованием "автодесковской" dll с закрытым кодом. Она может прочитать метаданные, но их нельзя изменить без AutoCAD.
Начиная с 2004 сделали хранение SummaryInfo стандартно. Но по какому такому "стандарту"? Да по стандарту Microsoft.
Стандарты работы в Windows диктует Microsoft. Любим мы ее или нет. Microsoft давно предложила пути решения:
а) Специальный doc-файл (не путать с форматом doc для Word). Это внутреннее структурированное хранилище данных, в котором, как бы во внутренней файловой системе может храниться любая информация.
б) Дополнительные атрибуты файлов, кроме размера, даты и прочего.
Первый путь приживается с трудом. Каждый программист и его фирма считают себя умнее всех и никого не слушаются. Да и объективные причины есть - переделка всех форматов и всех программ. Кроме того, это опять привязка к технологиям Microsoft, а это "смотрящий" имеет привычку беззастенчиво менять правила игры. И форматы все равно остаются закрытыми.
Второй путь связан с использованием более совершенных файловых систем. Тоже хорошего мало (хотя и логично). Файловые системы опять же диктует Microsoft. Да и для новых файловых систем нужны новые ОС, новая техника и очередной виток не нужной большинству пользователей гонки производительности. Но очень любимый производителями железа и софта.
Есть третий путь - использование только открытых форматов, например XML. Здесь вся информация на виду, самодокументирована, можно вписать любые метаданные. Если я впишу в XML дополнительные атрибуты, то моя (или любая программа) их сможет прочитать. А те, кто не умеют или не желают ее читать - просто проигнорируют. И это не маловразумительные DXF или RTF.
Аутодеск сделала DesignXML и включала в AutoCAD 2002. А потом убрала. Возможно испугалась собственной смелости - формат-то открытый и никаких секретов, как в DWG там не утаишь.
Недостаток XML - размер и избыточность информации решается просто. XML прячется в ZIP. Так сделано в Open Office - его документы - это просто ZIP, в котором лежит требуемая начинка.
Microsoft тоже обещает пойти по такому пути. Но "обещанного три года ждут".
Есть и четвертый путь, который всем знаком - дополнительные файлы, в которых содержатся метаданные. Всякие файлы примечаний (descript.ion,  и т.п.). Это тоже плохо, но хоть какой-то выход. Тоже разнообразие форматов, но справиться с ним легче.
Так что пока ситуация неутешительная. Легкого решения нет. Нам, например, пришлось по старинке использовать INI-файлы, в которых хранятся любые метаданные.
Убого, но иного пока сделать нельзя. Зато позволяет сделать "архивы файлов dwg без привлечения громоздких и ненадежных в эксплуатации архивов основанных на БД и СУБД". Оценку надежности СУБД оставляю на совести Forma, дело не в надежности, а в гибкости работы и разнообразии данных. К тому же скоро вообще файловая система может замениться на одну "громоздкую и ненадежную" БД - собственно такой она уже и является - упорядоченное хранилище данных.
А то, что сделал Александр Ривилис - замечательно. Жаль, что он пока не сделал следующего логичного шага...:) Пока тоже привязка к ARX, к очередным версиям AutoCAD и среды разработки.

> Александр Ривилис
Я бы сделал ActiveX. Внутри него - реализацию извлечения Summary Info разными методами. В то числе, если AutoCAD на машине нет.
Для этого Autodesk выкладывала специально
http://adeskftp.autodesk.com/prodsupp/a … gpro15.zip (наверное, есть поновее).
Там внутри DwgProps.obj, Dwgprops.h и пример pscan.cpp
Из этого добра делал dll, но очень уж не нравится привязка к компилятору. "Я не буду глотать столько попугаев". А obj от Microsoft не линкуются, куда надо.
В результате приходится писать много кода, чтобы добираться через StgOpenStorageEx или еще как.

> ShaggyDoc
Теперь понял о чем Вы! :) Есть на сайте ADN DwgPropsX.dll который через ActiveX позволяет читать Summary Info для AutoCAD 2002...2006. Но она не позволяет редактировать эти поля.

    interface IProperties : IDispatch {
        [id(0x00000001), helpstring("method Load")]
        HRESULT Load([in] BSTR bstrFileName);
        [id(0x00000002), helpstring("method LetOff")]
        HRESULT LetOff();
        [id(0x00000003), propget, helpstring("property Title")]
        HRESULT Title([out, retval] BSTR* pVal);
        [id(0x00000004), propget, helpstring("property Subject")]
        HRESULT Subject([out, retval] BSTR* pVal);
        [id(0x00000005), propget, helpstring("property Author")]
        HRESULT Author([out, retval] BSTR* pVal);
        [id(0x00000006), propget, helpstring("property Comments")]
        HRESULT Comments([out, retval] BSTR* pVal);
        [id(0x00000007), propget, helpstring("property Keywords")]
        HRESULT Keywords([out, retval] BSTR* pVal);
        [id(0x00000008), propget, helpstring("property LastSavedBy")]
        HRESULT LastSavedBy([out, retval] BSTR* pVal);
        [id(0x00000009), propget, helpstring("property RevisionNumber")]
        HRESULT RevisionNumber([out, retval] BSTR* pVal);
        [id(0x0000000a), propget, helpstring("property HyperlinkBase")]
        HRESULT HyperlinkBase([out, retval] BSTR* pVal);
        [id(0x0000000b), propget, helpstring("property Custom")]
        HRESULT Custom(
                        [in] long index,
                        [out, retval] BSTR* pVal);
        [id(0x0000000c), propget, helpstring("property EditingTime")]
        HRESULT EditingTime([out, retval] DATE* pVal);
        [id(0x0000000d), propget, helpstring("property Created")]
        HRESULT Created([out, retval] DATE* pVal);
        [id(0x0000000e), propget, helpstring("property LastUpdated")]
        HRESULT LastUpdated([out, retval] DATE* pVal);
    };

Да и не люблю я ActiveX! :)

> ShaggyDoc
Ага. Значится на "посмотреть" можно. :) Это на 80% ваш упрек "Не слишком ли уверенное заявление?" уже размывает. Я бы мог продолжить дальше, но думаю не конструктивно это будет.
Ну и заодно уже о базах данных. Точнее об управлении ими. Здесь я имел пресловутый "человеческий фактор". Который любую супернадежную базу данных может превратить в свалку мусора. Ну да ладно, в любом случае, спасибо за интересную информацию.