4to paso: diseñar una interfaz (parte II)

Viendo a Pier retirado a un rincón haciendo ejercicios de respiración, posición flor de loto (¿escuchaste Lotus Flower de Radiohead, último disco?), me surge algo así como un sentimiento de sana envidia al encontrarme yo en las antípodas de esa situación. No sé bien porqué, pero me parece que en el mini-proyecto que abordaremos en esta página no habrá mejor protagonista que nuestro amigo dibujante…(¿dije sana envidia?).
El tema a cubrir será el de la entrada por teclado y la posterior manipulación de estos datos externos, una interesante característica que fué agregada en la versión 1.4 de nuestro entorno de programación favorito — ¡si, es de Scratch que estoy hablando! —.
En este mini-proyecto haremos que Pier se presente y nos pregunte por nuestro nombre y apellido, para luego cerrar con un sorpresivo y cordial mensaje (todo un gentleman, vió…)  Let's work!

Chateando con Pier

El manejo de la capacidad de entrada por teclado en Scratch es —creo— de simple comprensión: utilizando el bloque preguntar (algo) y esperar —buscalo dentro de los bloques sensores— le damos al usuario la posibilidad de ingresar un texto (letras, números y otros símbolos), el cual será almacenado en un lugar especial (y único) que el entorno tiene ya preparado para la ocasión: el contenedor respuesta. A partir de allí podremos referenciar este dato dentro de nuestro algoritmo del mismo modo que lo hacemos con cualquiera de las variables "comunes y corrientes" que ya sabemos crear.
Pero allí se termina la semejanza con las variables: no podremos ni fijar ni cambiar su valor desde dentro del algoritmo, y especialmente su carácter de única nos obligará a tener cuidado con su uso. ¿Por qué? Porque cada vez que el usuario ingrese una nueva respuesta el valor almacenado previamente se perderá (es un típico caso de sobreescritura).
Por suerte existe un truco: si después de ser ingresado un valor para respuesta este se transfiere a una variable creada oportunamente por nosotros, este problema desaparecerá —lo veremos en un instante—. La regla general indica que conviene crear tantas variables como entradas por teclado se soliciten (aunque muchas veces pueden ser menos, o incluso ninguna).

Luz, cámara,…

Pongamos en acción un nuevo mini-proyecto.
Tomemos algún viejo trabajo que haya tenido a Pier como protagonista (el del cuadrado es una buena elección) y guardémoslo con un nuevo nombre (presentación, por ejemplo).
animación
Primero de todo borremos todo programa asociado al objeto Pier, y creemos un nuevo script. Te sugiero que añadas en un principio los primeros 6 bloques que ves en la imagen y pruebes a ver que pasa.
(Con tus conocimientos de Scratch no creo que haga falta ninguna aclaración sobre las acciones programadas).
Antes de seguir con el programa en sí necesitaremos crear dos variables para nuestro proyectinho… sus nombres serán autoexplicativos: nombre y apellido (en inglés first name y last name).
Llegó el momento de estrenar el uso de nuestro bloque "estrella": preguntar (algo) y esperar (desde ya que algo será una pregunta que Pier le dirigirá al usuario, y somos nosotros los deberemos determinar qué es lo que va a inquirir).
Fijate que la ejecución de nuestro script se detendrá hasta que el usuario ingrese por teclado su respuesta dentro del espacio reservado que se le presenta en la parte inferior del escenario. Una vez que dé el OK (con ENTER o usando el check mark  check mark ) el programa sigue su curso, quedando almacenado el texto ingresado en el contenedor respuesta.
Dado que Pier va a realizar una pregunta más, necesitaremos hacer una copia del contenido de respuesta en otro contenedor: usaremos a tal fin nuestra variable nombre. A partir de esta acción de copiado (la cual es efectuada por la instrucción fijar (nombre) a respuesta) ya podremos despreocuparnos de ulteriores ingresos de texto que sobreescriban el contenido de nuestra variable única y especial .
Nos falta repetir ahora la misma secuencia pero dedicada ahora al ingreso y almacenamiento del dato "apellido del usuario". El contenido previo de respuesta será sobreescrito —pero nosotros ya tomamos los recaudos necesarios al respecto—.
NOTA: Dada la simpleza de nuestro programita en realidad no necesitaríamos del copiado en la variable apellido con el bloque fijar (apellido) a respuesta (de hecho no necesitaríamos haber creado esa variable), pero para darle cierta "simetría" a nuestra solución preferí que se tomen las mismas acciones ante el ingreso y almacenado de los 2 datos externos del usuario.
Ya tenemos las piezas fundamentales de nuestro rompecabezas… ¡y será casi un rompecabezas el que deberemos armar!

