teclear escape por codigo

[edgar suarez kummers]

Buenas Foreros y Foxeros:

Debo teclear ESCAPE por codigo, pero:

Ni siquiera haciendolo tres veces con el código bajo estas líneas funciona en la aplicación compilada.

Voy a cambiar las líneas de lugar dentro del PRG a ver si va mejor.

FOR alfa = 1 TO 3

KEYBOARD "{ESC}" clear

WAIT WINDOW "saliendo" TIMEOUT 1

endfor

Si alguien del grupo sabe como lograrlo se lo abonaré desde EL CIELO

Edgar Suárez Kummers

[César Pistiner]

Hola Edgar

Creo que había un seteo para eso, tal vez lo tengas apagado.

Set escape on/off

Fíjate la ayuda pero creo que era así.

Saludos,
César

[edgar suarez kummers]

Gracias César por la respuesta.

Ocurre que he estado todo el día por la calle y ahora que acabo de llegar me he encontrado tu respuesta.

Te agradezco de corazón tu buena voluntad.

Saludos

Edgar Suárez Kummers

[César Pistiner]

No hay porqué estimado!

Pero... Era ese el problema?

Saludos,
César

[HernanCano]

Edgar:

¿Qués es lo que sí pasa o qué es lo que no pasa con el código que expones?

 

[edgar suarez kummers]

Estimado César, todavía no logro el efecto deseado.

Estimado Hernán, hay que manejar mejor la instrucción KEYBOARD, sigo en ello.

Saludos

Edgar Suárez Kummers

[Fernando D. Bozzo]

Hola Edgar:

Más que tratar de arreglar una "implementación", sería útil que cuentes qué querés funcionalmente y dejar abierta la posibilidad de que pueda hacerse de otra forma.

¿Podés detallar lo que querés hacer con el programa en general y porqué en ese FOR querés eso?


Saludos!

[edgar suarez kummers]

Estimado Fernando:

La función KEYBOARD funciona pero no ejecuta.

A ver te explico:

Para salirse de un FORM programático que opera una cámara virtual del browser o una cámara real del computador se debe teclear ESC (escape)

dentro de los FORMS de las cámaras tengo 

KEYBOARD space(1) clear && para limpiar el buffer y colocar la barra espaciadora

Hasta ahí todo bien

Cuando el software está en DEMO pasadas dos horas debe salirse, entonces debe operar la tecla ESC escape programáticamente.

KEYBOARD '{ESC}' clear && seguro coloca ESC en el buffer

Pero no la ejecuta, ........... , olvido de M$

Dentro de algo menos de dos horas (para no molestar el código del Timer) sabré si 

Parte del código tomado del Link abajo de estas líneas sí ejecuta keystroke adecuado:

Luego si se ejecuta bien ese código el software presenta 3 tablas con información pequeña al usuario.

http://www.foxite.com/archives/send-keystrokes-to-external-app-from-vfp-0000229059.htm

Son tres días poniendo y quitando líneas y probando:

Al final debe desaparecer tras dos horas el fotograma de la cámara y seguir con las tablas:

​

En este momento el software podría estar detectando una paloma en vuelo a unos 50 metros de distancia si es de día o los ojos de un gato brillando en la oscuridad si es de noche y estos dos ejemplos son parte de los eventos que puede rastrear si se le ha enseñado al programa con el AUTOTUNES.

Al cumplirse las dos horas y por estar en DEMO debe desaparecer el FORM de la cámara y seguirse con la información de 3 tablas NOUPDATE.

Te repito que KEYBOARD '{ESC}' clear && no ejecuta el ESC aunque sí lo coloca en el buffer

saludos estimado Fernando y agradecerte una vez más a tí e igual a Fidel, porque en alguna parte del software tengo incorporadas sus maravillosas ideas.

Es un trabajo que entre líneas me ha tomado unos 7 años (soy más demorado que 'polvo de chancho') según mi adorable esposa, refiriendose obviamente a mi trabajo en el computador, ella es campesina y conoce bien a los cerdos porque en sus fincas los criaban.

Saludos

Edgar Suárez Kummers

[Fernando D. Bozzo]

Hola Edgar:

Como te decía, siempre hay más de una forma de hacer las cosas, y en este caso creo que te convendría usar instrucciones normales y no el buffer de teclado.
En otras palabras, ¿por qué usás un bucle para meter instrucciones en el buffer de teclado para salir del programa, cuando con un CLEAR EVENTS y un RETURN por ahi podés hacer lo mismo?

