example - Excel VBA "Error de automatización" debido a la actualización de Office de enero de 2016, probablemente causada por MSCOMCTL.OCX(Microsoft Windows Common Controls 6.o(Service Pack 6))
excel vba treeview example (4)
Solución
He agregado un Treeview Active X Control a una de nuestras hojas de cálculo, usando Microsoft Windows Common Controls 6.0 (Service Pack 6), es decir, MSCOMCTL.OCX que vive en C:/Windows/SysWOW64/
KB2881029 (Actualización de seguridad para Microsoft Office 2010 edición de 32 bits) (MS16-004), expulsado de Microsoft el 15-01-2015 (aproximadamente), instala una nueva versión de MSCOMCTL.OCX (v6.1.98.46) que fue "Creado" en 2015-12-09, pero "Accesado" (es decir, instalado en la computadora) en el momento de la actualización.
Esto hizo que el libro de trabajo "pierda" la referencia a MSCOMCTL.OCX (comillas en "perder", porque la referencia todavía está marcada pero ya no funciona; el libro de trabajo no se compila debido a "Error de compilación: característica de biblioteca de objetos no compatible" o "Error de automatización").
Parece que la actualización modifica la siguiente clave de registro al agregar una SubKey 2.0, pero la deja en blanco y no registra la nueva MSCOMCTL.OCX :
HKEY_CLASSES_ROOT/TypeLib/{831FDD16-0C5C-11D2-A9FC-000F8754DA1}/
La solución del problema requiere tres pasos:
MSCOMCTL.OCXnecesita ser no registrado y volver a registrarse desde un símbolo del sistema elevado, de la siguiente manera:C:/Windows/system32>Regsvr32 /u C://Windows/SysWOW64/MSCOMCTL.OCX C:/Windows/system32>Regsvr32 C://Windows/SysWOW64/MSCOMCTL.OCX
Al registrar el nuevo
MSCOMCTL.OCX(Versión 6.1.98.46) a través de REGSVR32, se agrega una nueva clave al Registro:KEY_CLASSES_ROOT/TypeLib/{831FDD16-0C5C-11D2-A9FC-000F8754DA1}/2.2
Si existía una Subclave con el nombre 2.1 ya existente, ingresa una referencia que ahora es la clave 2.2 para su uso. ¡Pero no le hace nada a la SubKey 2.0 vacía!
Si hay una Subclave 2.0 (o 2.1 para esa materia) sin nada en ella, cualquier objeto que use ese OCX no debe crear porque usará la versión 2.0 (resp 2.1), no puede verificar y no verificó para 2.2 Versión.
Limpie el registro eliminando las claves erróneas o reemplazadas 2.0 y 2.1, dejando solo la clave 2.2 más reciente y en funcionamiento. Esto se puede hacer desde el Editor del Registro seleccionando HKEY_CLASSES_ROOT, Edit / Find / MSCOMCTRL.OCX.
(Nota: este paso parece opcional ya que he comprobado que hacer solo el paso 1 y 3 hizo que el libro de trabajo funcione nuevamente. Pero se siente como lo correcto)
En el proyecto de VBA del libro de Excel, los controles comunes de Microsoft Windows 6.0 (Service Pack 6) no necesitan referencias ni referencias. Volver a referenciar no es solo cuestión de volver a marcar la casilla, debe usar "Buscar" y seleccionar
MSCOMCTL.OCXenC:/Windows/SysWOW64/(Tenga en cuenta que, en la ventana del navegador, debe cambiar el tipo de archivo de "dll" a "OCX" (o "todo"))
Daniel Alexander Karr (consulte la publicación más adelante) ha compartido amablemente un guión que escribió para realizar los pasos 1 y 2 automáticamente (tenga en cuenta que debe ejecutarse como administrador).
Gracias Daniel y Wmelonman por su ayuda para comprender el problema y encontrar una solución.
Publicación original
De manera similar a lo que se describe en esta publicación de 3 años (Errores de automatización de VBA debido a Office Service Pack 3.0 causados por Formularios) , un libro de trabajo perfectamente funcional dejó de funcionar de un día para otro ...
En la lista de actualizaciones realizadas anoche, las siguientes son actualizaciones de Office:
- KB3114563 (Actualización de definición para Microsoft Office 2010 Edición de 32 bits)
- KB2881029 (Actualización de seguridad para Microsoft Office 2010 edición de 32 bits)
- KB3114555 (Actualización para Microsoft Office 2010 Edición de 32 bits)
- KB3114553 (Actualización de seguridad para Microsoft Office 2010 Edición de 32 bits)
- KB3114564 (Actualización de seguridad para Microsoft Excel 2010 edición de 32 bits)
Hubo otras actualizaciones, pero actualizaciones generales de Microsoft Windows, no específicas para Office, y con un poco de suerte no son relevantes aquí.
Según tengo entendido, el "Error de automatización" se debe a que el proyecto no se compila debido a la presencia de 2 controles ActiveX "adicionales" en uno de mis formularios al que he hecho referencia desde Microsoft Windows Common Controls 6.0 (Service Pack 6), es decir, MSCOMCTL.OCX que vive en C:/Windows/SysWOW64/
Desafortunadamente, el registro y la reinscripción de MSCOMCTL.OCX como se explica en la publicación mencionada anteriormente no resolvió el problema.
También traté de eliminar todo *.exd , pero no había ninguno en mi disco C: .
Información adicional que puede ser relevante:
- La versión del archivo
MSCOMCTL.OCXes6.1.98.46, se creó y se modificó por última vez el 12/12/2015 pero se accedió a las 3,33 a. M. (15/01/2016), es decir, aproximadamente al mismo tiempo que se produjeron las actualizaciones (a las 3:14 a.m. ) - Una vez pasado el mensaje inicial de "error de automatización", recibiría un mensaje adicional, "Error de compilación: característica de la biblioteca de objetos no compatible", resaltando las líneas de códigos asociadas con los controles adicionales.
- Verifiqué que estos estaban "causando" el problema creando un formulario en blanco y tratando de agregar uno. Recibí el mensaje de error "No se pudo completar la operación debido al error 800a0011".
- Estos controles adicionales son Microsoft TreeView Control 6.0 (SP6) y Microsoft ImageList Control 6 (SP6).
- Podría agregar Microsoft TreeView Control, Versión 5.0 (SP2) y Microsoft ImageList Control, Versión 5.0 (SP2) sin levantar el error (aunque no intenté hacerlos funcionar).
¿Alguien sabe de un MSCOMCTL.OCX similar con MSCOMCTL.OCX después de las actualizaciones de ayer de Microsoft? Eso puede confirmar que podría ser la fuente de mi problema.
¿Alguien sabe de una solución?
¿Alguien sabe cómo informar esto a Microsoft (si de hecho es la fuente del problema)?
Y, por último, para los interesados, hay una forma de evitar que Microsoft Updates estropee los controles ActiveX ... ¡no los use! Esto es lo que JPK ha hecho por su TreeView .
nuestro software Business-ERP Faktura-XP tuvo el mismo problema desde ayer, investigamos el problema y creamos un parche para él, tal vez ayudará a alguien:
http://www.faktura-xp.de/faktura-xp-download/update-und-patch-oeffentlich.html#toggle-id-4
En nuestro caso, TreeViewControl dejó de funcionar, pero será el mismo problema con la Automatización. Microsoft actualizó el MSCOMCTL.OCX a la Versión 2.2, si la Clave {831FDD16-0C5C-11D2-A9FC-000F8754DA1} tiene una Entrada 2.1 o 2.0 vacía, el Control Común dejará de funcionar. Solución: elimine las claves 2.0 y 2.1, deje 2.2, anule el registro de mscomctl.ocx y vuelva a registrarlo.
Nuestro parche hará exactamente esto, nada más, nada menos, pero lo más simple posible para nuestros clientes, simplemente haga clic en Siguiente y Cerrar.
Editado para más información:
HKEY_CLASSES_ROOT/TypeLib/{831FDD16-0C5C-11D2-A9FC-000F8754DA1}/2.2
se acaba de crear al registrar el nuevo MSCOMCTL.OCX (Versión 6.1.98.46) a través de REGSVR32
Cuando hay una SubKey llamada 2.1 ingresa una referencia que 2.2 es ahora la Clave de uso.
Si hay una Subclave 2.1 sin nada en ella, su Objeto no podrá crear porque usará la Versión 2.1, no puede y no verificó la Versión 2.2.
Elimina esta clave si es necesario y listo.
Pruebas adicionales muestran que 2.0 SubKey está obsoleta y podría causar problemas.
Mayormente sistemas con Microsoft Windows 7 tuvieron este problema. Para nuestro software, nadie con Windows 8.1 o Windows 10 llamó un problema después de la actualización actual.
Problema similar aquí: la aplicación Ancient Access 97 en XP antiguo (ya no por mucho tiempo, suspiro de alivio ) se detiene diciendo " Error 91: variable de objeto o con variable de bloque no establecida ". El examen mostró que sucede cuando se dirige el control de barra de progreso que reside en Mscomctl.ocx.
Descubrí que KB2881029 (MS16-004) es el culpable. Instala la nueva versión de MSCOMCTL.OCX. En las máquinas sin esta actualización, la aplicación de acceso funciona bien. Pero no es adecuado para la eliminación, al menos esto es lo que nuestro WSUS me dijo cuando iba a buscarlo. De todos modos, no nos gustaría vivir sin una actualización de seguridad.
Después de leer la respuesta sobre HKCR / TypeLib {831FDD16 ... Traté de eliminar la subclave todavía poblada / 2.0 antes de instalar la actualización solo para descubrir que incluso con una subclave / 2.0 no existente la actualización crea la vacía en la instalación. ¡Bien hecho, Microsoft ...!
Gracias a todos por sus contribuciones,
Descubrí que la eliminación de referencias y la referenciación de los controles comunes de Microsoft Windows 6.0 (Service Pack 6) en el proyecto Excel VBA finalmente lo haría funcionar.
!!!...PERO...!!!
Simplemente desmarcar / volver a marcar la casilla de verificación sería demasiado simple. Para volver a referenciarlo, debe usar "explorar" y seleccionar MSCOMCTL.OCX en c: / Windows / SysWOW64 /
(tenga en cuenta que, en la ventana del navegador, debe cambiar el tipo de archivo de "dll" a "OCX" (o "todo"))
Intenté simplemente hacer esto en una máquina donde no había ejecutado el parche de Daniel Alexander (para anular el registro y volver a registrar MSCOMCTL.OCX, y eliminar la antigua clave vacía 2.0 del registro), y no funcionó, así que espero que se requieran los pasos anteriores. Intentaré probar exhaustivamente qué pasos son necesarios y editaré esta respuesta para deletrear todo el procedimiento, paso a paso, pero por el momento ejecutaré el parche de Daniel Alexander (¡COMO ADMINISTRADOR!) Y volveré a referirme a Microsoft Windows Common Controls 6.0 (Servicio Paquete 6) en el proyecto Excel VBA parece funcionar.
El problema ha sido descrito en detalle aquí:
"Mensajes de error o bloqueos de acceso después de instalar la actualización de seguridad MS16-004"
MS: ID del artículo: 3139567
(Última revisión: 16/02/2016 19:15:00 - Revisión: 3.0)