Capítulo 8 Introducción al lenguaje OpenScript

Transcripción

1 Capítulo 8 Introducción al lenguaje OpenScript 8.1 Eventos, mensaje y manipuladores Como hemos visto en los capítulos anteriores existen diversas formas de añadir comportamiento a una aplicación ToolBook que no exigen el dominio de un lenguaje de programación (Uso de Widgets, Propiedad Hyperlink, Editor de acciones). Sin embargo para obtener una capacidad máxima de desarrollo de aplicaciones con ToolBook es necesario el empleo del lenguaje de programación OpenScript que se encuentra integrado al sistema. OpenScript es un lenguaje de programación categorizado como "Full Featured" (Completo). Al igual que los lenguajes de propósito general permite el manejo de variables locales, globales; simples y estructuradas; posee estructuras de control para el tratamiento de condicionales, iteraciones, etc. Contiene una amplia gama de funciones y procedimientos predefinidos permitio además la implementación de estructuras de este tipo definidas por el programador. Como Windows, ToolBook es un sistema guiado por eventos con naturaleza orientada a objetos. En tal sentido el lenguaje OpenScript además de permitir la creación y manipulación de los objetos del sistema es extensible mediante el uso de DLLs, controles del tipo ActiveX (VBX, OCX) así como el protocolo DDE (Dynamic Data Exchange) que permite a ToolBook interactuar directamente con datos generados en otras aplicaciones Windows. Tenio en cuenta su naturaleza Event-Driven (guiado por eventos) la interactividad con el sistema está basada en la reacción de los objetos ante eventos que puedan o no ocurrir. Estos eventos pueden ser generados por el usuario o por el propio sistema. En este sentido es importante comprer la significación de 3 importantes conceptos: evento (event), mensaje (message) y manipulador (handler). Event (evento): Un evento es una acción que ocurre y que es reconocible por el sistema. Eventos pueden ser, entre otros, el pulsar de uno de los botones del ratón, oprimir una tecla, la ejecución de un procedimiento del lenguaje, la asignación de una propiedad a un objeto, etcétera. Observación: 1. Como se observa un evento es una acción que puede ser generada por el usuario o también por el sistema. 2. La programación guiada por eventos tiene como esencia el concebir respuestas a los eventos que se deseen controlar. 146

2 Message (Mensaje): Un mensaje es una comunicación que envía el sistema a un objeto para indicar que un evento a ocurrido. Así por ejemplo, si un usuario oprime el botón izquierdo del ratón, el sistema genera el mensaje denominado ButtonClick para indicar que tal acción ha tenido efecto y de esta forma solicitar una respuesta consecuente, por parte de los objetos de la aplicación. Observación: 1. El concepto de mensaje en OpenScript está fuertemente ligado a la jerarquía de objetos discutida en el capítulo En OpenScript los denominados procedimientos o subrutinas de la programación estructurada serán tratados como manipuladores de mensajes que se envían entre objetos. Manipulador (Handler): Un handler o manipulador es una colección de código OpenScript, capaz de definir una respuesta a un evento particular. Observaciones: 1. En ToolBook el manipulador de un mensaje, está asociado a la propiedad Script del objeto receptor del mensaje. 2. La propiedad script de un objeto puede contener múltiples handlers (manipuladores), previo de esta forma diferentes respuestas para los diferentes eventos que puedan ocurrir. Así por ejemplo mientras un manipulador controla la posibilidad de que el usuario pulse con el botón izquierdo del ratón sobre un objeto (mensaje ButtonClick) y de esta forma prever una respuesta para este evento, otro manipulador en el propio Script puede prever una respuesta para la acción de pulsar con el botón derecho del ratón (mensaje RightbuttonUp) e inclusive prever una respuesta para el caso en que no exista ninguna acción por parte del usuario (mensaje idle). (Véase mensajes del sistema más adelante en este mismo capítulo). Ejemplo: Supongamos que se a diseñado un botón sobre una página ToolBook y se desea que al pulsar con el botón izquierdo del ratón, se visualice una ventana que muestre la tradución al español de la palabra inglesa «Welcome», de igual manera se desea que si en lugar de pulsar con el botón izquierdo del ratón el usuario pulsa con el botón derecho, entonces lo que se desea visualizar es la tradución al francés de la misma palabra y por último deseamos que si el usuario 147

