Problema al ejecutar codigo con EXECSCRIPT

[Gabriel Barreto]

Estimados, tengo una consulta para verificar un comportamiento de VFP, por si a alguien le ha pasado y si se puede resolver.

Me explico: Tengo una aplicacion, bastante grande, que funciona como front-end de una gran base de datos MS-SQL Server.

En ella entre varias cosas, se generan y muestran varios gráficos estadísticos utilizando las excelentes clases de dominio público Foxcharts.vcx con Gdiplusx.vcx.

En mi sistema, he generado sub-clases de Foxcharts.vcx para mostrar gráficas tipo medidores, gauges, etc con excelente resultado visual.

Todas las clases estan "incluidas" al compilar el ejecutable, por lo que quedan empaquetadas en el archivo .EXE

El problema surgio recientemente, al agregar una nueva funcionalidad de que el sistema tuviera un inicio personalizado para cada grupo de usuarios, requerian que se mostraran unos graficos de resumen tipo panel "Dashboard", es decir aprovechar el fondo de pantalla (_screen) que normalmente esta en blanco.

Como este incio seria personalizado y ademas lo irian variando con bastante frecuencia, la solucion fue colocar el PRG en un campo TEXT de una tabla en el servidor SQL, de ese modo la aplicacion apenas arranca, genera el entorno, carga menus, etc. y descarga en un campo memo local el PRG adecuado, y lo ejecuta con EXECSCRIPT(CampoMemo) 

Hasta aca todo bien, modificando el contenido en el servidor SQL podia crear el arranque personalizado y actualizarlo sin tener que cambiar el .EXE del sistema a cada usuario.

El problema surge cuando con este PRG "remoto" por asi decirlo, tratamos de crear objetos gráficos de las clases que están incluidas en el EXE: NO las encuentra!

Después de varias pruebas, la única solución que funcionó fue copiar las bibliotecas .VCX en la carpeta de la aplicación de cada usuario... a pesar de que están incluidas en el EXE.

Pareciera que el PRG ejecutado con EXECSCRIPT(CampoMemo) tuviera su propio entorno, como si fuera un proceso separado del EXE que lo llamó... Le pasó a alguien? Tiene solución, para no tener que copiar los .VCX aparte?

Gracias desde ya y disculpen lo largo de la explicación, sino no se entiende

[Irwin Rodriguez]

Tuve ese problema cuando desarrollé el EasyRibbonBuilder

Intenta lo siguiente:

SOLUCION 1

Coloca ésto en tu PRG remoto:

IF !"MICLASE" $ SET("CLASSLIB")

   SET CLASSLIB TO ("MICLASE")  IN ("MI_EXE.EXE") ADDITIVE

ELSE && !"MICLASE" $ SET("CLASSLIB")

ENDIF && !"MICLASE" $ SET("CLASSLIB")

Donde MICLASE es el ALIAS con el cual la declarastes en tu EXE

SOLUCION 2

Deja que tu EXE cree los objetos que necesites a traves de una función la cual te retornará la referencia a objeto creado.

Ejemplo:

*-- Función dentro del EXE:

*--

FUNCTION CREAR_OBJETO_DENTRO_DEL_EXE

   LPARAMETERS toParentObject, tcObjectName, tcClassLibrary

   LOCAL loObject

   loObject= .NULL.

   TRY

      toParentObject.AddObject( tcObjectName , tcClassLibrary )

      loObject = toParentObjec.tcObjectName

   CATCH TO oErr

      MESSAGEBOX( oErr.Message,16 )  

   ENDTRY

   RETURN loObject

ENDFUNC

*--

Y asi la debes llamar:

LOCAL loObj1

loObj1 = CREAR_OBJETO_DENTRO_DEL_EXE(_SCREEN.ActiveForm, "myObjectName", "myClassLibrary")

? loObj1.Name

Nada de ésto está probado, solo es para darte una idea en base a la experiencia que he tenido.

Espero te sirva.

Saludos...!

--

Irwin Rodríguez

Analista Programador

+593 0994903424
Latacunga - Ecuador

"Un equipo solo son piezas que intercambias hasta que terminas el trabajo, es eficiente, funciona."

[Fidel Charny]

Deberías estudiar la posiblidad de pasar las referencias de objeto de las clases que necesitas.

Este es un ejemplo muy sencillo (no tiene mayor sentido, pero funciona)

loCust = NEWOBJECT("cust_verisys","verisys_new.vcx")
lcExe = "LPARAMETERS toCust";
    + CHR(13);
    + "toCust.Veriprev(.f.,.t.,.f.,.t.)";
    + CHR(13)
   
EXECSCRIPT(m.lcexe,loCust)
loCust = null

[Gabriel Barreto]

Muchas gracias Irwin y Fidel por responder, les comento la solución simple y que funcionó perfecto es la nro 1 de Irwin,... indicar que las librerías están dentro del .EXE!!

La verdad, por no leer la ayuda después de muchos años con VFP, siempre las declaraba como estando en archivos .VCX, nunca las habia usado de esa manera (esto comprueba que nunca se termina de aprender..)

Las otras dos soluciones, aunque es interesante el planteamiento, generaría un "acoplamiento" que no deseo entre la aplicación principal y el PRG personalizado de arranque, ya que no en todos los casos necesitaran esas librerías, y pueden usar otras, el poder definir las que ya están en el EXE es mejor en mi caso y mas limpio.

Gracias a todos por el tiempo, un abrazo!

Gabriel