database.BeginSave += new DatabaseIOEventHandler(database_BeginSave);
database.SaveComplete += new DatabaseIOEventHandler(database_EndSave);
database.SaveAs()
А чем не устроила отдельная команда?
Do Not Use UNDEFINE and REDEFINE Commands
Level
Requirement
Applies to
ObjectARX and .NET applications
You cannot use the UNDEFINE and REDEFINE AutoCAD commands. Using these commands can confuse users and can conflict with other applications. Particularly troublesome is the situation when QUIT, END, SAVE, OPEN, and NEW are redefined by more than one application. ObjectARX provides a variety of mechanisms for applications to receive control at these key events. (Refer to the Notification chapter in the ObjectARX Developer's Guide for a discussion of reactors.)
Я пользую команду movebak из express tools для создания bak файлов в заданной папке.я не вижу пользы в ней, т.к. она не даёт возможности откатиться к нужной версии чертежа. Каждое сохранение по прежнему переписывает этот единственный BACK. То, где лежит BACK-файл: рядом с DWG или в подкаталоге - это особой роли не играет (имхо). Ключевой момент - иметь возможность откатиться к нужной версии чертежа. BACK может оказаться повреждённым, как и оригинал, в виду того, что повреждённое состояние было сохранено.
Если речь о бэкапах, то я когда-то написал такое решение (https://sites.google.com/site/bushmansnetlaboratory/sendbox/lab/backupfiles) (возможно будет интересно).
1. случаи аварийные, т.е. рядом с файлом не надо. Когда надо тогда и залезли в папку автосохранения. Также идет работа в сетевых папках.Мои пользователи в основном так же работают с файлами, расположенными в сети. Каталоги сохранения настраиваются посредством конфиг-файла, имеющего формат xml (он там, кстати, показан). При помощи конфига можно указывать как абсолютный, так и относительный путь к каталогу резервных копий (как правило, он там же - на сервере).
2. механизм автосейва использовать удобнее, поставил 10 минут и забыл. не вызывая доп команды.Я отказался от этого, т.к. подобный подход способствует быстрому раздуванию каталогов с контрольными точками сохранения и по факту будет содержать огромное количество ненужных файлов, не соответствующих самой идее контрольных точек восстановления. Отдаю предпочтение осмысленному нажатию на кнопке создания контрольной точки сохранения, т.к. именно пользователь, а не автосэйв, имеет чёткое представление о том, когда целесообразней эту точку создать. Такие точки обозначают очередной пройденный этап проектирования, либо один из возможных вариантов решения (т.е. своего рода ветвление). В дальнейшем от какой-то ветки можно будет легко отказаться (в случае необходимости).
3. бэкап - постоянный спам, подлежащий удалению через 1-3 дня, т.е это локальная, очищаемая папка.Я делаю отличие бэкапа от контрольной точки восстановления, созданной пользователем. Это разные понятия. Мой код создаёт именно контрольные точки, а не бэкапы.
SaveComplete + Singleton + запирающий флаг, чтоб избежать зацикливания, скорее всего то, что нужно.Этой фразы я не понял. Польза обозначенного паттерна в данной ситуации мне так же не очевидна. Синглтон гарантирует, что объект некоторого класса всегда будет присутствовать в единственном экземпляре. Какое это отношение имеет к автосохранению и как может помочь - я не представляю.
Мои пользователи так же работают с файлами, расположенными в сети. Каталоги сохранения настраиваются посредством конфиг-файла, имеющего формат xml (он там, кстати, показан). При помощи конфига можно указывать как абсолютный, так и относительный путь к каталогу резервных копий.Это не спорю, можно.
способствует быстрому раздуванию каталогов. т.к. именно пользователь имеет чёткое представление о том, когда целесообразней эту точку создать.Каталог "сам почищу" до старта команды при старте, по дате файлов...это детали
Я различаю бэкап от контрольной точки восстановленияА мне не нужно нового термина - точка восстановления. это именно бэкап через заданный промежуток времени. Это именно то, что ожидают мои пользователи от Autosave. Наверное тоже не стоит спорить.
Этой фразы я не понял. Польза обозначенного паттерна в данной ситуации мне так же не очевидна.Ок, какие еще варианты?)))
Ок, какие еще варианты?)))
Command: NETLOAD
The "C:\public\Debug\DWG_save_sandbox\DWG_save_sandbox.R20.1.dll" assembly successfully loaded.
Command:
Command:
Command: _qsave
File saved as 'C:\public\data\test_2015-05-29_11-36-45.bak'.
Command:
Command:
Command: _qsave
File saved as 'C:\public\data\test_2015-05-29_11-36-46.bak'.
Command:
Command:
Command: _qsave
File saved as 'C:\public\data\test_2015-05-29_11-36-49.bak'.
Command:
Command:
Command: _qsave
File saved as 'C:\public\data\test_2015-05-29_11-36-51.bak'.
Command:
Command:
Command: _qsave
File saved as 'C:\public\data\test_2015-05-29_11-36-52.bak'.
Например такой:я тоже самое и написал, только словами))
я тоже самое и написал...Тогда я не понял причины наличия этого топика, ведь обозначенный мною выше код работает (без всяких "синглтонов"). Если у тебя такой же, то должен был работать и твой...
и тоже самое по сути у меня в коде ;-)
Singleton - единственный экземплярЭтой фразы я не понимаю, ну да ладно...
(savingMarker и db_SaveComplete&SaveAs)
Кстати по поводу Singleton.Опять не понимаю, при чём тут Singleton. Дважды в один и тот же AppDomain загрузить одну и ту же Assembly невозможно. Соответственно и регистрация событий будет выполнена лишь единожды, при первой (и ей же последней) загрузке управляемой сборки.
Если 2 раза вызвать netload выполняемой при загрузке библиотеки, не создаст ли она 2 события db.SaveComplete += db_SaveComplete;???
У меня почему-то подозрение, что автору нужна система контроля версий.у меня такого подозрения нет.
У тебя уверенность?абсолютная. в том, что ему это не нужно :)
А мне не нужно нового термина - точка восстановления. это именно бэкап через заданный промежуток времени. Это именно то, что ожидают мои пользователи от Autosave. Наверное тоже не стоит спорить.git посложнее моего варианта будет ;)
Тогда я не понял причины наличия этого топика, ведь обозначенный мною выше код работает (без всяких "синглтонов"). Если у тебя такой же, то должен был работать и твой...
Этой фразы я не понимаю, ну да ладно...Обсуждение паттернов в разрезе кто, что и как написал, и насколько понятно/непонятно, предлагаю тут не вести. Это темы других форумов.
Дважды в один и тот же AppDomain загрузить одну и ту же Assembly невозможно. Соответственно и регистрация событий будет выполнена лишь единожды, при первой (и ей же последней) загрузке управляемой сборки.Вот это по теме. AppDomain и Assembly я плохо знаю механизмы, загрузки/выгрузки, поэтому и спросил. Спасибо буду теперь знать)
У меня почему-то подозрение, что автору нужна система контроля версий.Нет. Нужно резервирование их работы в течении дня-трех.
А сбои пока частые.Я бы разбирался с причинами частых "вылетов". Восстановление в данном случае, думаю,- это лечение симптомов, а не болезни.
Твой код появился в этой теме, после поиска проблемы. Мой код был доработан в это же время.теперь понял. я сначала подумал, что это решение и так было тобой найдено ранее, но чем-то тебя не устроило и ты создал тему.
Обсуждение паттернов в разрезе кто, что и как написал, и насколько понятно/непонятно, предлагаю тут не вести.Тогда предлагаю их тут и не упоминать, тем самым внося некоторые неясности.
Дважды в один и тот же AppDomain загрузить одну и ту же Assembly невозможно. Соответственно и регистрация событий будет выполнена лишь единожды, при первой (и ей же последней) загрузке управляемой сборки.Кстати, здесь есть одно НО... Дело в том, что CLR реализована в виде COM сервера. Если мне не изменяет память, то начиная с .NET 4.5 неуправляемое приложение может использовать в своей работе сразу несколько таких COM серверов - по одному для каждой поддерживаемой приложением версии CLR. Это позволяет успешно загружать в исходное неуправляемое приложение написанные для него управляемые плагины, скомпилированные под разные версии .NET: 3.5, 4.0, 4.5, 4.5.1. Каждый плагин грузится в соответствующий ему COM сервер (CLR).
70% знают где посмотреть папку для автосохранения.Общая папка автосохранения - зло, которое может вылезти боком в самый неподходящий момент. Такая папка должна быть для каждого проекта своя, т.к. юзеры могут работать над разными версиями одного и того же проекта, в результате чего некоторые файлы могут иметь одинаковые имена. В этом случае в общем каталоге автосохранения будет файл того, кто последним выполнил автосохранение. Впрочем это не моя головная боль - решай сам (я лишь предупредил о мине замедленного действия).
Андрей Бушман, зачем транзакция в Initialize?Это код моего общего шаблона в Visual Studio. Я лишь заменил
Все верно, что тут добавишь.А сбои пока частые.Я бы разбирался с причинами частых "вылетов". Восстановление в данном случае, думаю,- это лечение симптомов, а не болезни.
Транзакцию убирать не стал, хотя она там и не нужна.Скорее вредна,о чем мы с тобой недавно говорили.
Общая папка автосохранения....Я не имел ввиду общей папки на сервере. Это локальная папка для каждого юзера, куда автоматически спамяться версии файлов. В случае глюков залезли и восстановили.
Я вот только не понял зачем нужно дополнительно вызвать db.SaveAs в db_SaveComplete если операция сохранения уже выполнена. Теперь просто сохранённый файл нужно скопировать/переименовать в нужное место средствами .NET без использования AutoCAD .NET APIХорошая мысль, а как гарантированно получить имя сохраненного резервного файла?
а как гарантированно получить имя сохраненного резервного файла?
File.Copy(doc.Name, sb.ToString()); // второй параметр как раз и содержит имя, о котором спрашиваешь.
У вас прямо онлайн проектирование идет что ли с необходимостью не потерять и 10 минут?Бэкап делается один раз ночью. Если под конец рабочего дня у юзера повреждается файл, то у твоего пользователя работа целого дня идёт насмарку. Именно в виду этой проблемы (прежде всего) я и написал своё решение.
Вообще-то имя сохранённого файла будет e.FileName. В случае AutoSave оно будет отличаться от doc.NameЯ показывал вариант, когда очередное сохранение не затирает предыдущие. Для этого генерировал новое имя на основе даты и времени.
Я показывал вариант, когда очередное сохранение не затирает предыдущие. Для этого генерировал новое имя на основе даты и времени.Я не об этом, а о том в какое имя файла произошло сохранение. В случае автосохранения e.Filename содержит что-то типа "test_1_1_1191.sv$" (если мне не изменяет память). И именно этот файл, а не doc.Name нужно копировать (файл doc.Name не изменился если e.Filename != doc.Name)
максимум что можно потерять это один день в этом случае, но это уже совсем единичные случаи были (1 раз в несколько лет всречалось)1 день это непозволительная роскошь, когда счет сдачи проекта идет на часы и нет времени на исправления!
isavepercent установить в 0 или 100, а не в 50 - и всех делов.Это необходимое, но недостаточное условие для того, чтобы не потерять файл. :)
чтобы из bak файла не удалось восстановить файлНе охота включать создание bak файлов. Это сильно упрощает задачу восстановления, но ведет к дублированию информации на рабочих компьютерах и сетевых хранилищах.
чка Создавать резервные копии ?У кого как. Пользователи ее сами могут убрать, т.к. некоторых бесит создание левых файлов. А в случае восстановления бегут к нам.
Откровенно говоря, у меня крепнет подозрение, что надо не программу писать, а технологию проектирования чинить.+1
Вообще-то *.bak для того и существуют, чтобы при необходимости восстановить результаты работы. ИМХО решение сводится к установке isavepercent в 0 и savebak в 1. Принудительной автоматической установке.
Откровенно говоря, у меня крепнет подозрение, что надо не программу писать, а технологию проектирования чинить.
bak файлы пишутся в заданную папкуХм, тогда вопрос, где настроить, чтобы bak файл попадал в указанную папку, а не папку с чертежом.
Технология проектирования и логика бэкапов Автодеска, это 2 совершенно различные вещи.Но связанные.
Вы хотели бы, чтобы точки восстановления Windows маячили во всех папках файлов? Это то-же самое.Не то же самое.
Бэкап должен идти не мешая процессу проектирования не попадаясь на глаза до того момента, когда потребуется что-то восстановить.При открытии через AutoCAD файла dwg он и не виден.
абочая папка и папка бэкапов, это 2 различные папки в разных местах.Кто сказал? Лично я, например, против команды _movebak (причины Андрей Бушман уже описывал). В каталоге лежит два файла: test.dwg - рабочий и test.bak - страховая копия.
Если это сделано в целях удобства пользователей, типа глюк, а вот и резервная копия,В MS Excel / MS Word тоже можно настроить создание резервных копий файлов в разных вариантах. У MS тоже глюк?
проблемы с сохранением файлов слишком частыеС загаженными файлами - вполне вероятно. В нормально организованных файлах подобное обычно не наблюдается.
Написано же на первой странице - movebakМожно создать свой аналог этой команды, расширив её возможности. Например, создавая в каталоге с чертежом подкаталог BAK, в который будут попадать bak-файлы, а при необходимости и файлы автосохранения.
Написано же на первой странице - movebakПри активации создания bak файлов есть 2 типа файлов, одни в папке автосохранения, актуальны через заданные промежутки времени, и одна копия в текущей папке, которая не реагирует на автосохранение, только на нажатие сохранить, что полностью зависит от пользователя.
Откровенно говоря, у меня крепнет подозрение, что надо не программу писать, а технологию проектирования чинить.+1. Я что-то подобное опубликовывал здесь (http://bushman-andrey.blogspot.ru/2011/04/autocad.html) и вот ещё дополнительно (https://yadi.sk/d/6BvJtHQmgwuSw).
Скорее вредна,о чем мы с тобой недавно говорили.А можно и остальным узнать, чем вредна?
А можно и остальным узнать, чем вредна?Вредно работать с базой (Database) в методе Initialize, т.к. он может быть вызван еще до того, как база полностью сконструирована (в случае если загрузка сборки прописана в реестре) и к ней можно будет обращаться не опасаясь Fatal Error.
Что касается имён аля "test_1_1_1191.sv$", то они не информативны. Как определишь, какой из них относится к тому DWG, который хочешь восстановить, если каталог содержит *.sv$ всех файлов проекта?Предполагаю что это не проблема, т.к. это архив за 1-3 дня. Более поздние файлы будут автоматически удаляться. За это время проектировщики успеют поработать только с десятком файлов.