Problema con el alcance de la aplicación

Artículo original: Application scope gotcha
http://www.foxpert.com/knowlbits_200707_4.htm
Autor: Christof Wollenhaupt
Traducido por: Ana María Bisbé York

---

Visual FoxPro nos brinda flexibilidad para incrustar archivos en archivos APP / EXE. Otros lenguajes tienen esta capacidad; pero requieren que el desarrollador utilice funciones de recursos para acceder a estos archivos. En Visual FoxPro, por otra parte, el acceso a archivos incrustados ocurre completamente transparente. Cuando usted abre un archivo que tiene el mismo nombre que uno incrustado, Visual FoxPro utiliza el interno.

Solamente con una aplicación difícilmente pensará sobre este mecanismo. Sin embargo, con múltiples aplicaciones, el concepto de aplicación se torna cada vez más importante. Como Visual FoxPro ejecuta el código, está al tanto de qué código pertenece a qué aplicación. El código puede solamente acceder a archivos que estén incrustados en esa aplicación.

Por ejemplo, puede incluir un archivo DBF en una aplicación. Esta aplicación puede abrir el DBF sin ningún problema. Sin embargo, una segunda aplicación podría intentar abrir la misma tabla utilizando código como este:

USE DBF("alias") AGAIN IN 0

Esta línea de código podría fallar de repente, porque la segunda aplicación no tiene acceso al archivo DBF incrustado. ¿Por qué estoy hablando sobre esto? Por que Visual FoxPro 9 introdujo problemas en cuanto alcance de la aplicación, a aplicaciones que no antes no tenían problemas. Estoy hablando del nuevo motor de informe, que confía en tres aplicaciones externas para realizar su tarea.

En las versiones anteriores a la 9, frecuentemente incrustábamos los archivos FOXUSER para controlar la barra de herramientas de Presentación preliminar, por ejemplo, quitar el botón imprimir de esta barra de herramientas. La rutina de impresión primero cambiaba el archivo de recursos, imprimía el informe y restauraba el archivo de recursos. Si usted no cambia este código y pone solamente REPORT FORM ... PREVIEW, puede recibir un error en el método OpenResourceFile. El código que da problemas es aparentemente inocente:

select 0
use (set("RESOURCE",1)) again shared
set order to 1

Cuando VFP carga un archivo FOXUSER, siempre crea un índice temporal. El código funciona bien si se va a ejecutar en el mismo ámbito que su aplicación. Esto es parte de REPORTPREVIEW.APP. Lo que ocurre es lo siguiente:

Su aplicación carga el recurso incrustado y VFP crea un índice temporal. La aplicación ReportPreview intenta guardar y restaurar la posición de la ventana preliminar. La instrucción USE debe abrir el archivo de recursos actual. Una vez que el código preliminar se ejecute en un ámbito de aplicación diferente a su aplicación inicial, Visual FoxPro busca un archivo externo con el mismo nombre. Ahora pueden ocurrir dos cosas:

Si no existe un archivo externo con este nombre, Visual FoxPro lanza un mensaje de error, porque el archivo no ha podido ser encontrado. Si el archivo existe externamente, Visual FoxPro lo abre. Para Visual FoxPro, este archivo ahora es diferente al que abrió antes como archivo de recursos.

Visual FoxPro siempre abre las tablas una sola vez. Cuando usted abre una tabla en múltiples áreas o sesiones de datos, todas estas instancias se refieren en realidad a la entrada actual de la tabla. Esta es la razón, por la que hace falta USE AGAIN cuando abre una tabla en más de un área. La entrada de la tabla mantiene un registro de los archivos índices abiertos. Esta es la razón por la cual, al abrir nuevamente una tabla, hereda todos los archivos abiertos.

Cuando usted abre el archivo de recursos nuevamente, utilizando el código como el que fue mostrado antes, Visual FoxPro reutiliza la entrada existente de la tabla con el índice que VFP creó internamente. En nuestro escenario de un archivo de recursos incrustado, sin embargo, la sentencia USE crea una nueva tabla que no tiene un índice asociado. Consecuentemente la línea SET ORDER TO provoca un error. Este problema en particular se puede evitar desconectando el archivo de recursos mientras se accede al formulario de presentación preliminar.

Sin embargo, no se trata solamente de un error en la aplicación ReportPreview. Se trata de un error que puede ser aun más y más importante si incorporamos características a nuestra aplicación que se extiende a través de múltiples archivos APP. Los problemas de alcance de la aplicación vienen de muchas formas, incluyendo la restauración de parámetros como SET CLASSLIB, SET PROCEDURE, y así con todos los que pueden referirse a archivos incrustados.