3 realiza un dobleclic se escuche la pronunciación de esta palabra en inglés británico. La solución en OpenScript de este ejemplo sería: -- Código que se coloca en la propiedad Script de un objeto button (botón) To handle ButtonClick Request "Bienvenido" End To handle RightButtonUp Request "Bienvenue" End To handle ButtonDoubleClick Get PlaySound("c:\MiApp\medias\welcome.wav") End Observación : 1. Cada colección de código enmarcada entre las palabras reservadas del lenguaje to handle y, es lo que se denomina handler o manipulador. En este caso decimos que el objeto contiene 3 handlers. 2. El orden de escritura de los handlers de un objeto es intrascente, o sea lo mismo se puede escribir primero el manipulador que controla el evento relacionado con el botón izquierdo que el que trata el botón derecho, etcétera. Como se observa la programación guiada por eventos tiene características particulares, sin embargo muchos de los conceptos de la programación estructurada seguirán vigentes. La siguiente figura muestra un análisis comparativo breve del OpenScript con otros lenguajes de programación. 148

4 8.2 Herramientas de programación para OpenScript El proceso de programación en OpenScript está relacionado con las siguientes herramientas: - Editor de script El editor de script funciona de manera similar a un procesador de texto convencional, mediante este editor el programador introduce el código del lenguaje. Como todo editor de texto, posee las funciones básicas de Copiar (Copy), Pegar (Paste), Buscar (Find), Reemplazar (Replace), etc. Adicionalmente el editor de script posee una función que permite realizar chequeos sintácticos sobre el código introducido. A partir del menú File del editor también podemos acceder a servicios de exportación de código en formato texto (.txt), así como a la ventana del " Debugger " que se muestra más adelante. Figura 8.1 Ventana de comandos (Command Window). La ventana de comandos es una herramienta que permite enviar mensajes de manera directa al sistema, asignar propiedades, probar segmentos de código, en fin ensayar un procedimiento y probarlo de manera inmediata. Figura 8.2 Ventana de Debug (Debugger Window). Como es usual en la mayoría de los lenguajes de programación el Debugger se usa para corregir errores en el código. Para llevar el control del proceso es posible asignar y eliminar Break Points (puntos de ruptura) en los que se detrá la corrida del programa permitio visualizar valores de variables y rastreo de subrutinas (procedimientos, funciones). 149

5 Figura 8.3 Ampliación: Una información detallada acerca del manejo de las herramientas de programación de Openscript lo puede encontrar en el capitulo 4 del fichero tb70os.pdf, que se encuentra en la carpeta Manuals del disco de instalación. 8.3 Algo más acerca de eventos y mensajes. Jerarquía de objetos ToolBook ToolBook maneja dos tipos de mensajes, los denominados Build-in (predefinidos) como es el caso de ButtonClick, EnterPage, MouseEnter, etc. y los user-defined (mensajes construidos por el programador). Al ejecutarse un evento vinculado con uno de los mensajes buil-in (predefinidos) de ToolBook, automáticamente se envía este mensaje y el mismo va atravesando por diferentes niveles, que se organizan de acuerdo a la ya mencionada Object hierarchy (jerarquía de objetos). Cómo debe interpretarse este esquema en el contexto evento-mensajemanipulador? Recordemos que un botón que se encuentra sobre una página, es hijo de esta, la página es a su vez es hija del background que la soporta y este último es hijo del libro que los contiene a todos. 150