Ojo, tené en cuenta que lo que te digo es basado en la poca información que hay, ya que mencionaste un timer, pero no tengo idea de cómo tenés la implementación de la carga del programa, o sea: ProgramaPrincipal => Form => TimerEnElForm o como lo tengas. Dependiendo de esto, hay varias alternativas, pero te repito, es muy difícil dar soluciones cuando los datos son tan pocos.

Si pudieras armar un ejemplo mínimo y funcional con tu programa principal (si hay uno), un form y el timer, para que sea pueda ver cómo interactúan entre ellos en este modo demo que comentás, seguramente podamos ir mucho más rápido con la solución. Sé que preparar un ejemplo funcional a veces no es tan fácil, dependiendo de cómo lo hayas hecho, pero es mucho más fácil para todos el poder trabajar sobre un ejemplo en el que podamos decirte en el mismo código "mirá, podés hacer esto o lo otro" y vos lo puedas ver, que estar tirando ideas basadas en poca información.

Acordate que muchas veces uno se encasilla con una solución y brinda los datos enfocados a esa única solución, lo que impide poder dar otras soluciones, lo que en este foro es un error muy común.


Saludos.-

[edgar suarez kummers]

Estimado Fernando:

Voy a hacer la prueba que dices con el CLEAR EVENTS y el RETURN.

A ver te comento lo siguiente:

Para terminar el programa hay fácilmente más de 30 llamados a un prg que hace eso, terminar, depende de varios factores, llamado manual a terminar, llamado por timer, llamados porque encuentra que alguno de los archivos encriptados ha sido modificado, porque detecta un error etc ...

En todos los casos debe reportar el número de línea y el prg o form del cual salió.

El programa es uno solo, entra en DEMO si la encriptación y la seguridad de la encriptación no corresponde a la del disco duro donde está instalado. 

En ambos casos es totalmente funcional, pero en el caso DEMO puede operar hasta por periodos de dos horas treinta veces.

Aquí puede pasar que lo bajen de internet, lo instalen, lo prueben y pasadas las dos horas se quede la toma de la cámara estática, pero visible y no deseo que desde un principio se piense (como es la verdad) que estoy lejos de ser un buen programador.

En el caso de no estar en DEMO primero deben ESC escapar de la cámara para acceder a salir del programa. Allí no hay problema.

Las tres últimas tablas que saca en secuencia son información muy útil, que me la pueden reportar como es en qué numero de línea salió y de donde PRG o FORM, eso se debe dar en todos los casos.

Igualmente indica si sale porque le han cambiado de nombre al programa o entre la carpeta existe algún otro ejecutable, en ese caso sale también y termina.

Tiene control de doble ejecución para impedir que eso suceda.

Voy a insistir en sacarlo programáticamente, porque como te digo el programa es uno solo que entra 

en DEMO bajo ciertas condiciones.

Saludos y de nuevo muchísimas gracias por tu apoyo y sabiduría que ompartes.

Edgar Suárez Kummers

[Staff de Desarrollos EfiMax]

          Edgar para el caso que describes un timer programado para que se desencadene en dos horas no tiene impacto en el desenvolvimiento del performance de tu sistema, una vez alcanzado el tiempo meta se desencadena el timer y cierra el formulario.

 

          Suerte

 

 

 

____________________________________

Carlos Omar Figueroa López

Ingeniero Industrial y de Sistemas

http://www.efimax.com.mx

[Hernan Serrano]

Y si en la instrucción del Timer se coloca un ThisForm.Release.

Y en el Release las instrucciones con las tablas.,..

No se es una idea....

--

Tico Support S. A.
Tel. (506)8772-6170

[edgar suarez kummers]

Gracias estimados Hernán y Carlos Omar por sus sabios consejos.

