PRB: La automatización COM entre procesos puede bloquear la aplicación de cliente en Windows 95 ó 98

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 216400
Este artículo se ha archivado. Se ofrece "tal cual" y no se volverá a actualizar.
Síntomas
Cuando un servidor de COM de fuera de proceso desde una aplicación cliente de automatización, si el código de cliente entra en un bucle estrecha o realiza solicitudes amplio para obtener nuevas interfaces de la aplicación cliente podría dejar de responder durante una llamada de automatización, requerir que el usuario terminar el proceso de forma anormal. Una vez bloqueado, error en la cualquier solicitud de COM que implican una interfaz de referencias calculada. Se requiere un reinicio para solucionar el problema.

El problema se produce sólo en sistemas Windows 95 y Windows 98.
Causa
Cuando se calculan referencias de una interfaz a través de límites de proceso, se crean un número de objetos del sistema para controlar la comunicación entre los procesos cliente y servidor. Esto incluye el proxy/stub, junto con los OID y OXID necesarios por COM para identificar la interfaz que se calculan las referencias. Cuando se suelta la interfaz por el proceso de cliente, estos objetos se destruirán durante la recolección de elementos.

Por diseño, COM utiliza diferida de recolección para liberar recursos del sistema que ya no son necesarios. Esta colección se produce durante períodos de relativa inactividad. Si una aplicación cliente no proporciona suficiente tiempo libre para la recolección se produzca, es posible que el sistema se quede sin recursos y ya no podrá calcular referencias de interfaces. Si esto sucede, la propia capa COM puede dañarse, impidiendo que más recolección de elementos no utilizados hasta que se reinicie el sistema.

La causa más común para el problema es que el código del cliente ha escrito un bucle ajustado o está realizando un periodo intenso de automatización que implican a una jerarquía de objetos anidados, donde se realizan las llamadas sucesivas para obtener y liberar numerosos objetos fuera de proceso en un breve período de tiempo. Por ejemplo, en el siguiente ejemplo de código se muestra una jerarquía de objeto anidado que requiere tres interfaces que calcularse cada vez que se llama al método PrintOut. Puesto que el código se ejecuta en un bucle ajustado, el número total de que se calculan las referencias de interfaces es 30:
   For i = 1 To 10      oExcel.ActiveWorkbook.Sheets(i).UsedRange.PrintOut   Next i				
para Windows 95 y Windows 98, el número total de interfaces que se pueden calcular referencias a la vez es aproximadamente 65.536.
Solución
Los desarrolladores deben minimizar el número de referencias de objeto solicitan durante bucles estrecha o períodos mucho de automatización. Si una interfaz es necesaria más de una vez, debe ser mantenido en y usa repetidamente en lugar de publicada y reacquired varias veces en sucesión.

Por ejemplo, esta versión modificada del ejemplo anterior se realiza la misma tarea pero sólo requiere dos interfaces de calcularse para cada llamada de imprimir (una reducción del 30 por ciento desde el código anterior):
   Set oBook = oExcel.ActiveWorkbook   For i = 1 To 10      oBook.Sheets(i).UsedRange.PrintOut   Next i				
otra posible solución podría ser mover algunos de los código de automatización de procesos al servidor, si el servidor permite secuencias de comandos en el proceso. Por ejemplo, productos de Microsoft Office incorporan VBA secuencias de comandos para la automatización interna. Moviendo el código del bucle en un módulo de VBA, podría evitar el cálculo de referencias varias interfaces y en su lugar invocar una macro que permite al servidor realizar todo el trabajo.
Referencias
Para obtener información adicional, consulte en contacto con el siguiente artículo en Microsoft Knowledge Base:
219905Cómo: Agregar dinámicamente y ejecutar una macro VBA desde VBA

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 216400 - Última revisión: 01/11/2015 02:28:20 - Revisión: 4.4

Microsoft Windows 95, Microsoft Windows 98 Standard Edition, Microsoft Windows Millennium Edition

  • kbnosurvey kbarchive kbmt kbautomation kboleapp kbprb KB216400 KbMtes
Comentarios