6 Figura 8.4 Para dar respuesta a esta pregunta analicemos el siguiente ejemplo: Un usuario pulsa con el botón izquierdo del ratón sobre un objeto que ha sido colocado sobre una página. Obviamente, esta página esta contenida en un determinado backgound que a su vez esta contenido en un objeto Book (libro). Buscando respuesta a nivel de objeto. Si se ha definido en la propiedad script del objeto un handler (manipulador) capaz de interpretar el mensaje buttonclick (consecuencia del evento oprimir el botón izquierdo del ratón), entonces al producirse el mensaje, el objeto reaccionará ejecutando la respuesta prevista por el programador a traves de las instrucciones definidas en el manipulador y el mensaje, una vez satisfecho, se dentrá. To handle ButtonClick -- aquí se escribe el código que genera la respuesta al evento que produce el mensaje. (Por ejemplo navegar hacia una página específica, ejecutar un vídeo, acceder a un record de una base de datos, etc.). End Buscando respuesta a nivel del objeto page (página). 151

7 Si por el contrario, el objeto no posee un handler (manipulador) consecuente, entonces el mensaje pasa al nivel jerárquico inmediato superior (en este caso el objeto page) en busca de un handler capaz de satisfacer su demanda. Si la página posee el manipulador necesario, entonces se producirá la respuesta prevista en este manipulador y el mensaje, una vez satisfecho, se dentrá. Buscando respuesta en niveles superiores. De no existir un handler (manipulador) consecuente, en el nivel actual, el mensaje continuamente pasará al nivel superior en busca de un manipulador capaz de ater su solicitud, si lo encuentra en algunos de los niveles subsecuentes (background, book, system book), será atido y el mensaje no pasará al nivel superior, de lo contrario será ignorado por el sistema. Como se ha visto, toda vez que el evento es atido por un manipulador de su tipo, el mensaje no continua a través de la jeraquía de objetos. En tal sentido parecería que sólo es posible determinar un único objeto, privilegiado, encargado de dar respuesta al mensaje emitido. Tal es la situación que nos presenta la jerarquía de objetos ToolBook, sin embargo, el empleo del comando forward puede lograr violar esta condición. Veamos algunos ejemplos: Variante 1 Si colocamos 2 manipuladores, uno en el botón que analizamos y otro en la página que lo contiene como se muestra abajo: -- manipulador colocado en la propiedad script del botón To handle ButtonClick Request "Estoy sio atido por el botón" Pause 3 seconds forward End -- manipulador colocado en la propiedad script del objeto page (página), parent (padre) del objeto button (botón). To handle ButtonClick Request "Estoy sio atido por la página" End Posterior a la escritura de estos manipuladores en los objetos respectivos (botón y página) se pasa al nivel lector (F3) y se pulsa el botón diseñado con el botón izquierdo del ratón. Veremos el primer mensaje y tres segundos más tarde el segundo mensaje. 152

8 Variante 2 Coloquemos los 2 manipuladores tal y como hicimos en el ejemplo anterior, solo que cambiemos la posición de la linea que contiene la sentencia forward de la siguiente manera: -- manipulador colocado en la propiedad script del botón To handle ButtonClick Forward Pause 3 seconds Request "Estoy sio atido por el botón" End -- manipulador colocado en la propiedad script del objeto page (página), parent (padre) del objeto button (botón). To handle ButtonClick Request "Estoy sio atido por la página" End Entonces veremos como primer mensaje, el referente a la página y como segundo mensaje tres segundos más tarde, el referente al botón. De esta forma habremos violado la jerarquía de objetos Toolbook. 8.4 Nivel idóneo para la definición de un manipulador (handler) A partir del análisis hecho en el epígrafe anterior se podrían establecer dos reglas extremas para colocar los manipuladores de mensajes. Una regla extrema (1) sería colocar manipuladores a todos y cada uno de los objetos involucrados en responder a cada uno de los eventos previstos, la otra regla extrema (2) podría ser, por ejemplo, colocar un único juego de manipuladores en el nivel más alto de la jerarquía de objetos (Book o system Book), pensando que de una manera u otra, de todas formas, todos los mensajes emitidos por el sistema llegarán a este nivel finalmente. La regla extrema 1 presenta el inconveniente de generar redundancia en el código, ya que para satisfacer la regla, ciertos comportamientos comunes a varios objetos serían repetidos una y otra vez. 153

