Sub CheckReference()
Dim vbProj As VBProject ' This refers to your VBA project.
Dim chkRef As Reference ' A reference.
' Refer to the activedocument's VBA project.
Set vbProj = ActiveDocument.VBProject
' Check through the selected references in the References dialog box.
For Each chkRef In vbProj.References
' If the reference is broken, send the name to the Immediate Window.
If chkRef.IsBroken Then
Debug.Print chkRef.Name
End If
Next
End Sub
У тебя проблема наверное в том, что пока ocx не зарег. низя открывать никакие проекты, да и потом, у меня например ситуация немного другая, я свою форму с ocx импортирую в локальный Personal.xls, так вот вначале надо в проекте Personal.xls подключить ссылку на уже зарег. ocx и только потом уже импортировать в него форму с ocx. Иначе форма импортнется без ocx и с ругательством, а потом начнется такая же канитель как и у тебя.
Excel и OCX
Здравствуйте!
Не очень понимаю почему так происходит и что неправильно?
У меня есть Excel-вский проект и я хочу использовать в нем свой OCX-контрол. Tools-References ставлю галочку, эксель говорит, что компонент лежит по пути "D:\WINNT\SYSTEM32\TProject.ocx". Все работает. Переписываю проект и OCX на другую машину, винда там лежит на диске C:\. Естественно, OCX кладу в "C:\WINNT\SYSTEM32". Регистрю OCX, запускаю проект - ошибка выполнения - "Метод объекта TProject такой-то не найден". Контролы на листах не показывают юзер-интерфейс, а просто в виде белых квадратов. Лезу в референсы VBA - путь к OCX-у экселевский проект видит старый "D:\WINNT...". Думаю, ладно, фиг с ним, пытаюсь удалить этот референс, VBA говорит - "This reference in use" (И это несмотря на то, что путь указывает в воздух!). Приходится удалять контрол из проекта, сохранять его, закрывать (иначе все равно референс удалить не удастся), открывать, удалять старый референс, и ставить новый по реальному пути "C:\WINNT\SYSTEM32\TProject.ocx", вставлять контрол на листы (у меня он на нескольких листах) и тогда опять все ОК, но жутко непрактично.
Думаю ладно, буду подключать динамически через References.AddFromGuid, и далее, используя OLEObjects.Add, повешу контрол на листы. При закрытии книги, делаю OLEObjects.Delete и пытаюсь сделать References.Remove, на что получаю тот же ответ - "This reference in use". Хоть прямо на VBA сохраняйся, закрывайся, открывайся и удаляй... И вообще как-то криво все это.
Люди, помогите как сделать по-человечески, чтоб работало независимо от размещения OCX-а. Я бы OCX в текущий каталог сунул, но VBA все равно запомнит полный путь и при его изменении все по новой... (И почему Excel такой тупой? Если есть GUID, на кой ляд путь запоминать, и потом еще нагл ругаться...)
Не очень понимаю почему так происходит и что неправильно?
У меня есть Excel-вский проект и я хочу использовать в нем свой OCX-контрол. Tools-References ставлю галочку, эксель говорит, что компонент лежит по пути "D:\WINNT\SYSTEM32\TProject.ocx". Все работает. Переписываю проект и OCX на другую машину, винда там лежит на диске C:\. Естественно, OCX кладу в "C:\WINNT\SYSTEM32". Регистрю OCX, запускаю проект - ошибка выполнения - "Метод объекта TProject такой-то не найден". Контролы на листах не показывают юзер-интерфейс, а просто в виде белых квадратов. Лезу в референсы VBA - путь к OCX-у экселевский проект видит старый "D:\WINNT...". Думаю, ладно, фиг с ним, пытаюсь удалить этот референс, VBA говорит - "This reference in use" (И это несмотря на то, что путь указывает в воздух!). Приходится удалять контрол из проекта, сохранять его, закрывать (иначе все равно референс удалить не удастся), открывать, удалять старый референс, и ставить новый по реальному пути "C:\WINNT\SYSTEM32\TProject.ocx", вставлять контрол на листы (у меня он на нескольких листах) и тогда опять все ОК, но жутко непрактично.
Думаю ладно, буду подключать динамически через References.AddFromGuid, и далее, используя OLEObjects.Add, повешу контрол на листы. При закрытии книги, делаю OLEObjects.Delete и пытаюсь сделать References.Remove, на что получаю тот же ответ - "This reference in use". Хоть прямо на VBA сохраняйся, закрывайся, открывайся и удаляй... И вообще как-то криво все это.
Люди, помогите как сделать по-человечески, чтоб работало независимо от размещения OCX-а. Я бы OCX в текущий каталог сунул, но VBA все равно запомнит полный путь и при его изменении все по новой... (И почему Excel такой тупой? Если есть GUID, на кой ляд путь запоминать, и потом еще нагл ругаться...)
Цитата:
Originally posted by creasysee
Здравствуйте!
Не очень понимаю почему так происходит и что неправильно?
У меня есть Excel-вский проект и я хочу использовать в нем свой OCX-контрол. Tools-References ставлю галочку, эксель говорит, что компонент лежит по пути "D:\WINNT\SYSTEM32\TProject.ocx". Все работает. Переписываю проект и OCX на другую машину, винда там лежит на диске C:\. Естественно, OCX кладу в "C:\WINNT\SYSTEM32". Регистрю OCX, запускаю проект - ошибка выполнения - "Метод объекта TProject такой-то не найден". Контролы на листах не показывают юзер-интерфейс, а просто в виде белых квадратов. Лезу в референсы VBA - путь к OCX-у экселевский проект видит старый "D:\WINNT...". Думаю, ладно, фиг с ним, пытаюсь удалить этот референс, VBA говорит - "This reference in use" (И это несмотря на то, что путь указывает в воздух!). Приходится удалять контрол из проекта, сохранять его, закрывать (иначе все равно референс удалить не удастся), открывать, удалять старый референс, и ставить новый по реальному пути "C:\WINNT\SYSTEM32\TProject.ocx", вставлять контрол на листы (у меня он на нескольких листах) и тогда опять все ОК, но жутко непрактично.
Думаю ладно, буду подключать динамически через References.AddFromGuid, и далее, используя OLEObjects.Add, повешу контрол на листы. При закрытии книги, делаю OLEObjects.Delete и пытаюсь сделать References.Remove, на что получаю тот же ответ - "This reference in use". Хоть прямо на VBA сохраняйся, закрывайся, открывайся и удаляй... И вообще как-то криво все это.
Люди, помогите как сделать по-человечески, чтоб работало независимо от размещения OCX-а. Я бы OCX в текущий каталог сунул, но VBA все равно запомнит полный путь и при его изменении все по новой... (И почему Excel такой тупой? Если есть GUID, на кой ляд путь запоминать, и потом еще нагл ругаться...)
Здравствуйте!
Не очень понимаю почему так происходит и что неправильно?
У меня есть Excel-вский проект и я хочу использовать в нем свой OCX-контрол. Tools-References ставлю галочку, эксель говорит, что компонент лежит по пути "D:\WINNT\SYSTEM32\TProject.ocx". Все работает. Переписываю проект и OCX на другую машину, винда там лежит на диске C:\. Естественно, OCX кладу в "C:\WINNT\SYSTEM32". Регистрю OCX, запускаю проект - ошибка выполнения - "Метод объекта TProject такой-то не найден". Контролы на листах не показывают юзер-интерфейс, а просто в виде белых квадратов. Лезу в референсы VBA - путь к OCX-у экселевский проект видит старый "D:\WINNT...". Думаю, ладно, фиг с ним, пытаюсь удалить этот референс, VBA говорит - "This reference in use" (И это несмотря на то, что путь указывает в воздух!). Приходится удалять контрол из проекта, сохранять его, закрывать (иначе все равно референс удалить не удастся), открывать, удалять старый референс, и ставить новый по реальному пути "C:\WINNT\SYSTEM32\TProject.ocx", вставлять контрол на листы (у меня он на нескольких листах) и тогда опять все ОК, но жутко непрактично.
Думаю ладно, буду подключать динамически через References.AddFromGuid, и далее, используя OLEObjects.Add, повешу контрол на листы. При закрытии книги, делаю OLEObjects.Delete и пытаюсь сделать References.Remove, на что получаю тот же ответ - "This reference in use". Хоть прямо на VBA сохраняйся, закрывайся, открывайся и удаляй... И вообще как-то криво все это.
Люди, помогите как сделать по-человечески, чтоб работало независимо от размещения OCX-а. Я бы OCX в текущий каталог сунул, но VBA все равно запомнит полный путь и при его изменении все по новой... (И почему Excel такой тупой? Если есть GUID, на кой ляд путь запоминать, и потом еще нагл ругаться...)
С самого начало нужно было ocx брасать в system32 и регистрировать , а только потом потключать к проекту...
Я так всегда делаю и нет проблем , а Excel действительно тупой в этом отношении....
Цитата:
Originally posted by vladsoft
С самого начало нужно было ocx брасать в system32 и регистрировать , а только потом потключать к проекту...
Я так всегда делаю и нет проблем , а Excel действительно тупой в этом отношении....
С самого начало нужно было ocx брасать в system32 и регистрировать , а только потом потключать к проекту...
Я так всегда делаю и нет проблем , а Excel действительно тупой в этом отношении....
Так как же быть, если это продукт для конечных пользователей, не будут же тети и дяди, например бухгалтеры, регистрить и вставлять в проект OCX ручками...
Цитата:
Originally posted by creasysee
Так как же быть, если это продукт для конечных пользователей, не будут же тети и дяди, например бухгалтеры, регистрить и вставлять в проект OCX ручками...
Так как же быть, если это продукт для конечных пользователей, не будут же тети и дяди, например бухгалтеры, регистрить и вставлять в проект OCX ручками...
Сейчас сам занимаюсь подгтовкой готовых дистрибутивов с макросами Excel (с доп. ocx на борту), последовательность такая:
1. скопировать ocx в дир.
2. зарегистрировать ocx.
3. потом подсоедин. к Excel и дин. проверяем и подключаем ссылку на ocx. Делается это через VBProject.References, например так:
Код:
Цитата:
Originally posted by SergeySV
1. скопировать ocx в дир.
2. зарегистрировать ocx.
3. потом подсоедин. к Excel и дин. проверяем и подключаем ссылку на ocx.
1. скопировать ocx в дир.
2. зарегистрировать ocx.
3. потом подсоедин. к Excel и дин. проверяем и подключаем ссылку на ocx.
Дело, очевидно, несколько в другом. OCX естественно уже зарегистрен - его инсталшилд регистрит при инсталляции и машину перегружает, т.е. раньше проект не открыть. Но, если в системе OCX с таким GUID уже установлен, но только не по тому пути - в референсах не пишется MISSING, и, как следствие, isBroken возвращает false, на листах белые квадраты с объектами, но OLEObjects.Object у них паталожный. Т.е. Нужно полюбому сначало грохать контролы на листах, затем, грохать референсы, а только потом подключать по новому пути. Так проблема опять же остается! Не удалить референс на отсутствующий путь без сохранения без контролов на листах и повторного открытия.
Прям ужас какой-то. Поубивав бы утех, хто Ексель писАл!
Цитата:
Originally posted by creasysee
Но, если в системе OCX с таким GUID уже установлен, но только не по тому пути - в референсах не пишется MISSING, и, как следствие, isBroken возвращает false, на листах белые квадраты с объектами, но OLEObjects.Object у них паталожный.
Но, если в системе OCX с таким GUID уже установлен, но только не по тому пути - в референсах не пишется MISSING, и, как следствие, isBroken возвращает false, на листах белые квадраты с объектами, но OLEObjects.Object у них паталожный.
Если брать твой объяснение, то по нему могу сказать следующее.
В свое время я изучал пример базы Access, где товарищ при запуске базы поверял ссылки (References), и там я помню как раз чувак дополнял свой код кроме IsBroken доп. проверкой пути этого ocx потому что как раз и утверждал, что IsBroken показывает не все - для меня эта функция проверки целостности ссылок стала примером. Ща попробую для тебя найти ее.
Во, зайди сюда, почитай, там чувак все грамммотно рассписал.... разницы в этом случае между VBA и VBE особенной нет, прнцип работы с сылками тотже.
http://am.rusimport.ru/MsAccess/topic.aspx?ID=127
Вообщем, по идее все можно настроить.
Я щас пока копаюсь с уровнем безопасности (мы этого уже обсуждали с mhaturov в одном из топиков), чтобы пользователям не надо было ничего ручками менять при установки новых макросов. Потом все протестю, опробую и опишу что у меня получилось и насколько все это автоматически работает.
http://am.rusimport.ru/MsAccess/topic.aspx?ID=127
Вообщем, по идее все можно настроить.
Я щас пока копаюсь с уровнем безопасности (мы этого уже обсуждали с mhaturov в одном из топиков), чтобы пользователям не надо было ничего ручками менять при установки новых макросов. Потом все протестю, опробую и опишу что у меня получилось и насколько все это автоматически работает.