Complementos del Analizador de trayecto
Los complementos son archivos de código (normalmente .prg o .scx) que proporcionan un método sencillo para reajustar el Analizador de trayecto. La subclase cov_standard del motor de trayecto, que engloba la interfaz de usuario de Coverage.app, sólo muestra una pequeña parte de lo que puede hacer con el motor. El motor analiza el registro de trayecto; mientras que cov_standard simplemente muestra el resultado en una de las numerosas formas en que puede obtenerse.
Puede crear una subclase de cov_engine distinta con una presentación muy diferente. Por ejemplo, esa subclase podría mostrar un cuadro de diálogo que ejecutase consultas sobre las estadísticas de trayecto reunidas por el motor. Las opciones de presentación podrían ofrecer una vista del código marcado para un conjunto filtrado de entradas del registro o únicamente un gráfico con los resultados de perfilado.
Es posible que desee que una subclase cov_engine no cree una nueva interfaz a partir de cero, ya que la clase cov_engine proporciona un proceso más sencillo. Puede agregar funcionalidad a cov_standard, o a cualquier subclase cov_engine, mediante los complementos. Cov_standard expone esta característica a través de un botón del cuadro de diálogo principal del Analizador de trayecto. Al ejecutar un complemento en una instancia de cov_standard, como por ejemplo el Analizador de trayecto, el complemento puede manipular la capacidad de cov_engine, las tablas de trayecto y también cov_standard. Los complementos podrían además agregar nuevos cuadros de diálogo y otras características a la interfaz visual de cov_standard.
Escribir complementos
Puede escribir complementos para mejorar la interfaz estándar o bien puede crear una subclase de cov_standard para formar su propia interfaz, completamente nueva.
Mejorar la aplicación estándar
En la lista siguiente se incluyen características que se pueden proporcionar mediante complementos:
Agregar una característica visible al cuadro de diálogo principal.
Agregar un cuadro de diálogo al conjunto de formularios del motor de trayecto (observe más abajo la limitación sobre la forma de asegurarse de que el cuadro de diálogo aparezca en el lugar correcto).
Mostrar un cuadro de diálogo aparte para tener acceso a una característica del motor de trayecto (observe más abajo la limitación sobre la forma de asegurarse de que el cuadro de diálogo aparezca en el lugar correcto).
Proporcionar una interfaz de consultas que utilice la tabla de origen y presente una lista con todas las líneas que cumplan los criterios, y que filtre y ordene el resultado.
Nota Puede utilizar los métodos Adjust… del motor (AdjustCoverageFilenameCursor( ), AdjustSourceCursor( ) y AdjustTargetCursor( )) para agregar campos a las tablas de origen y destino cuando el motor las crea, y utilizar esos campos en los complementos.
Agregar nombres de archivo al cursor IgnoredFiles, para descartar esos archivos del análisis. Así se puede ahorrar tiempo de análisis.
Utilizar el enganche especial Init para los complementos.
Registrar los complementos para recuperarlos y tener acceso a los mismos fácilmente desde una lista.
La clase de diálogo modal cov_AddInDialog de la subclase del motor de trayecto estándar presenta en una lista desplegable los cuadros de diálogo registrados previamente. Al establecer el valor ON en la opción IRegisterAdd-In del motor de trayecto, se agrega al Registro de Windows la ruta de acceso completa de los complementos ejecutados correctamente, lo que permite volver a ejecutarlos fácilmente. La clase Standard UI también permite establecer esta propiedad en el cuadro de diálogo Opciones del Analizador de trayecto.
El objeto Coverage Engine mantiene en la propiedad aAddIns una lista con todos los complementos registrados.
Utilizar la información de los campos del archivo final coverage.log, la pila de llamadas, para diseñar su propia interfaz o su propia vista del registro de trayecto.
Al escribir complementos, considere lo siguiente:
- Puede utilizar cualquiera de los tipos de archivo admitidos como complementos. Los tipos de archivo admitidos son .qpr, .qpx, .mpr, .mpx, .app, .exe, .scx, .fxp, .prg y los procedimientos (si ya están disponibles en una biblioteca de procedimientos abierta).
- El conjunto de formularios del Motor de trayecto tiene una barra de herramientas "invisible". Si un complemento no es visual, puede utilizar esta barra de herramientas para que lo contenga. Si el complemento es un control visual, probablemente el lugar más adecuado para ubicarlo sea el contenedor del miembro .Cov_tools del cuadro de diálogo principal de la subclase estándar. De este modo, la posición y tamaño de la barra de herramientas se sincronizará automáticamente con el resto del cuadro de diálogo al cambiar el tamaño de éste.
- Todos los métodos del motor que utilizan las tablas de origen y destino tienen argumentos opcionales que permiten al usuario que dichos método apunten en los alias correspondientes mientras trabaje con ellos. También puede cambiar el contenido actual de las propiedades cSourceAlias y cTargetAlias para hacerlo coincidir con el par de cursores que le interesen. Así podrá comparar diversas ejecuciones del registro de trayecto entre sí desde la misma interfaz.
- Limitaciones:
- Los complementos deben aceptar un parámetro (el motor de trayecto se transfiere una referencia a sí mismo).
- Los complementos deben ser de uno de los tipos de archivo permitidos indicados anteriormente.
- Los procedimientos que se utilicen como complementos deben estar disponibles en una biblioteca de procedimientos actualmente cargada (vea SET PROCEDURE) en la Ayuda. El motor no utiliza la sintaxis IN NombreArchivo y no llama a los procedimientos ni a los archivos .prg como funciones, ni obtiene sus valores con RETURN. Tampoco utiliza las palabras clave NAME o LINK en el comando DO FORM, por lo que puede administrar usted mismo la referencia o hacer que el formulario sea miembro del conjunto de formularios del motor para que éste lo alcance automáticamente.
- Si ejecuta un complemento al inicio deberá utilizar una referencia, ya que la variable pública _oCoverage aún no estará disponible. En las demás ocasiones, puede utilizar la referencia de variable pública en el código propio, si lo prefiere.
- Al escribir un complemento como un formulario, si crea el formulario con ShowWindow = 1 y ejecuta el trayecto en su propio marco, los formularios complemento deberán aparecer en el marco del trayecto.
- Si utiliza .RunAddIn desde la ventana Comandos, asegúrese de que el marco del trayecto sea el marco MDI activo antes de crear instancias de los formularios.
Crear una subclase de la clase Cov_Standard
Puede crear una subclase del motor de trayecto o de su subclase estándar. En la lista siguiente se describe la estructura del conjunto de archivos de origen del proyecto COVERAGE.
| Archivo | Descripción |
|---|---|
| Coverage.prg | "Envoltura" del objeto Coverage, que crea una instancia el objeto. |
| Coverage.vcx Coverage.vct |
Todas las clases del motor y su subclase estándar. |
| Cov_short.mnx Cov_short.mnt |
Menú contextual. |
| Cov_pjx.frx Cov_pjx.frt |
Mecanismo predeterminado para obtener resultados del proyecto. |
| Coverage.h | Archivo de encabezado para todo el código de trayecto, que incorpora los elementos siguientes:
*— Constantes de caracteres de trayecto para registro y análisis: *— Cadenas de trayecto localizadas (puede utilizar algunas constantes de registro y análisis): *— Constantes de componentes de cuadros de diálogo comunes del trayecto: *— Especificaciones y requisitos del trayecto: *— Constantes de objetos del registro de trayecto: *— Opciones de ajuste de trayecto: |
El conjunto de archivos de origen del proyecto COVERAGE también incluye otros archivos .ico .bmp y .msk.
Puede utilizar el archivo COV_TUNE.H (que contiene los comentarios y explicaciones correspondientes) para familiarizarse con las opciones disponibles sin tener que rescribir el código.
Como el uso de complementos está controlado por la superclase del motor de trayecto, cualquier otra subclase de trayecto que cree podrá utilizar complementos de la misma forma en que lo hace la subclase estándar.
La subclase del motor de trayecto cuya instancia ha creado la aplicación predeterminada Coverage.app no aumenta el método RunAddIn( ) del motor de trayecto de ningún modo. No obstante, invoca un cuadro de diálogo modal para que el usuario pueda seleccionar un complemento antes de invocar al método RunAddIn( ) del motor de trayecto. El cuadro de diálogo modal recibe una referencia al objeto Coverage y establece la propiedad cAddIn del motor de trayecto.
Si escribe su propia subclase del motor de trayecto, asegúrese de que la subclase pueda utilizar la misma clase de cuadro de diálogo modal (cov_AddInDialog) para tratar los complementos como lo hace la aplicación de trayecto estándar. El cuadro de diálogo no se basa en ninguna característica de la subclase estándar.
Puede llamar a un cuadro de diálogo modal distinto, establecer el nombre de archivo cAddin directamente en la propiedad cAddIn o anular el contenido de esta propiedad al pasar el nombre del archivo de complemento que desea ejecutar al método RunAddIn( ).
Independientemente del modo en que logre el acceso a un complemento para ejecutarlo en una subclase, puede observar la lista de complementos registrados en Coverage.app si busca los nombres de los archivos en la propiedad aAddIns del motor de trayecto.
Si desea información acerca de las propiedades, eventos y métodos del motor de trayecto, vea Objeto Coverage Engine en la Ayuda.
Vea también
Modificar el Analizador de trayecto | Enlaces del Administrador de proyectos | Desarrollo de aplicaciones y productividad de los programadores | Jerarquía de objetos de un proyecto | Aplicación Analizador de trayecto