9 La regla extrema 2 presenta el inconveniente de tener que escribir un código adicional para controlar que objetos deben reaccionar ante determinados mensajes y cuales no. Como siempre se ha dicho las posiciones extremas son malas, por lo que una regla idónea podría ser: Para comprer esta regla veamos un ejemplo: Saber hacer: El nivel idóneo dentro de la jerarquía de objetos ToolBook para escribir un handler (manipulador) deberá ser el nivel representado por el objeto de mayor jerarquía, de entre todos aquellos que necesiten recibir el mensaje. Supongamos que tenemos un Book (libro) de 20 páginas, donde las 10 primeras pertenecen al BackGround (fondo) A, las 5 siguientes pertenecen al BackGround B y las 5 últimas pertenecen al BackGround C. Cada una de estas páginas contienen objetos de tipo field (campos) contenedores de texto y en los textos se han definido objetos de tipo Hotword (Hiperpalabras o palabras calientes). Por ejemplo asumamos que en la página 1 existen 3 de estos fields (campos) con sus respectivas palabras calientes. Problema 1 Se desea que, estando en la página 1, al oprimir el botón izquierdo del ratón sobre una palabra caliente (en cualquiera de los tres campos existentes en esta página), la aplicación busque el significado de esta en un glosario confeccionado a tal efecto. Solución 1 (Altamente redundante) Una solución sería repetir el manipulador en la propiedad script de cada una de las N palabras calientes de todos los campos de de la página 1. Obviamente, esta solución implicaría la escritura del código N veces (una vez para cada objeto de tipo Hotword). To handle ButtonClick -- aquí se escribe el código que presenta la definición de la palabra interactuada. End 154