Definitívamente KEYBOARD ('{ESC}' se guarda en el buffer, pero no se ejecuta en la forma que se espera para cerrar el FORM.

Cuando se cumplen las dos horas no hay garantía de que el FORM de la cámara esté activo.

Si se teclea ESC todo funciona bien y SET ESCAPE OFF es el seteado, porque SET ESCAPE ON si que agrava la cosa porque suspende todo el programa.

Voy a añadir un FORM explicando que cuando aparezcan las tablas en BROWSE y no sirva tratar de cerrarlos es porque detrás hay un FORM que hay que cerrar tecleando ESC hasta 3 veces sucesivas donde se cierran primero las tablas en BROWSE y luego el formulario de la cámara.

Y este formulario explicativo motrarlo junto con la foto del suceso dentro de él y en el momento en que pretendan abrir las dos opciones de las cámaras o el AUTOTUNES.

Gracias por sus grandes aportes en ideas, pero esto era algo más propio del lenguaje de programación. Inclusive lo traté de hacer con código extractado de: 

http://www.foxite.com/archives/send-keystrokes-to-external-app-from-vfp-0000229059.htm

Y tampoco funcionó

Saludos y gracias

Edgar Suárez Kummers

[Fernando D. Bozzo]

Edgar, hay algo que no me queda claro:

Cuando se ejecuta el timer, ¿se tiene que cerrar solo el form o todo el programa? Porque si debe cerrar todo el programa te serviría un CLEAR EVENTS y un QUIT a secas.

Saludos.-

[edgar suarez kummers]

Sabes que tienes razón, en este caso pudiera prescindir de la información que dan las tablas respecto del errores, tiempo transcurrido, existencia de otros exe dentro de la carpeta y haber renombrado el exe porque la duplicidad de ejecuciones está contemplada en las siguientes llamadas a ejecuciones.

No en vano eres de los grandes gurús del grupo.

Nos queda de experiencia que KEYBOARD() almacena en buffer, pero no ejecuta.

Saludos de nuevo agradecido. Ya te debo varias de mucha inteligencia de tu parte.

Edgar Suárez Kummers

[Fernando D. Bozzo]

Respecto de KEYBOARD, te cuento algo que normalmente se desconoce: Sí ejecuta, pero hay que forzarlo a que lo haga, y me explico:

Cuando ejecutás KEYBOARD <caracteres> es como si pulsaras esas teclas, pero Fox no las procesa hasta que se encuentra en un estado IDLE, o sea, en espera de datos, como cuando cargás un form de ingreso de datos con READ EVENTS. Lo que sucede en este caso es que luego de que se ejecute la última instrucción de programa del último evento ejecutado que se haya programado (load, init, activate, etc), es ahí cuando Fox manda el foco el control de entrada de datos que le hayas puesto y comienza a leer el bufer de teclado y a volcarlo, por ejemplo, en un textbox.

Cuando se meten secuencias de teclas en el buffer simulando el ingreso manual, hay que hacer "algo" para forzar ese estado IDLE aunque sea un momento, suficiente para que se pueda leer el buffer de teclado, y ese estado IDLE se fuera con DOEVENTS.

El único caso que por ahora se me dió donde necesito enviar teclas al buffer de teclado porque es algo que no se puede hacer por programa, es la compilación automatizada de FoxPro cuando hay algún problema (como un error de sintaxis en un programa que se compila, un archivo no encontrado pero referenciado en el código, etc) y que suele mostrar un molesto cuadro de diálogo con "Locate, Ignore, Ignore all, Cancel" que rompe toda automatización. Este es uno de esos casos donde se puede enviar anticipadamente una secuencia de teclas para "ignorar todo" (tecla a) así continúa el proceso.

Creo que con un ejemplo lo podés entender mejor como funciona lo del buffer de teclado en Fox, paso a paso:

1) Creamos un programa de prueba llamado "test.prg":

MODIFY COMMAND test.prg

2) Como código, le ponemos dentro esta línea que llama a un programa inexistente (para generar un error a propósito) y lo guardamos (CTRL+W):

DO PEPE.PRG

3) Ahora creamos un proyecto y un ejecutable desde la ventana de comandos:

BUILD PROJECT test FROM test.prg
BUILD APP test FROM test.pjx RECOMPILE

Sale este cuadro de diálogo donde hay que elegir "Ignore all" (tecla "a"):

​

Y ahí termina la compilación manual.

Ahora imaginate que este proceso de compilación lo querés automatizar, y supongamos también que este proceso se va a realizar en un servidor remoto al que normalmente no estás conectado, por lo que no ves su pantalla ni lo que pase (por ejemplo, automatización de ejecutables con CruiseControl o Jenkins): Obviamente no podés estar pendiente de que salga un cuadro de diálogo, porque te obligaría a estar conectado a ese servidor para ver lo que ocurre, y menuda automatización sería si tenés que estar pendiente de una pantalla. En este caso podemos usar KEAYBOARD para simular la pulsación de esa tecla y asegurarnos de que no nos preguntará nada, simplemente lo hará.

En este caso, lo haríamos así:

KEYBOARD "A" PLAIN CLEAR
BUILD APP test FROM test.pjx RECOMPILE
CLEAR TYPEAHEAD

