Для чего это нужно: делаю программу обработки прайс-листов.
Среди них попадаются файлы в формате Excel 4 (какой-то древний формат) Excel мало того, что блокирует их редактирование (мне это пофиг, я работаю с этими прайсами в ReadOnly), так ещё и макросы начинают вести себя очень странно (жмём кнопку на панели инструментов - если активен файл Excel4, макрос не запускается, если любая другая книга - всё ОК)
Самое интересное, что макрос обращается к единственному свойству активной книги - activeworkbook.fullname И этого обращения к свойству древнего файла достаточно, чтобы Excel 2010 остановил все макросы.
Кстати, файлы Excel4 не отображаются в редакторе VBA
PS: Тестирую программу на Excel 2010 Макрорекордер не пишет изменение этих настроек
Прикрепить файл Excel4 не могу, так как он по размеру около мегабайта, а удалить лишние строки для уменьшения объёма файла Excel не позволяет. Поэтому выложил книгу в древнем формате на сайте: <EM>http://ExcelVBA.ru/XL_Files/excel4.rar</EM>
Уф! Думаю, дело - дрянь. Врядли эти настройки сделаны для того, чтобы их можно изменить через код (кому нужна такая безопасность?). Может через ADO тащить данные?
Прошу прощения за глупый вопрос, а файлы обязательно должны оставаться в формате Excel 4? Или всё таки их можно сохранить в более новом формате?
По поводу системы безопасности от макросов в MS Office, то в 2007 она страдает параноей. Так если ставишь макрос, который при закрытии книги ставит защиту структуры в Excel, то при следующем открытии макросы будут отключены напрочь, и офису до лампочки, что файл в безопасном расположение и все макросы разрешены, пока не удалишь этот макрос.
Пользователи, как школьники, учиться хотят далеко не все, а отличниками становятся единицы. Проблема - это ситуация, в решении которой человек не заинтересован.
1) Если бы файлы можно было пересохранить в другой формат макросом (например на компе, где злосчастные галочки уже убраны), то в этом бы не было необходимости, т.к. можно было бы считать информацию там же и тогда же.
2) Если бы файлы можно было пересохранить в другой формат вручную, то наверное можно было бы изъять информацию вручную. Скорее всего файлов много и они не находятся в одном месте и в одно и то же время
3) Вероятно, что нет явного формального признака, по которому можно заранее определить сохранен ли файл в Excel4, пока его не откроешь и не заблокируешь макросы
4) Насчет паранойи, можно посмотреть пример в файле?
Увы, через ADO тащить данные - не вариант. Обрабатываемые прайс-листы имеют различную структуру, пароли на открытие, и т.д. Кроме того, кое-где в качестве исходных данных используется структура (группировка), и форматирование ячеек) Так что только макрос справится.
Придётся сделать инструкцию для пользователей - типа, если у вас Excel 2010, сначала зайдите туда-то, и уберите все галочки.
Пользователи, как школьники, учиться хотят далеко не все, а отличниками становятся единицы. Проблема - это ситуация, в решении которой человек не заинтересован.
DEADMAN, Это не глупость, а нормальная реакция, пока сам с таким не столкнешься :) Насчет паранойи, у меня в XL2007 макросы отключаются независимо от формата файла или применения защиты структуры :0 В XL2010 это происходит только при первом открытии.
Согласно вашим советам, сделал макрос, после выполнения которого файлы Excel4 начинают открываться без уведомлений:
Sub DeleteFileBlock() On Error Resume Next Key$ = "HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Excel\Security\FileBlock\" arr = Array("XL2Macros", "XL2Worksheets", "XL3Macros", "XL3Worksheets", _ "XL4Macros", "XL4Workbooks", "XL4Worksheets") For Each Item In arr CreateObject("WScript.Shell").RegWrite Key$ & Item, 0, "REG_DWORD" Next End Sub
Теперь достаточно запускать этот макрос при открытии Excel, и о проблеме можно забыть.
Честно говоря, я исходил (наверное ошибочно) из той предпосылки, что программа предназначена для клиента, и что нельзя быть уверенным в том, что у пользователя будут права админа в Windows. Если я не ошибался, то наверное стоило бы потестировать код в режиме non-elevated. Если память мне не изменяет, в Windows XP проблем быть не должно, а вот в Windows Vista и 7...
Вообще-то я думал, что при записи в ветку HKEY_CURRENT_USER не должно быть проблем и без админских прав.
На днях тестировал свою надстройку с автообновлением и активным пользованием реестра (в ветке HKEY_CURRENT_USER) под пользовательской учёткой на Windows Server 2008 - всё отлично работает, в реестр всё пишется.
Так что, полагаю, и в других версиях ОС проблем быть не должно. А вот при записи в HKLM наверняка возникнет ошибка.
Протестировать не могу - являюсь приверженцем Windows XP (не нравятся мне все эти висты и семерки), и на всех компах у меня только XP
XP конечно гораздо удобнее в администрировании, но Вы же разработчик, как можно быть таким принципиальным (= Вечерком проверю дома на семерке, отпишусь.
Протестировал, как обещал на связке Win7-Office 2010. Макрос DeleteFileBlock() отработал корректно.
"Вообще-то я думал, что при записи в ветку HKEY_CURRENT_USER не должно быть проблем и без админских прав." Спросил у своих админов на работе. Говорят, что этот раздел тоже можно защитить от изменений. Наверно, это нецелесообразно просто. Но теоретическая возможность есть.