10 Observación: La expresión: if object of target is hotword, garantiza que la respuesta al mensaje buttonclick se realice sólo si el objeto interactuado resulta ser una palabra caliente. Solución 2 (Redundante) Otra solución sería repetir el manipulador en la propiedad script de cada uno de los 3 fields de la página 1, agregando una condicional para que el mensaje sea respondido si se interactúa sólo con una palabra caliente. Obviamente, esta solución implicaría la escritura del código 3 veces (una vez para cada campo). To handle ButtonClick If object of target is hotword then -- aquí se escribe el código que presenta la definición de la palabra End End interactuada. Observación: La expresión: if object of target is hotword, garantiza que la respuesta al mensaje buttonclick se realice sólo si el objeto interactuado resulta ser una palabra caliente. Qué sucedería si en lugar de 3 campos en la página resultan ser 10 ó 15? Según esta solución tríamos que repetir 10 ó 15 veces este código para cada uno de los fields (campos), esto, como se dijo antes, generaría una significativa redundancia en el código de la aplicación. Solución 3 (Efectiva) Una solución más eficiente sería colocar el manipulador en la propiedad script del objeto parent (padre) de los 3 campos involucrados, o sea en el script de la página. Según se analizó en el epigrafe anterior al no existir un manipulador en un determinado nivel, hace que el mensaje pase al nivel inmediato superior (en nuestro caso el objeto page (página), lográndose asi una atención al mensaje indepientemente de la palabra con la que se haya interactuado en esta página. 155

11 Problema 2 Se desea que este comportamiento sea efectivo no sólo para las palabras calientes contenidas en los campos de la página 1, sino también para todas las palabras calientes contenidas en todos los campos que se encuentren en las páginas que pertenecen al background A. Esta vez los objetos involucrados son los siguientes: Hotwords (Palabras calientes) pertenecientes a diversos fields (campos) que se encuentran en diferentes pages (páginas) de un mismo background (Fondo). Obviamente, el objeto de jerarquía superior entre los involucrados es el objeto Background A, que contiene a todas las páginas que a su vez contienen a todos los campos contenedores de todas las palabras calientes involucradas. Según la regla discutida, sería el background A, el objeto idóneo para contener el manipulador que garantiza la solución del problema planteado. Problema 3 Se desea que este comportamiento sea efectivo, no sólo para las palabras calientes contenidas en los campos de las páginas del background A, sino también para todas las palabras calientes contenidas en todos los campos que se encuentren en todas las páginas, que pertenezcan a todos los backgrounds A, B y C del libro. Esta vez los objetos involucrados son los siguientes: Hotwords (Palabras calientes) pertenecientes a diversos fields (campos) que se encuentran en diferentes pages (páginas) de todos los backgrounds (Fondos) de un determinado Book (libro). La aplicación de la regla discutida, obviamente nos llevará a la conclusión de que será el objeto Book (libro), el idóneo para contener el manipulador que garantiza la solución de este problema, por ser este objeto el de jerarquía superior de entre los objetos involucrados. Sería posible encontrar un nivel de jerarquía que permita hacer extensible la solución del problema planteado para todas las palabras calientes de una aplicación compuesta por un conjunto de varios books (libros)? La respuesta a este problema la encontaremos en el epígrafe 8.x System Books. Creación de bibliotecas nativas. 156

12 8.5 Una vista al recurso SharedScript o código compartido En el epígrafe anterior se plantearon 3 problemas hipotéticos en los cuales se discutió lo referente al lugar idóneo de escritura de un manipulador ante un problema determinado bajo ciertas circunstancias. Pensemos ahora que el problema se hace extensible más allá de las palabras calientes, o sea, que además se involucran objetos de tipo rectangle, polygon y ellipse (objetos de diverso tipo), sin que esto quiera decir que todos los objetos de la página o el background están involucrados. El manipulador (handler) hipotético discutido, presenta una condicional que limita el tratamiento del mensaje a objetos de tipo Hotword únicamente. Para hacerlo extensible a otros tipos de objetos (rectangle, polygon y ellipse) habría que modificar el código incluyo operadores de tipo OR que permitan incluir en la consideración a los otros tipos de objetos. To handle ButtonClick If object of target is hotword or \ object of target is rectangle or \ object of target is polygon or \ object of target is ellipse then End End -- aquí se escribe el código que presenta la definición de la palabra interactuada. Observación: El uso del símbolo \ (backslash) permite escribir en la línea inferior, código que sintácticamente debe escribirse en la misma línea. El manipulador, así modificado, permite adaptar el código a las nuevas circunstancias, sin embargo, si quisieramos hacer reaccionar a otros tipos de objetos diferentes de los previstos en el manipulador (hotword, rectangle, polygon, ellipse), habría que modificar el código e incluir en la conjunción a los nuevos tipos de objetos. Existirá alguna forma de hacer extensible el manipulador a otros tipos de objetos sin necesidad de modificar su código? La respuesta a esta pregunta la encotramos en el concepto SharedScript. En capítulos anteriores, se establece que el SharedScript constituye uno de los tipos de recursos del sistema. 157

13 En este sentido se dice que un SharedScript es un fragmento de código que puede ser compartido por múltiples objetos de diferente tipo y que garantiza que todos adopten el mismo comportamiento. Como todo recurso, ToolBook almacena una copia única del mismo. El concepto Sharedscript, evita la posibilidad de generar redundancia y facilita el mantenimiento del código. Observación: 1. A un objeto sólo se le puede asignar un SharedScript. 2. Si un objeto posee a la vez un script y un sharedscript, trá precedencia el script y no se ejecutará el sharedscript a menos que se utilice el comando forward. 8.6 Eventos y mensajes predefinidos ToolBook envía automáticamente un mensaje si se produce un evento vinculado a este, como es el caso del envío del mensaje ButtonClick cuando se oprime el botón izquierdo del ratón. Estos tipos de mensajes, que se envían automáticamente ante la presencia de un evento ocurrido son los que se denominan Build-in. (pre-definidos). Un programador también puede provocar el envío de un mensaje de este tipo, para lo cual puede utilizar la sisntaxis: S <Ident. Message> to Obj Por ejemplo, desde el script de un botón se le podría enviar el mensaje buttonclick a otro (por ejemplo llamado video). Ejemplo: S ButtonClick to button Video Si el button Video posee un manipulador para el mensaje buttonclick, se producirán las acciones previstas. Los manipuladores más comunes de ToolBook están asociados a mensajes y su sintaxis es la siguiente: To handle <Ident. Message> [Par1,Par2,...] Instruc1... Instruc2... Instruc3... [Break [Ident. Message]] [Ident. Message] 158

14 <Ident. Message> - es el identificador del mensaje (ButtonClick, EnterPage, Mouse Leave, etc) Par1, Par2, - Es una lista de parametros opcionales que puede tener el manipulador. Instruc1..., Instruc2..., Instruc3... representan los comandos que generan la respuesta al mensaje. [Break [Ident. Message]] Es un comando que permite interrumpir la ejecución del manipulador. Los mensajes predefinidos (build-in) de ToolBook pueden ser clasificados de la siguiente forma: Mensajes Mensajes de selección de items de menús Mensajes del ratón Mensajes de teclado Descripción Se envían directamente a la página cuando un item de la barra de menú es seleccionado, ya sea a nivel lector o a nivel autor. Se envían a nivel lector cuando se oprime un botón del ratón o el cursor intercepta los límites de un objeto. Se envían a nivel lector cuando se oprime una tecla. Mensajes de entrada y salida Se envían en circunstancias de apertura o cierre de ventanas (viewers), libros (books), fondos (backgrounds), páginas (Pages), navegación entre páginas o libros y se envían a objetos de tipo botón (button), campo (field), cuando el objeto recive o pierde el foco. Mensajes de notificación Mensajes "drag an drop" Mensajes de Interrogación Mensajes DDE Se envían para notificar al sistema de la ocurrencia de diferentes eventos (creación, destrucción de objetos, inactividad por parte del usuario, etc.). Se envían ante operaciones de arrastrar y soltar. Se envía aun objeto para determinar su estado o el valor de una determinada propiedad. Se envían cuando se produce un intercambio de información de ToolBook con otras apliaciones Windows. 159

15 Ampliación: Para mayor información acerca de los diferentes tipos de mensajes ToolBook consulte el capítulo 5 en el fichero tb70os.pdf que se encuentra en la carpeta manuals del disco de instalación Eventos de ratón Evento Mensaje: ButtonClick [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el usuario realiza una acción compuesta (pulsa y suelta) con el botón izquierdo del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, son parámetros cuyo identificador es intrascente e indican: a) Pos: Las coordenadas x,y del cursor expresadas en PageUnits en el momento de efectuar la pulsación. b) May: Parámetro Boolean (True o False) que indica si la tecla Shift está oprimida en el momento de la pulsación. c) Ctrl: Parámetro Boolean (True o False) que indica si la tecla Ctrl está oprimida en el momento de la pulsación. Evento Mensaje: ButtonUp [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el usuario suelta el botón izquierdo del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Evento Mensaje: ButtonDown [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el usuario oprime el el botón izquierdo del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Evento Mensaje: ButtonDoubleClick [Pos,May,Ctrl] 160

16 Descripción: Se produce a nivel lector cuando el usuario realiza una acción de doble clic con el botón izquierdo o el derecho del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Evento Mensaje: RightButtonDown [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el usuario oprime el botón derecho del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Evento Mensaje: RightButtonUp [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el usuario suelta el botón derecho del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Evento Mensaje: RightButtonDoubleClick [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el usuario realiza una acción de doble clic con el botón derecho del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Ejemplo: El siguiente código presenta 3 manipuladores en el script de un objeto que garantizan que si se pulsa con el botón izquierdo del ratón se visualice, en un field (campo) cuyo identificador es Traducción, una definición en idioma inglés de una supuesta palabra. Si en lugar de hacer un clic sencillo se ejecuta un doble clic, en lugar de visualizarse la definición en inglés se visualizará en francés y finalmente si se oprime el botón derecho se escuchará la pronunciación de esta palabra en idioma español. 161

17 To handle ButtonClick Put MyDefinitionIng of self into text of field Traducción To handle ButtonDoubleClick Put MyDefFrench of self into text of field Traducción To handle RightButtonUp get PlaySound ("C:\Castellano\pronu_esp.wave") " Observación: En el ejemplo anterior MyDefinitionIng y MyDefFrench son propiedades definidas por el programador que se han asignado previamente al objeto en cuestión. Evento Mensaje: ButtonStillDown [Pos,May,Ctrl,Der] Descripción: Se produce a nivel lector cuando el usuario mantiene oprimido el botón izquierdo o el derecho del ratón sobre el área activa de un objeto. Los parámetros Pos, May y Ctrl, son parámetros cuyo identificador es intrascente e indican lo mismo que el evento ButtonClick. El cuarto parametro Der es boolean y cuando es true indica que la acción se está realizando con el botón derecho del ratón. Ejemplo: El siguiente ejemplo colocado en el script de una página permite redimencionar un rectángulo llamado MiCaja a nivel lector. to handle buttonstilldown ploc items 3 to 4 of bounds of rectangle "MiCaja" = ploc buttonstilldown Evento Mensaje: MouseEnter [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el cursor intercepta el área activa de un objeto, desde su exterior. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. 162

18 Evento Mensaje: MouseLeave [Pos,May,Ctrl] Descripción: Se produce a nivel lector cuando el cursor intercepta los límites de un objeto desde su interior. Los parámetros Pos, May y Ctrl, indican lo mismo que en el evento ButtonClick. Ejemplo: Observación: 1. Syscursor es una propiedad del sistema que permite especificar la forma del cursor del ratón. Existe un conjunto de constantes que identifican diferentes formas del cursor, por ejemplo el valor 44 se corresponde con una mano, el 19 se corresponde con un lápiz, etc. 2. Es posible personalizar la forma del cursor a partir de ficheros.cur a través del sistema de recursos. Ejemplo: SysCursor= cursor Tijeras Script en un botón To handle MouseEnter syscursor=44 End To handle Mouseleave syscursor=1 End 163

19 Figura Eventos de entrada/salida Evento Mensaje: EnterBook Descripción: Se envía inmediatamente después de la apertura de un book y posterior al envío del mensaje EnterApplication. Ejemplo: To handle EnterBook syslevel=reader syscursor=4 Observación: El ejemplo anterior puede colocarse a nivel del script del objeto Book. Garantiza que posterior a la apertura del libro se pase incondicionalmente al nivel lector y el cursor adquiera la forma de reloj de arena. Evento Mensaje: EnterBackground Descripción: 164

20 Se envía si se muestra una página en un background diferente al que estaba mostrando. Observación: La acción de apertura de un libro, entre otras, también provoca el mensaje EnterBackGround. Ejemplo: To handle EnterBackGround Caption of this window=name of this background Observación: El ejemplo anterior puede colocarse a nivel del script del objeto Book. Garantiza que cada vez que se navegue a una página que se encuentre en un nuevo background, el texto que se encuentra en la barra de títulos de la ventana principal asuma el nombre del background activo. Evento Mensaje: EnterPage Descripción: Se envía cuando una página se muestra. Diferentes eventos pueden provocar el envío de este mensaje (navegar de una página a otra, mostrar un viewer (ventana), etc.). Observación: El ejemplo anterior puede colocarse a nivel del script del objeto Page. Este mensaje es de suma importancia para la inicialización de estados de objetos que se presentarán posterior a la navegación entre páginas. Ejemplo: to handle enterpage Hide button Continuar Show PaintObject "Pirámide del Sol" enterpage 165

21 Observación: En el ejemplo anterior al presentarse la página, automáticamente se esconde un botón denominado Continuar y se muestra una fotografía de la Pirámide del Sol. Evento Mensaje: EnterField / EnterRecordField Descripción: Se envía a un campo o a un campo registro cuando este recibe el foco. Ejemplo: To handle EnterField syscursor=19 Observación: El ejemplo anterior puede colocarse a nivel del script del objeto field. Al tomar el foco el campo (quedar listo para la escritura), el cursor del ratón adopta la forma de lápiz. Véase también el mensaje EnterButton. Evento Mensaje: LeaveField / LeaveRecordField Descripción: Se envía a un campo o a un campo registro cuando este pierde el foco. to handle LeaveField if text of self=null then request " La información de este campo es requerida!" if " Observación: El ejemplo anterior puede colocarse a nivel del script del objeto field. Al perder el foco el campo, se envía el mensaje LeaveField y su manipulador verifica si se ha introducido en el alguna información. Nota: Este mensaje es sumamente importante para implementar validaciones en el proceso de entrada de la información. Véase también el mensaje LeaveButton. 166