Bibliotecas de referencia de VBA

Question

Soy nuevo en VBA y he estado creando una pequeña macro para Office. Tenemos unos 80 usuarios en configuraciones de PC esencialmente idénticas, y todos los usuarios menos algunos usuarios tendrán acceso a ellos.

He estado jugando con la automatización del acceso a páginas web utilizando las referencias de servicios web, y también he cargado las referencias de Microsoft Scripting Runtime en el proyecto. Intenté ejecutarlo en una PC de prueba y se quejó de que faltaban referencias.

No quiero particularmente ir alrededor de 80 PC y cargar manualmente las referencias.

Mi pregunta, básicamente, es cómo debo gestionar la distribución de esta macro-aplicación a 80 usuarios impares para asegurarme de que las referencias se cargarán cada vez para cada usuario.

Gracias!

Answer 1

En lugar de que los documentos expongan la funcionalidad, conviértalo en un complemento para Office (el conjunto de aplicaciones o las aplicaciones individuales que elija). De esta manera, no tienes que lidiar con referencias.

Luego, simplemente distribuya un paquete de instalación con el complemento que registra los componentes y registra los complementos con las aplicaciones de Office apropiadas.

VB6 podría ser una buena idea aquí, dada su similitud con VBA.

Answer 2

Si tiene referencias de las que depende su aplicación, que sabe que no van a estar en las PC de destino, le recomiendo encarecidamente que investigue alguna tecnología de instalación.

Usando el instalador debería poder instalar su macro e instalar y registrar todas las referencias/bibliotecas apropiadas.

En general, existen dos versiones de Windows, la tecnología basada en Windows Installer y la tecnología basada en secuencias de comandos.

Usamos InstallShield para todas nuestras implementaciones, aunque hay varias opciones para su uso (hay varias discusiones sobre Desbordamiento de pila).

Utilizando la tecnología de instalación de Windows, puede compilar archivos de instalación de MSI, que luego podrá implementar automáticamente mediante la directiva de grupo.

Answer 3

Además de this answer, que es la solución a prueba de balas para resolver este tipo de problema, pero que es bastante complejo de implementar, también puede escribir algún código para ejecutar cuando se inicia su aplicación VBA, verificando las 'referencias 'colección del objeto' aplicación '. Luego puede verificar (1) si los archivos solicitados (dll, ocx, tlb) están disponibles en la computadora y (2) si se puede crear una referencia (application.references.addFromFile ...).

CUIDADO: declaraciones de objetos que podrían ser 'referencia dependiente', tales como:

Dim cat as ADOX.catalog 

elevará un error de compilación si la referencia no está activo cuando el módulo correspondiente es 'compilado'. Luego le aconsejo que aísle su 'procedimiento de verificación de referencia' en un módulo de inicio (equivalente a un 'autoexec') que trata solo con VBA y objetos básicos de la aplicación. Verifíquelo con sus archivos de ayuda (Ejemplo: en Access, las referencias predeterminadas que se pueden usar sin referencias externas son VBA, Access y DAO).

EDIT:

en el caso de las referencias externas dependen de otro paquete de software y (1) no puede ser distribuida con un archivo MSI o (2) puede tener múltiples versiones, creo que el 'references.addFromFile' es el único solución que se puede aplicar. Ejemplo:

• Tiene un/Acceso cliente de ejecución aplicación VBA que ha de hacer referencia a la Palabra (archivo Msword.olb).
• Por problemas de licencia, no se puede distribuir libremente este archivo con el paquete de MSI
• el archivo OLB puede ser el 'versión XP o una más reciente

Nuestra solución es tener 2 mesas en el cliente Archivo de acceso. Uno enumera todas las referencias que deben verificarse o agregarse en el momento del inicio (Word será una de ellas), y el otro enumera todas las ubicaciones posibles del archivo (dependiendo de si el usuario tiene la versión 'office11' o una más nueva) uno), con una relación de uno a muchos entre las 2 tablas.

Por lo tanto, la mejor estrategia podría ser una mezcla entre paquetes y gestión de MSI a través de código:

• MSI es ideal para distribuir DLL independientes u otros archivos que son totalmente 'incrustados' en su aplicación, tales como ActiveX controles (como controles de escáner, informes o visualizadores de archivos, etc.)
• código es la mejor solución donde su aplicación tendrá que comunicarse con otras aplicaciones (word, excel, outlook, etc.) que pueden existir en diferentes versiones en las máquinas de su usuario .

Answer 4

En su mayor parte, el enlace tardío resolverá problemas con referencias en VBA, a menos que tenga algunas referencias inusuales. La mayoría de los problemas son causados ​​por diferencias en las versiones de la biblioteca que pueden superarse con el enlace tardío. Con VBA, a menudo se recomienda que desarrolle con la vinculación temprana pero la liberación con la vinculación tardía. La principal desventaja de la ligadura dinámica está cambiando las constantes integradas a los valores (velocidad ya no es el tema que solía ser.)

Así:

Dim fs As Object 'Instead of FileSystemObject ' 
Dim xl As Object 'Instead of Excel.Application ' 

Set fs=CreateObject("Scripting.FileSystemObject") 
Set xl=CreateObject("Excel.Application") 

'Value instead of built-in constant ' 
ForReading=2 
Set f = fs.OpenTextFile("c:\testfile.txt", ForReading)