Actitud zen

La clave de lo que sigue es hacer decir a Pier algo donde se mezcla un texto fijo con el texto ingresado por el usuario… el objetivo es que nos quede: ¡un gusto,_Juan_Pérez! —desde luego que tanto nombre como apellido variarán según el ingreso de datos de cada usuario ("¡obvio!") —

IMPORTANTE

Conviene notar que en vez de un espacio en blanco de forma deliberada coloqué un guión bajo ( _ ), algo que es muy útil en la etapa de prueba del encadenamiento de texto . Una vez conformes con el resultado deberemos reemplazarlos convenientemente.
Para lograr esto necesitaremos utilizar uno de los operadores que Scratch nos ofrece para manipular las variables y constantes de tipo texto: el bloque unir ( ) ( ).
Con el uso de varios de estos bloques pueden conseguirse construcciones muy complejas y flexibles, pero que suelen requerir de nosotros una gran cuota de paciencia —materia prima que suele escasear—.
¿El motivo? Con estos bloques sólo puede trabajarse tomando las cadenas de texto de a dos ("what?").

Una cadena de texto está constituida por una secuencia de una o más letras, números o símbolos (generalmente con cierto significado semántico) que puede ser tratada como una unidad por parte del programa. Si son fijas (o constantes) son ingresadas directamente en los bloques que pueden manejarlas (decir, pensar, preguntar, unir, etc.), pero también pueden almacenarse en variables creadas por el usuario y, por supuesto, en el contenedor respuesta.

Como quizás hayas alcanzado a inferir, la cosa se complica cuando hay que concatenar varias cadenas de texto de fuentes diversas.
Otra cosa a destacar es que existen muchas maneras de llegar a un resultado correcto (todas igualmente válidas).
orden de armado
En la imagen más reciente podés ver la secuencia que yo seguí, desdoblada en tres pasos siguiendo un creciente nivel de "anidamiento".
La mejor manera de poder entender ésto —como muchas veces sucede— es "practicar con obstinación" hasta poder dominar el truco, e incluso animarse a proponer alguna otra solución igualmente viable.
Recordá que una vez que la implementación te funcione, deberás reemplazar el guión bajo (_) por un espacio en blanco [el producto de pulsar 1 vez la barra espaciadora] en los 2 lugares donde esto es necesario.
Un tip que te puede ser útil: podés ir probando el resultado de la concatenación de textos haciendo doble clic sobre el bloque unir.
Una vez que quedó todo ensamblado, probá el mini-proyecto y verificá los resultados… si está todo OK ya podés guardarlo.
¿Sorprendido? No creo que tanto como Pier, que pasó de un estado cuasi-contemplativo al de la más desbordada de las euforias —para describir esto es que se inventó la palabra ciclotimia—.
Ya conocemos cómo es…¡las luces del escenario lo pueden!, y al verse como absoluto protagonista del proyecto y charlando directamente con el usuario ya se ha puesto realmente "pesado"… ¡si ya está pidiendo que le den más letra!
Creo saber ahora lo que debió sentir Herr Frankenstein… ¿será el momento de parar con nuestro experimento? ¿se volverá en nuestra contra? ¿son tornillos los que sobresalen de las sienes y mandíbula de Pier? Para saber la respuesta no te queda otra que seguir leyendo esta gótica historia…
Última actualización: Febrero 25, 2014

No hay comentarios.:

Publicar un comentario

© Scratch CodeLab | D153ñ0 b454d0 3n l4 pl4n71ll4 SimpleRWD d3 Oloblogger