Не плоди одинаковые темы в разных разделах. В других разделах я их удалю.
Однозначного ответа на твой вопрос нет.
В любом случае открытого API для этой цели нет.Если всегда ждать API, то можно ждать до пенсии :)
указан ключ ACAD-A001:419, который соответствует обычному AutoCAD 2012 (R18.0).Я не знаю, это первый попавшийся файл из сети от смежников, понятия не имею в чем они его создавали и в чем он редактировался, но судя по кодам на скрине, получается что простой 2012.
А есть ли возможность определить в каком приложении был последний раз сохранен dwg файл?Если вытащить записанное в файле строковое представление ключа, то остальное будет не сложным. Например, для ключей:
ACAD-101:409
ACAD-D000:419
ACAD-F000:419
acad-7001:409
acadlt-9009:419
AutoCAD key: ACAD-101:409
AutoCAD 2002 [R15.2] English (United States)
AutoCAD key: ACAD-D000:419
Autodesk Civil 3D 2014 [R19.1] Russian (Russia)
AutoCAD key: ACAD-F000:419
Autodesk Civil 3D 2016 [R20.1] Russian (Russia)
AutoCAD key: acad-7001:409
AutoCAD 2009 [R17.2] English (United States)
AutoCAD key: acadlt-9009:419
AutoCAD LT 2011 [R18.1] Russian (Russia)
Хотя конечно потрошить dwg файл, эт плохо.
Код не критиковать!Вы же знаете, что я так "не играю"... :)
Плохо и не очень надежноСогласен, применительно к текущей версии кода. :P
Некоторые моменты сразу бросаются в глаза... Куда подевали проверку первых шести байтов на предмет того, новее ли это чем 2004-й? Почему не проверяете значение переменных lineStart и lineEnd? Мало ли, ведь DWG мог быть сгенерирован не автокадом, но сторонним приложением (например работающем на основе платформы ODA или какой-нибудь другой).Проверка первых 6 байт в данном случае смысла не имеет - меня не интересует в формате какой версии сохраняли файл. Меня интересует каким приложением и какой версией это было сделано. Если в файле этой информации нет, то функция вернёт null. Так как стоят try/catch, то проверка lineStart и lineEnd смысла не имеют. Что будет в случае ODA меня честно говоря не слишком интересует (и на этом форуме не обсуждаем), но и с ним аварийного завершения не будет. Если они сделали по образцу и подобию AutoCAD, то должна получится нормальная информация, если нет - то будет null.
Если в файле этой информации нет, то функция вернёт null. Так как стоят try/catch, то проверка lineStart и lineEnd смысла не имеют.Если в случае пакетной обработки исключение будет происходить часто, то скорость обработки будет отвратительной - вам это прекрасно известно. Тогда почему бы сразу, предусмотрительно, не избегать try\catch, если это можно сделать без особого труда?
Что будет в случае ODA меня честно говоря не слишком интересует (и на этом форуме не обсуждаем)А меня как раз интересует именно практическое применение кода, а не сферические кони в вакууме. Мы нередко получаем от сторонних организаций DWG, созданные не в автокаде.
Если они сделали по образцу и подобию AutoCAD, то должна получится нормальная информация, если нет - то будет null.Оно понятно, но предусмотреть обратный поворот событий не мешало бы (имхо).
А меня, как раз, интересует практическое применение, а не сферические кони в вакууме.Вот и проверь. В действительности в коде есть значительно более грубая вещь - чтение всего файла в память, которую следовало бы избежать. По сравнению с этим все остальные прегрешения - мелочь...
C:\Temp>GetDwgSaveInfo.exe Проверка.dwg
Application = ODA Name = Teigha(R).NET for .dwg files Build Version = 2.5 Registry Version = 3.8
---- Press any key ----
Если в случае пакетной обработки исключение будет происходить часто, то скорость обработки будет отвратительнойЭто при чтении файлов? Да вообще фиолетово, в зависимости от машины - дельта будет ну где то 5 секунд МАКСИМУМ на порядка 100000 файлов - это в крайнем случае - то есть если все выдали ошибку - это конечно ужасная разница.
Александр, а файл GetDwgSaveInfo.exe точно не вирус, а то мой Symantec Endpoint Protection ну никак не хочет его запускать!Точно. Можешь сам скомпилировать его из исходника, который я выложил.
Это при чтении файлов? Да вообще фиолетово, в зависимости от машины - дельта будет ну где то 5 секунд МАКСИМУМ на порядка 100000 файлов - это в крайнем случае - то есть если все выдали ошибку - это конечно ужасная разница.Как говорится, обожгёшься на молоке - будешь дуть на воду. Вот пример (https://sites.google.com/site/bushmansnetlaboratory/sendbox/stati/database/compare) существенной разницы в скорости. В обозначенном примере я выполнял полную итерацию по всем объектам базы данных чертежа. Чертёж 50 Мб, количество объектов - 736 323. Один из обозначенных способов использовал try\catch, отлавливая ошибки. Два другие используют подходы в которых исключение не генерируется.
Как говорится, обожгёшься на молоке - будешь дуть на воду.Тут Вы как-бы об кастрюлю обожглись - в смысле не туда дуете. try->catch действительно медленная операция, но не на ту разницу, что в Вашем примере. Однозначно необходимы дополнительные проверки, либо при очень большом кол-ве итераций, либо когда проверяемая процедура имеет долгую обработку при получении ошибочных данных (например введя в строку браузера левый адрес - он долго будет понимать, что его нет) - как в Вашем случае - то есть минуты у Вас появились, не из-за того что долго работала try->catch, а из-за долгой работы TargetDb.GetObjectId в случае ошибки. Проверьте сами какая будет разница в секундах если проверять 100000 чисел деленных на ноль, проверкой делителя и через try catch - вот Вам и будет реальная разница.
А с файлом какого размера будет гораздо медленнее? Файл 7.9 Мб тоже быстро. Может я что-то не понял?Дело не в скорости (хотя это тоже важно). В случае если чертеж будет размером в сотни мегабайт (или даже гигабайты) не исключено что алгоритм не сработает. Возможно в этом случае будет активное использование виртуальной памяти и это приведёт к сильному замедлению. Но на чертежах меньшего размера я не вижу повода для беспокойства.
Дело не в скорости (хотя это тоже важно). В случае если чертеж будет размером в сотни мегабайт (или даже гигабайты) не исключено что алгоритм не сработает. Возможно в этом случае будет активное использование виртуальной памяти и это приведёт к сильному замедлению. Но на чертежах меньшего размера я не вижу повода для беспокойства.Понятно.
минуты у Вас появились, не из-за того что долго работала try->catch, а из-за долгой работы TargetDb.GetObjectId в случае ошибкиЯ это прекрасно понимаю и не утверждал, что причина такой разницы во времени находится в использовании конструкции try\catch. Причина, понятное дело, в возникающих Exception, на обработку которых в try\catch и происходят дополнительные затраты времени. :) Я высказал своё мнение и пояснил причины, лежащие в его основе. Править код с учётом этих замечаний или нет - это уж каждый как хочет. )