Как узнать в каком приложении создан dwg-файл?

[Андрей Бушман]

Если в файле этой информации нет, то функция вернёт null. Так как стоят try/catch, то проверка lineStart и lineEnd смысла не имеют.

Если в случае пакетной обработки исключение будет происходить часто, то скорость обработки будет отвратительной - вам это прекрасно известно. Тогда почему бы сразу, предусмотрительно, не избегать try\catch, если это можно сделать без особого труда?

Что будет в случае ODA меня честно говоря не слишком интересует (и на этом форуме не обсуждаем)

А меня как раз интересует именно практическое применение кода, а не сферические кони в вакууме. Мы нередко получаем от сторонних организаций DWG, созданные не в автокаде.

Если они сделали по образцу и подобию AutoCAD, то должна получится нормальная информация, если нет - то будет null.

Оно понятно, но предусмотреть обратный поворот событий не мешало бы (имхо).

[Александр Ривилис]

А меня, как раз, интересует практическое применение, а не сферические кони в вакууме.

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

Кстати проверил файл, созданный не в AutoCAD. Вполне приличная информация:

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 файлов - это в крайнем случае - то есть если все выдали ошибку - это конечно ужасная разница.

[Пашин Евгений]

За ваши ответы +500 к карме каждому! Андрей Бушман и Boxa.Shu, вам отдельное спасибо, что вытащили вопрос к решению!

Александр, а файл GetDwgSaveInfo.exe точно не вирус, а то мой Symantec Endpoint Protection ну никак не хочет его запускать!

[Александр Ривилис]

Александр, а файл GetDwgSaveInfo.exe точно не вирус, а то мой Symantec Endpoint Protection ну никак не хочет его запускать!

Точно. Можешь сам скомпилировать его из исходника, который я выложил.

[Андрей Бушман]

Это при чтении файлов? Да вообще фиолетово, в зависимости от машины - дельта будет ну где то 5 секунд МАКСИМУМ на порядка 100000 файлов - это в крайнем случае - то есть если все выдали ошибку - это конечно ужасная разница.

Как говорится, обожгёшься на молоке - будешь дуть на воду. Вот пример существенной разницы в скорости. В обозначенном примере я выполнял полную итерацию по всем объектам базы данных чертежа. Чертёж 50 Мб, количество объектов - 736 323. Один из обозначенных способов использовал try\catch, отлавливая ошибки. Два другие используют подходы в которых исключение не генерируется.

Время полной итерации по всем объектам базы данных чертежа в варианте с try\catch составило 05 мин. 36,1859781 сек.
Та же самая операция, но без try\catch для двух других вариантов заняла 0 мин. 14,1793398 сек. и 0 мин. 0,2781968 сек. соответственно.

Как видим, на больших объёмах данных разница может оказаться существенной: в одном случае операция заняла даже менее половины секунды, в то время как в другом - более 5,5 мин. В процессе работы возникало около 100 000 исключений. Конечно, при пакетной обработке файлов, применительно к данной задаче, их будет значительно меньше. Однако я считаю, что если есть возможность избавитья от try\catch, то лучше было бы это сделать (имхо). Его можно было бы оставить, как перестраховку, но добавить логику проверки, которая позволила бы избежать лишние появления исключений.

[Пашин Евгений]

Я что-то важное пропустил...

Пришлось код Александра переписать на VB

Взял форму, установил кнопку на форму и вот это код вписал:

Код - vb.net [Выбрать]

1. Imports System.IO
2. Imports System.Text
3. Imports System.Xml
4. Imports System.Collections.Generic
5. Imports System.Linq
6. Imports System
7. Imports System.Threading.Tasks
8.  
9. Public Class Form1
10.     Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
11.         Dim Name As String = "", Build_Version As String = "", Registry_Version As String = ""
12.         Const Desc As String = "<ProductInformation name ="
13.         Try
14.             Dim line As String = System.IO.File.ReadAllText("C:\Users\Pashin.Evgeniy\Desktop\Чертеж_Civil3D_пустой.dwg", Encoding.Unicode)
15.             Dim lineStart As Integer = line.IndexOf(Desc)
16.             Dim lineEnd As Integer = line.IndexOf(">", lineStart + 1)
17.             Dim s As String = New StringBuilder(line.Substring(lineStart, lineEnd - lineStart)).Replace("\""", """").ToString()
18.             s = s & ">"
19.             Dim reader As XmlReader = XmlReader.Create(New StringReader(s))
20.             Using (reader)
21.                 reader.Read()
22.                 Name = reader.GetAttribute("name")
23.                 Build_Version = reader.GetAttribute("build_version")
24.                 Registry_Version = reader.GetAttribute("install_id_string")
25.             End Using
26.             MsgBox(Registry_Version)
27.         Catch ex As Exception
28.             MsgBox(ex.Message) ' "Ну, что опять не так?"
29.         End Try
30.     End Sub
31. End Class

Работает! Но файл пустой. А с файлом какого размера будет гораздо медленнее? Файл 7.9 Мб тоже быстро. Может я что-то не понял?


Переписал файл чертежа в AutoCAD и Registry Version изменился... Жаль, что нет аттрибута, который бы отвечал за название исходного приложения.

Все равно подойдет! Всем большое спасибо!

[Дима_]

Как говорится, обожгёшься на молоке - будешь дуть на воду.

Тут Вы как-бы об кастрюлю обожглись - в смысле не туда дуете. try->catch действительно медленная операция, но не на ту разницу, что в Вашем примере. Однозначно необходимы дополнительные проверки, либо при очень большом кол-ве итераций, либо когда проверяемая процедура имеет долгую обработку при получении ошибочных данных (например введя в строку браузера левый адрес - он долго будет понимать, что его нет) - как в Вашем случае - то есть минуты у Вас появились, не из-за того что долго работала try->catch, а из-за долгой работы TargetDb.GetObjectId в случае ошибки. Проверьте сами какая будет разница в секундах если проверять 100000 чисел деленных на ноль, проверкой делителя и через try catch - вот Вам и будет реальная разница.

[Александр Ривилис]

А с файлом какого размера будет гораздо медленнее? Файл 7.9 Мб тоже быстро. Может я что-то не понял?

Дело не в скорости (хотя это тоже важно). В случае если чертеж будет размером в сотни мегабайт (или даже гигабайты) не исключено что алгоритм не сработает. Возможно в этом случае будет активное использование виртуальной памяти и это приведёт к сильному замедлению. Но на чертежах меньшего размера я не вижу повода для беспокойства.

[Пашин Евгений]

Дело не в скорости (хотя это тоже важно). В случае если чертеж будет размером в сотни мегабайт (или даже гигабайты) не исключено что алгоритм не сработает. Возможно в этом случае будет активное использование виртуальной памяти и это приведёт к сильному замедлению. Но на чертежах меньшего размера я не вижу повода для беспокойства.

Понятно.

[Андрей Бушман]

минуты у Вас появились, не из-за того что долго работала try->catch, а из-за долгой работы TargetDb.GetObjectId в случае ошибки

Я это прекрасно понимаю и не утверждал, что причина такой разницы во времени находится в использовании конструкции try\catch. Причина, понятное дело, в возникающих Exception, на обработку которых в try\catch и происходят дополнительные затраты времени. Я высказал своё мнение и пояснил причины, лежащие в его основе. Править код с учётом этих замечаний или нет - это уж каждый как хочет. )