Trucos

Superior  Previo  Próximo

Nota para Usuarios de Visual Basic 5/6

Los usuarios de Visual Basic 5/6 deberían tener en cuenta que el número de versión de la interfaz de EA se almacena en el archivo de proyecto VBP en una forma similar a la siguiente: 

 

Reference=*\G{64FB2BF4-9EFA-11D2-8307-C45586000000}#2.2#0#..\..\..\..\Program Files\Sparx Systems\EA\EA.TLB#Enterprise Architect Object Model 2.02 

 

Si experimenta problemas al moverse de una versión de EA a otra, abra el archivo VBP en un editor de texto y elimine esta línea. Luego abra el proyecto en Visual Basic y use Proyecto-Referencias para crear una nueva referencia al modelo de Objetos de EA.

 

El Add-In falló al descargar

 

En la liberación 7.0 de EA los Add-ins creados antes del 2004 no son soportados. Si un Add-In subscribe a una interfaz (estilo 2003), este fallará al descargar. En este caso, contacte al vendedor o autor del Add-In y requiera una actualización.

 

Manteniendo la Información del Estado

 

Es posible para un Add-in mantener información de estado, significando que los datos se pueden almacenar en variables miembros en respuesta a un evento y recuperarlos en otro. Existen algunos peligros al hacer esto: 

Los Objetos de Automatización de EA no se actualizan ellos mismos en respuesta a una actividad del usuario, para la actividad en otras estaciones de trabajo, o incluso para las acciones de otros objetos en el mismo cliente de automatización. La retención de manejadores para tales objetos entre llamadas puede dar como resultado en el segundo evento de consulta de objetos que no tenga relación con el estado actual de EA.
Cuando los usuarios le piden a EA que se cierre, se les pide a todos los Add-ins que se cierren. Si hay algunos clientes de automatización externos EA necesitará permanecer activo, en cuyo caso todos los add-ins serán cargados nuevamente -perdiendo todos los datos-. 
Si EA actúa como un cliente de automatización no se cerrará si un Add-in aún mantiene una referencia en él (liberando todas las referencias en el evento Disconnect() evita este problema). 

 

Se recomienda que a menos que haya una razón específica para hacer eso, el add-in debería usar el parámetro del repositorio y sus métodos y propiedades para proveer los datos necesarios. 

 

EA No se Cierra

 

Incidencias Específicas de .Net

La automatización verifica el uso de objetos y no permitirá que ninguno de ellos sea destruido hasta que no se use más. 

 

Como se indicó en la sección de la Interfaz de automatización, si su controlador de automatización se escribió usando el framework de .NET, EA no se cerrará aun después de que haya liberado todas sus referencias a él. Para forzar la liberación de todos los punteros COM, llame a las funciones de administración de memoria como se muestra abajo: 

 

GC.Collect(); 

GC.WaitForPendingFinalizers(); 

 

Adicionalmente, debido a que los clientes de automatización se conectan a EA el cual crea Add-ins los cuales a su vez se conectan de nuevo a EA, es posible ingresar en una situación sin salida en donde EA y los Add-ins no se dejarán uno de otro y se mantendrán uno al otro activo. Un Add-in puede retener su conexión a EA porque: 

Mantiene una referencia privada a un objeto de EA (vea Manteniendo Información del Estado más arriba). 
Fue creado por  .NET y el mecanismo GC no lo liberó. 

 

Hay dos acciones que se requieren para evitar las situaciones sin salida: 

Los controladores de automatización deben llamar a Repository.CloseAddins() en algún punto (presumiblemente al final del procesamiento). 
Los Add-ins deben liberar a todas las referencias a EA en el evento Disconnect(). Vea la página Métodos Add-Ins para más detalles. 

 

Es posible que su cliente de Automatización controle una instancia de ejecución de EA donde los Add-Ins no cumplieron la regla de arriba. En este caso puede desear llamar a Repository.Exit() para terminar EA. 

 

Misceláneas

Al desarrollar add-ins usando el framework .Net se le requerirá seleccionar la Interoperabilidad de COM en las propiedades del proyecto para que se lo reconozca como un add-in. 

 

Algunos ambientes de desarrollo no registran automáticamente DLLS COM en la creación. Puede necesitar hacer eso manualmente antes de que EA reconozca el Add-In. 

 

Puede usar su clave privada de Add-In (como se requiere para el despliegue de Add-in) para almacenar información de configuración pertinente a su Add-in.

 

Llamadas concurrentes

En las liberaciones de EA hasta la liberación 7.0, hay una posibilidad de que EA pueda llamar dos métodos de Add-In concurrentemente si el Add-In:

Un casilla de mensaje
Una ventana modal
VB DoEvents, Aplicación .NET DoEvents o el equivalente en otros lenguajes.

 

En estos casos, EA puede iniciar un segundo método de Add-In antes de que el primero retorne (re-entrar). En la liberación 7.0 y liberaciones subsecuentes, EA no puede realizar llamadas concurrentes.

 

Si desarrolla Add-Ins, asegúrese que los usuarios del Add-In se ejecuten en la liberación 7.0 de EA o liberaciores posteriores para evitar cualquier riesgo de llamadas de métodos concurrentes.