- El KEYBOARD deja la letra "A" en el buffer de teclado

- El BUILD APP genera el proyecto "test.app", pero esto generará un error que debe saltearse. Cuando se muestre ese mensaje el sistema queda automáticamente en estado IDLE (en espera de una entrada del usuario) y es en este momento cuando FoxPro lee el buffer de teclado que ya dejamos cargado antes

- Finalmente, se ejecuta CLEAR TYPEAHEAD para limpiar el buffer de teclado, por si quedara algo en el mismo (por ejemplo, si no ocurriera ningún error, la "A" se queda en el buffer)

En tu caso pusiste un FOR como este:

FOR alfa = 1 TO 3
   KEYBOARD "{ESC}" clear
   WAIT WINDOW "saliendo" TIMEOUT 1

ENDFOR

Pero, ¿qué pasa realmente en ese FOR?

Veamos: Con SET ESCAPE ON

- Se ejecuta el primer KEYBOARD

- El WAIT WINDOW captura la tecla ESC, y somo SET ESCAPE es ON sale el cuadro de diálogo de "Cancel, Suspend, Ignore" y el sistema queda en estado de espera hasta que elijas una opción
- Si ignoramos (tecla "I") vuelve a salir este mensaje 2 veces más, pero el WAIT WINDOW no se ve.


​

Ahora veamos con SET ESCAPE OFF

- Se ejecuta el primer KEYBOARD

- El wait window captura la tecla ESC, pero como SET ESCAPE es OFF solo cierra el mensaje y sigue
- El WAIT WINDOW no se ve

Como ves, ese código con SET ESCAPE OFF no hace nada, ya que la tecla ESC que ponés en el buffer la lees inmediatamente con el WAIT WINDOW

Solución alternativa: Usar ON ESCAPE <comando> y dejar SET ESCAPE ON

Por ejemplo:

ON ESCAPE DO SALIR

SET ESCAPE ON

KEYBOARD "{ESC}" CLEAR

RETURN

PROCEDURE SALIR

   ON ESCAPE

   CLEAR EVENTS

   QUIT

ENDPROC

Realmente este programa solo te sirve para ver como funciona lo de poner ESC en el buffer de teclado y leerlo con el ON ESCAPE para salir, pero en la realidad ese ESC es el que presionaría el usuario en una pantalla cualquiera para salir del sistema, ya que la rutina de SALIR se encarga de cerrarlo.

Los estados de espera (IDLE) del sistema se producen en estos casos:

- Cuando se muestra un messagebox con una opción para seleccionar

- Cuando se muestra un form de ingreso de datos con textbox u otro campo

- Cuando ocurre un error no controlado (y por tanto muestra un messagebox con el error y alguna opción para elegir)

- Cuando se ejecuta DOEVENTS

- Cuando se ejecuta WAIT WINDOW sin NOWAIT

- Cuando se usa INKEY(valor_N)

- (habrá otro, pero no lo recuerdo ahora)

En todo caso, si no se fuerza un estado IDLE de espera, siempre se ejecutará primero el código de programa hasta la última instrucción ejecutable, y luego se leerá el buffer del teclado.

Espero que esto aclare un poco cómo funciona la lectura del buffer de teclado en Fox.

Saludos.-

[edgar suarez kummers]

Estimado Fernando:

Muy bien explicado, además muy claro y conciso.

Si urgas dentro de FACEBOOK y tecleas JORGE VICENTE SUÁREZ, es un informático de Avilés, Asturias, que ha trabajado en Dublin y en Londres para MICROSOFT y HEWLETT PACKARD, su esposa es Uruguaya y es hijo de mi prima JOSEFINA, cuyo padre (MI TIO) hizo bastante dinero en la Argentina con una flotilla de transporte terrestre. 

El único que quedó en América de los hermanos fue mi padre.

Como quiera que sea, te estoy muy agradecido por tu esfuerzo y entrega ayudando a otros dentro del foro con esa inteligencia y generosidad que te ha caracterizado. 

Saludos y felicitaciones.

Edgar Suárez Kummers

[Jean Pierre Adonis De La Cruz Garcia]

Asi me dijo mi padre se parece al unico hijo de mi padre, que es sobrino de mi tio, nieto, del hijo de mi padre, hijo de la esposa de mi padre, que no es mi hermano.

Al final no me recordaba de quien era.

pero busque en la agenda del feobuk y me di cuenta de quien era.