OOo Basic. Interface.

Formularios (b). Writer (1)

Analizo ahora el acceso a los controles de uso más frecuente en un formulario desde OOo Basic. Esta entrada complementa, pues, una [entrada anterior] en la que se analizó el esquema general de trabajo con formularios desde un script.

Los controles de uso más frecuente en un formulario son cuatro (2): Caja de texto, Cuadro de lista, Botón de opción y Casilla (de verificación). Los dos primeros para facilitar la entrada de datos y los dos últimos para facilitar la selección de opciones.

Como ya sabemos, todos los controles de formulario deben ser implementados en el documento-soporte (ver [aquí] en los primeros párrafos de la entrada sobre procedimientos de implementación de Formulario), pero además es posible (y generalmente necesario) conformar la apariencia y forma de funcionamiento de cada uno de ello de forma específica. Para ello deberemos acceder a Propiedades del control, opción disponible a partir de la ventana emergente que activamos mediante Selección del control -> Clic derecho sobre el control seleccionado. Una vez dentro de este menú de opciones, podremos configurar nuestro control del modo que deseemos.

El control Cuadro de texto posiblemente sea el control más sencillo ya que se comporta funcionalmente como un InputBox(). No obstante presenta características plenas como Control de formulario (por lo que debe ser tratado como tal) y posibilidades de uso diferentes (y mucho más ricas) que las que ofrece InputBox() (3). El modo de acceso a su contenido sigue el procedimiento descrito en la segunda parte de [esta entrada], a la que remito para no repetirme aquí. Me limito ahora a explicar cómo podemos acceder al contenido textual propio de Cuadro de texto.

Dim oTxtNombre As Object

Dim sNombre As String

Dim mDatos(6) As String

oTxtNombre = oForm.getByName("txtAlNombre")

sNombre = oTxtNombre.Text

mDatos(0) = oTxtNombre.Text

• Definido y caracterizado el funcionamiento de Cuadro de texto desde Propiedades del control, queda identificado por su Nombre (una de las opciones disponibles en Propiedades del control); por ejemplo "txtAlNombre" . Este nombre nos facilita una de las formas de acceso al control (oTxtNombre = oForm.getByName("txtAlNombre"))
• Previamente deberemos haber creado una variable tipo Object para capturar el objeto control deseado (Dim oTxtNombre As Object), ya que necesitamos esta variable para hacer posible el acceso al control y a su contenido.
• Tras acceder al control según la sintaxis ya expuesta (oTxtNombre = oForm.getByName("txtAlNombre")), la segunda fase del procedimiento consiste en acceder al contenido, necesariamente de tipo texto, dada la naturaleza de Cuadro de texto. Esto nos obliga a declarar previamente una variable tipo String o una matriz del mismo tipo (Dim sNombre As String y Dim mDatos(6) As String en nuestro caso) (4), a la que  asignar el contenido del control.
• Esta asignación se realiza mediante la siguiente instrucción. En ella oTxtNombre contiene el objeto Cuadro de texto y a través del objeto accedemos a su atributo Text, que es el que contiene a su vez el texto que el usuario ha introducido en Cuadro de texto, cadena alfanumérica que pasa a ser referenciada en la variable sNombre

sNombre = oTxtNombre.Text

El control Cuadro de lista se diferencia del control anterior por sustituir la entrada de texto de escritura libre por una entrada de valores, que es el listado de opciones que se presentan a la elección de usuario. Este listado puede crearse directamente desde Propiedades del control -> General -> Entradas de la lista o desde Propiedades del control -> Datos -> Tipos de contenido de la lista opción Lista de valores. Esta segunda opción también permite asociar el control a una tabla, una consulta o a otras opciones.

El acceso al control Cuadro de lista es igual que el acceso a Cuadro de texto, pero no así el acceso al contenido (en  este caso) seleccionado (la entrada del Cuadro de lista por el que opta el usuario). Observa el siguiente segmento del script:

Dim oCurso As Object, oCursoVista As Object

Dim sCurso As String

Dim mDatos(6) As String

oCurso =  oForm.getByName("curso")

oCursoVista = ThisComponent.getCurrentController.getControl( oCurso )

sCurso = oCursoVista.getSelectedItem()

mDatos(2) = oCursoVista.getSelectedItem()

•  Para acceder al Cuadro de lista necesitamos dos variables Object. 
• La primera (oCurso) nos permite acceder al control como tal (oCurso =  oForm.getByName("curso"))
• y la segunda (oCursoVista) a su listado de opciones (oCursoVista = ThisComponent.getCurrentController.getControl( oCurso ))
• Posteriormente asignamos la opción seleccionada (método getSelectedItem()) a una variable String, previamente declarada (Dim sCurso As String) haciendo uso de ese método (sCurso = oCursoVista.getSelectedItem()) (5)

El control Botón de opción es en realidad un conjunto (al menos dos) de controles que se vinculan entre sí, ofreciendo al usuario la posibilidad de elegir entre uno de ellos (el resto se descartan), por lo que presenta un comportamiento similar al del Cuadro de lista (en el que el usuario debe optar por una de las opciones que se le presentan), aunque en su apariencia formal son muy diferentes.

También lo son en el modo en que se accede a la opción seleccionada, requiriendo Botón de opción un manejo similar al que hacemos del valor que devuelve la función MsgBox() (6).

El acceso al "contenido" en Botón de opción es en realidad la captura de su pulsación por el usuario (oBtn1 = oFormulario.getByName("btn1")), y se requieren tantas variables como botones de opción contenga nuestro conjunto de opciones. Por ejemplo, en este caso, sólo dos (Dim oBtn1 As Object, oBtn2 As Object): el primero para capturar la pulsación del botón btn1 (oBtn1 = oFormulario.getByName("btn1")) y el segundo para capturar la pulsación del botón btn2 (oBtn2 = oFormulario.getByName("btn2"))

 

el acceso a los controles casilla y botón presenta un grado de dificultad intermedio entre los dos anteriores y más similitud entre sí de la que aparenta. Se diferencian, eso sí, en el modo en que se utilizan en un formulario incrustado en Calc en el que estos controles se asocian a celdas, pero no tanto en caso de acceso directo (cuestión esta aun no tratada).

De hecho en Writer a los datos de casillas y botones se accede del mismo modo mediante OOo Basic, esto es, mediante el valor que adopta la función state(), que permite identificar si el botón o la casilla han sido seleccionados (1) o no (0) (valores booleanos).

Pero el funcionamiento de ambos controles en el funcionamiento dentro del formulario es diferentes: mientras que los botones se presentan claramente asociados y vinculados, las casillas son y tienen un funcionamiento independiente (unas de otras).

Documento

• Formulario de ejemplo con botones y casillas.

Este documento no tiene más función que la de ejemplificar el funcionamiento de las casillas y botones y de mostrar el modo de acceder a su contenidos mediante script OOo Basic.

NOTAS 

(1) Al igual que la [entrada que la precede], ésta sustituye e incluye el contenido de otras dos publicadas el día 8/07/2023. En ambas se analizaba el funcionamiento de un formulario creado sobre Writer y usado desde un script OOo Basic y el modo de acceso al contenido de sus controles.

(2) LibreOffice cuenta con un listado de controles de formulario mucho más amplio, pero estos cuatro cubren la mayoría de las necesidades que buscamos satisfacer con un formulario, de ahí que sean los de uso más frecuente y, por tanto, los que más interés tienen para la creación de un docap basado en Formulario.

(3) El manejo de Cuadro de texto requiere el mismo procedimiento de acceso que cualquier otro control de formulario, por lo que no es factible trabajar con él como con InputBox(). En términos de funcionalidad, Cuadro de texto permite opciones de configuración que no están disponibles en InputBox() (que en esto es muy limitado); destaco por su utilidad la posibilidad de configurarlo multirrenglón, además de los formatos de texto (incluido tamaño de letra). Estas opciones de configuración permiten un uso muchos más amigable y funcional como interface, si bien requiere un trabajo previo de configuración desde Propiedades del control.

(4) La doble asignación a variable + matriz es innecesaria, aunque aquí la empleamos por motivos didácticos. En la explicación que sigue a esta nota en el cuerpo de la entrada sólo se recoge una de las dos alternativas de asignación, pero en el script se emplean ambas. El uso de la doble asignación podría estar justificada en algunos casos, pero entonces sería más adecuado que la propia variable se asignara al elemento x de la matriz (sNombre = oTxtNombre.Text -> mDatos(0) = sNombre).

(5) Recuerda lo dicho en (4) respecto al tratamiento de la matriz mDatos(). Omito ahora comentar esta parte del script. Al contrario que en Cuadro de texto, en el que el acceso al control requería el uso de la propiedad Text del control (sNombre = oTxtNombre.Text), ahora el acceso a la opción seleccionada por el usuario se hace invocando los métodos .getCurrentController.getControl( oCurso) del objeto Cuadro de lista. Esto supone un procedimiento mucho más complejo que en caso del control Cuadro de texto o el control Campo de fecha, que sigue el mismo procedimiento: 

oFecha = oForm.getByName("fecha")

sFecha = oFecha.Text

(6) También en este caso deberemos tratar el valor devuelto mediante una estructura decisional (condicional If)

OOo Basic. Interface.

Formularios (a). Writer. (1)

Además de las formas simples de interface (MsgBox e InputBox), LibreOffice cuenta con otros dos recursos de interface: los formularios y los cuadros de diálogo. Los formularios son medios para facilitar la interacción usuario-programa, empleados fundamentalmente en la fase Input. A diferencia del cuadro de diálogo (en adelante, Diálogo, por brevedad), el formulario se puede emplear tanto como funcionalidad (2) como asociado a a un script.

En esta entrada trataré sobre el uso del formulario sobre un documento Writer, aunque es extensible a su uso en otros servicios (Imperss, por ejemplo); posteriormente se analizará el uso del formulario sobre una hoja de cálculo (Hc) Calc. Los formularios de base de datos (Base) quedan fuera de nuestros objetivos.

La forma más básica de usar un formulario en Writer (3) es como medio para facilitar la entrada de información a un documento. Es una forma más elaborada de presentar documentos que contienen tablas como recursos para al entrada (input) de datos: un ejemplo, las carátulas de los documentos prescriptivos de evaluación (4).

Cierto que a nosotros nos interesa ir más allá del uso de Formulario como funcionalidad (esto es: nos interesa utilizarlo como recurso input en un script), pero no podemos olvidar que el primer paso va a ser necesariamente crear el formulario en y sobre el documento-base; de ahí la importancia que tiene dominar este prerrequisito; algo que no podemos dar por sentado, ya que como funcionalidad no está directamente disponible y en la práctica, en los documentos de trabajo (tanto los prescriptivos como en los que nosotros mismos creamos) predomina el uso de tablas sobre los formularios como medio de recogida y presentación de la información.

Además los medios para crear un formulario no tienen por qué estar disponibles por defecto, así que pueden quedar ocultos al usuario medio, siendo esta una de las causas de su escaso uso. Por ello, lo primero que tenemos que saber es cómo activar las opciones Formulario: Ver|Barra de herramientas|Diseño de formularios (muestra los controles del diseño de formularios) y Ver|Barra de herramientas|Controles de formularios (muestra la barra de herramientas que nos permite acceder a los diferentes campos de que puede constar un formulario). A partir de aquí lo único que debemos hacer es seleccionar el icono Modo diseño... (5)

... para entrar en la capa dibujo del documento y habilitar el acceso a los controles de formulario, seleccionar el icono del control que deseemos utilizar y posicionarlo en el documento.

Una vez creado el formulario, para crear un script que facilite su uso como recurso Input en un script, necesitamos acceder al IDE y, desde éste, trabajar en el script mediante el lenguaje OOo Basic. En esto centraremos el contenido de esta entrada.

Un script que nos permita acceder a un formulario creado en un documento y a sus controles se divide en tres fases sucesivas: 

• En la primera accederemos al formulario creado en el documento.

Dim oDocumento As Object, oCapaDib As Object, oForms As Object, oForm As Object

oDocumento = ThisComponent
oCapaDib = oDocumento.getDrawPage()
oForms = oCapaDib.getForms()

oForm = oForms.getByName("frmActua")

Observa que todas estas variables son de tipo Object, lo que significa que, en esta fase del procedimiento estamos accediendo a los objetos que están o pueden estar en la base del soporte (del documento Writer) según la lógica de su código como programa.

Observa también que, siguiendo esa lógica, el formulario se ubica (es accesible) desde la capa gráfica del documento (DrawPage()), de la cual es uno de sus posibles componentes. Esta capa gráfica no es accesible desde la capa en la que nos situamos con el cursor cuando escribimos. (6)

• En la segunda fase nos centramos en acceder a los controles del formulario y a su contenido.

Dim oTxtNombre As Object

Dim mDatos(6) As String
Dim i As Integer

 

oTxtNombre = oForm.getByName("txtAlNombre")

mDatos(0) = oTxtNombre.Text

 Observa que este subproceso se desarrolla en dos fases:

• En la primera fase accedo a los controles, que son también objetos, de ahí que las variables que facilitan este acceso se declaran de tipo Object (v.g. Dim oTxtNombre As Object). El acceso se concreta mediante esta expresión: oTxtNombre = oForm.getByName("txtAlNombre")
• En la segunda fase accedo al contenido de los controles, que como son de tipo texto, asocio a una matriz String (Dim mDatos(6) As String). La sintaxis de esta instrucción para acceder a un control simple de texto es la siguiente: mDatos(0) = oTxtNombre.Text. (7)

•  Y finalmente, en la tercera, trabajaremos con ese contenido mediante los medios y procedimientos que mejor se ajusten al objetivo del script. Por ejemplo, y para simplificar, mostrar el contenido de los controles en pantalla mediante MsgBox, haciendo uso de un bucle para recorrer la matriz (8)

For i = 0 To 5

MsgBox mDatos(i)

Next

Documento. Te doy acceso al documento que contiene el formulario y el código desde el enlace siguiente:

• Formulario de prueba basado en documento Writer

Recuerda que debes descargarlo y abrirlo con LibreOffice y acceder al script desde el IDE (Herramientas/Macros/Editar macros)

NOTAS

(1) Esta entrada sustituye e incluye el contenido de otras dos publicadas el día 8/07/2023. En ambas se analizaba el funcionamiento de un formulario creado sobre Writer, empleado como interface Input dentro de un script OOo Basic.

(2) Por funcionalidad entiendo cualquier recurso que puede ser desarrollado desde la interface general del servicio (Writer, por ejemplo), sin necesidad de acceder al IDE. En Writer los formularios se crean en la capa "Dibujo" del documento directamente desde éste. Para crear un Diálogo es necesario acceder al IDE y crearlo específicamente de forma directa. Desde esta perspectiva el formulario es un objeto más accesible y simple que un diálogo.

(3) Y en el resto de los servicios, a excepción de Base, que tiene su propia lógica,  al ser dependiente necesariamente de los campos de la base de datos.

(4) Recuerda que puedes convertir un documento Writer en un pdf, incluso manteniendo la funcionalidad del formulario y sus controles. Esto permite crear formularios en pdf para que el usuario los cumplimente sin necesidad de tener instalado LibreOffice. Esto da mucha más versatilidad al documento de recogida de datos.

(5) Este procedimiento implica activar el icono de la barra Controles de formulario. Este mismo icono está también disponible en la barra del Diseño de formulario. Activarlo también supone acceder a la definición del formulario y a otras utilidades, incluyendo la introducción de campos (comando Añadir campo), que también activa la barra Controles de formulario.

(6) El comportamiento del formulario en un soporte Calc es mucho más simple, ya que permite que (algunos) de sus controles se asocien directamente con las celdas de la hoja. Esto facilita el trabajo con formularios (mejor dicho, con los controles de formulario) en Calc.

(7) En realidad esta es una simplificación del sistema de acceso a los datos de los controles, tomando como referencia uno de ellos (Cuadro de texto), que es uno de los más simples (similar a un InputBox(), aunque más complejo. Queda para otra entrada la explicación de cómo emplear y acceder al contenido de diferentes controles del formulario.

(8) Esta es una de las opciones posible, no tanto de trabajo como de ejemplificación y constatación del funcionamiento del script. En un uso práctico deberíamos crear un procedimiento de trabajo que incluye el procesamiento de los datos y su uso para resolver un problema, como, por ejemplo, la creación de un texto en el que se analicen los resultados obtenidos en función de la fase de procesamiento. Pero lo que ahora nos interesa es constatar que hemos accedido a los datos del formulario, base para el desarrollo posterior del script.

OOo Basic. Interface.

Formularios. Acceso al contenido

Tendiendo en cuenta que hemos basado el uso de controles de formulario en Calc en su asociación con celdas, es necesario explicar específicamente el modo de acceso al contenido de las celdas desde OOo Basic.

Son ya unos cuantos los docap en los que he usado este procedimiento, pero no está demás dejarlo plasmado en una entrada específicamente dedicada a ello, ejemplificado el procedimiento con un sencillo documento Calc.

La simplicidad del procedimiento (a estas alturas del blog, claro) facilita que la entrada sea breve: sólo un poco de código de ejemplo...

Dim oDatos As Object, oCurso As Object

Dim sCurso As String

oDatos = ThisComponent.getSheets().getByName("Datos")

oCurso = oDatos.getCellRangeByName("B2")

sCurso = oCurso.getString()

NOTA. Después de declarar las variables necesarias, asignamos a ellas los objetos principales: primero la hoja (en este caso por el nombre, pero podría ser también por índice), y después la celda (también por el nombre, pero podría ser por la referencia de posición). Posteriormente accederíamos a su contenido (que asignamos a la variable string sCurso) mediante el método getString(). Si quisiéramos escribir en la celda usaríamos setString("Texto")

... y, para finalizar, este documento calc en el que ejemplifico el procedimiento de acceso al contenido de celdas y de escritura en celdas.

OOo Basic. Interface.

Formularios. CheckBox y OptionButtom

Siguiendo con el uso de formularios en Calc, una vez que aprendimos a manejar cuadros de texto y cuadros de lista, podemos avanzar un poco más y aprender a usar casilla de verificación y botones de opción, por ser también ambos controles de uso frecuente.

Las casillas de verificación (CheckBox) son controles asociados a variables lógicas (Verdadero - Falso) empleadas para identificar si se cumple o no una determinada condición.

Los botones de opción (OptionButtom) son controles que permiten elegir una entre varias opciones disponible. Por ese motivo trabajan juntos como mínimo dos botones, aunque lo normal es que sean más. La elección de uno de ellos (de una opción) implica la no elección del resto.

La diferencia entre ambos controles radica en que 

• Las casillas son independientes unas de otras, por lo que es posible seleccionar más de una puesto que no están vinculadas. Los botones sí lo están, por lo que sólo es posible seleccionar uno entre todos los que forman el conjunto de opciones.
• Los botones de opción se asocian a la elección de la opción o contenido implícito; las casillas a la confirmación del valor True para la condición expresada en el control.

Dado que este entrada está dedicada al uso del control en un documento Calc, suponiendo la asociación del control a una celda, en realidad las casillas de selección no ofrecen (en Calc) mayor dificultad, puesto que es posible realizar esa asociación sin mayor dificultad (igual, por ejemplo, que hacemos con un cuadro de texto.

En este ejemplo, la casilla de verificación "Niño" se utiliza para identificar el sexo del sujeto, asociando el valor resultante a la celda B3 de la hoja "Datos" del libro Calc. En caso de estar seleccionada la casilla, en la citada celda se escribirá "Niño", y si no está seleccionada se escribirá "Niña".

Aunque este uso de la casilla de verificación puede considerarse sustitutorio del botón de opción (y de hecho es posible usarla también con esta función), sin embargo el procedimiento de uso crea un potencial problema: si se trata (en el ejemplo) de una niña, el usuario no marcará la casilla en la creencia de que es suficiente con abstenerse de marcarla para que se recoja la opción implícita (Niña). Pero el funcionamiento del control sólo escribirá "Niña" en Datos.B3 si primero se seleccionó la casilla y después se retira la selección. De no hacerlo no escribirá nada. Tenemos dos formas de evitar esto:

• Usando dos casillas, una para la elección Niño y otra para la elección Niña
• O usando dos botones de opción.

Dada la versatilidad de las casillas de selección perfectamente podemos utilizar un juego de dos casillas, asociadas ambas a la misma celda, obligando entonces al usuario a seleccionar una y otra según el valor que asuma la variable asociada. De este modo nos ahorramos trabajar con botones de opción.

Pero si preferimos "hacer las cosas bien" y usar los controles más ajustados al objetivo, en este caso deberemos admitir que corresponde hacer uso de los botones de opción.

Lo malo es que, por defecto, el menú Controles de formulario de Libre Office Calc no dispone de icono para los botones de opción (entiendo que esto se relaciona con la "irrelevancia" de la diferencia entre casilla y botón), siendo necesario "reconvertir" otro control a botón de opción.

Una vez hecha esta "reconversión" (que sí es perfectamente posible), nos damos cuenta que el funcionamiento de la pareja de botones de opción es exactamente el mismo que el de las casillas de verificación. Por ello, la solución primera (dos casillas de verificación) tiene la misma utilidad y funcionalidad que usar dos botones de opción (y viceversa). Queda a tu elección qué solución adoptar.

Resumiendo, aunque casillas y botones son dos controles teóricamente diferentes en cuanto a su naturaleza y funcionamiento teórico, en la práctica del uso de ambos controles en una hoja de cálculo en la que asociamos los controles a celdas, las casillas de opción cumplen también las funciones propias de los botones de selección.

Dado que las circunstancias lo permiten (y hasta sugieren), al igual que hice en otra ocasión, para evitar hacer innecesariamente extensa esta entrada (su objetivo ya está cumplido), me abstendré de más desarrollo o ejemplificación, incluyendo formalizar las explicaciones previas en un supuesto formulario o repetirlas en un vídeo. 

Teniendo en cuenta lo que ya sabemos hacer a estas alturas, ninguno de los dos recursos van a aportar más a lo ya dicho aquí.

Documentos. Dictamen.

Dictamen - 1. Modelos documentales.

Crear un docap para cumplimentar el modelo de dictamen de escolarización implica partir del modelo de informe, pensando, al igual que en éste, en la especificidad del dictamen por nueva escolarización y lo que esto implica. Además las características de este documento (su presentación exclusivamente en formato de tablas) obligan a plantearse procedimientos específicos dentro del proceso de creación del código OOo Basic.

Partir del proceso anterior (docap sobre informe) facilita, en efecto, de manera significativa la creación de este tercer docap ya que muchos campos son compartidos. Además adaptar el dictamen al proceso de nuevas escolarizaciones como paso previo a la creación del docap, siguiendo el modelo de trabajo desarrollado con el docap informe, nos permite un ahorro de trabajo nada desdeñable. No obstante, la creación del docap Dictamen supone retos interesantes de programación, los cuales nos servirán para plantear, más adelante, el desarrollo de propuestas más generales.

Estos retos son debidos, como dije antes, por la formulación del Dictamen en formato tablas, las cuales, además, no están pensadas desde la perspectiva del trabajo con recursos informáticos mínimamente adaptados al objetivo que supone elaborar un dictamen de escolarización. Es más, se puede decir que en algunas cuestiones (la identificación de las NEE, por ejemplo), parece que el modelo de dictamen está pensado para ser cubierto manualmente.

Por ello, es perfectamente posible que la mejor alternativa para trabajar con este documento pudiera ser crear un formulario al estilo de los desarrollados por otras comunidades autónomas, ya que esta fórmula responde fácilmente al planteamiento objetivo del documento. Al respecto aporto los modelos (supongo vigentes, pero no me es posible asegurarlo) de las consejerías de educación de Castilla  y León y Castilla-La Mancha (no son las únicas que ofrecen formularios como ayuda y delimitación de modelo documental), así como el modelo de dictamen de Asturias y una formulación del mismo como formulario pdf, a la manera de las propuestas antes indicadas.

No obstante, he considerado que también es conveniente crear un docap siguiendo los ejemplos desarrollados en entradas anteriores, tanto por que es conveniente completar el proceso iniciado manteniendo el mismo formato, como por el reto que supone crear soluciones mediante código OOo Basic. Es cierto que es un esfuerzo posiblemente poco rentable en términos de ahorro de tiempo por lo dicho en el párrafo anterior, pero no por ello menos interesante desde el punto de vista informático.

Dado que la elaboración del docap proceso va a llevar cierto tiempo, que es posible diferenciar dos fases en la elaboración de esta propuesta y que explicar el código del docap va a exigir que la entrada sea de cierta extensión, me ha parecido conveniente dividir la presentación de estos contenidos en al menos dos entradas: 

• En esta primera (que finaliza ahora) proporciono los materiales básicos, incluyendo una versión formulario del documento Dictamen (no docap) 
• Y en la segunda me dedicaré a trabajar específicamente sobre el código del docap.

Estos son los materiales que te proporciono en esta entrada...

• Modelo Dictamen Asturias.
• Modelo Dictamen como formulario a partir del  documento anterior y en formato odt
• Modelo formulario de Castilla y León
• Modelo formulario de Castilla-La Mancha.

Documentos. Acreditación

Acreditación -7. Docap complejo (d1)

Iniciando con lo prometido nos adentraremos ahora en el análisis del conjunto de script  que conforman esta docap.

Podemos ver en la imagen que sigue los tres módulos que componen la biblioteca Standard y los script individuales que contienen. 

• Tenemos, en primer lugar, un módulo con script auxiliares cuyas funciones indican sus propios nombres. Dado que no se trata de script centrales del docap actual, no nos detendremos a explicar su funcionamiento.
• El módulo CapturaDatos reúne los script cuyo cometido es recopilar la información que aporta el usuario o usuaria (fase input)
• Y el módulo CreaDocum contiene el script que se ocupa de trasladar los datos anteriores al documento Writer que nos sirve de base para crear la acreditación.  
  
  

Además del módulo auxiliar, esta estructura revela la existencia de un proceso dividido en dos partes: el acceso a los datos y su ubicación controlada en celdas del soporte Calc y la captura del contenido de las celdas y su traslado al documento Writer.

En esta entrada nos centraremos en los script que forman parte del módulo CapturaDatos: DadosDocum y DatosAlumn; esto es, en la captura de datos del usuario 

Documentos:

• Fuente de datos (Base)
• Gestor (calc)
• Documento (Writer)

Documentos. Derivación

Formulario de derivación del Equipo Regional 

Tratando de responder a posibles necesidades prácticas, se me ha ocurrido que el documento actualmente vigente de solicitud de colaboración al Equipo Regional de Atención al ACNEAE podría ser un buen ejemplo de utilidad del uso de OOo Basic.

El documento lleva por título DEMANDA DE COLABORACIÓN AL EQUIPO REGIONAL DE ATENCIÓN AL ACNEAE, es accesible desde la web del Equipo y tiene una pretendida funcionalidad de facilitación de la comunicación entre el ER y el resto de los SEO del Principado de Asturias. 

Su formato (documento Word) es de un formulario teóricamente pensado para uso tanto manual (documento impreso y cumplimentado a posteriori) como (posiblemente como forma prioritaria) para ser cumplimentado mediante el propio programa MS-Office (Word). 

En su momento ya analicé la ambigüedad de este tipo de formatos y los errores de diseño en que se suelen incurrir. El documento del ER no es, en esto, una excepción, ya que se incurre en formulaciones mixtas que terminan complicando más que facilitando el uso del mismo. Ejemplo de ello, lo que muestra esta captura:

• Junto con un impecable uso de tablas para facilitar la estructuración del contenido, esta composición está correctamente diseñada para usar el documento en formato papel pero no para ser cumplimentado mediante el procesador de texto: las casillas de selección/verificación no son accesibles desde Word.
• Ejemplos de este tipo de errores no es que sean especialmente abundantes en el documento, pero por la escasa frecuencia de este tipo de formulaciones (tres ítem), ya no hay ocasión en la que se pueda cometer este error que no se produzca, lo que es coherente con la previsión de un uso manual del documento.
• No obstante, también hay ítem que parecen pensados para utilizar el procesador de texto, como los dos primeros de la segunda página, ya que no parece razonable pensar que el espacio reservado sea suficiente si los cubrimos a mano.

Veamos ahora un ejemplo de uso incoherente de tablas, que también los hay:

• Otra vez nos encontramos con un diseño aparentemente pensado para ser usado manualmente, ya que el uso mediante Word no se ve facilitado ni en el dimensionamiento de los espacios de respuesta ni en los desplazamientos.
• Por un lado se desperdicia espacio y por otro no se aprovechan las ventajas del uso de las tablas (desplazamiento mediante tabulador), lo que favorece que se desbarajuste el documento si se trabaja con el procesador de textos.

En resumen, este documento de derivación parece no haber sido repensado en términos de informatización de los procesos de comunicación entre Servicios, heredando formulaciones propias del uso manual que tuvo en su tiempo este tipo de materiales. Esto no facilita precisamente el logro de la finalidad que se pretende con él, ya que dificulta su manejo por parte de todos los profesionales que lo utilizan, incluyendo a los propios componentes del ER-ACNEAE.

Aunque no es el principal objetivo de esta entrada, como previo a éste, me considero obligado a ofrecer una opción que considero sí puede ser funcional para usar en soporte digital. Después crearé una alternativa pensada mediante OOo Basic.

El primer resultado de esta propuesta de modificación es este documento-base que, como se ve, lo que hace es redefinir la formulación original empleando sistemáticamente el formato tablas. De este modo, el documento, que se presenta dividido en tres partes (al igual que el original), se puede cumplimentar usando el procesador de texto sin más requisito que pasar de celda mediante el tabulador.

Dado que se pretende cumplimentar con el procesador de texto, los espacios reservados para las respuestas se ajustan al contenido sin ningún tipo de previsión al respecto, por lo que la apariencia del documento-base es una mera aproximación a lo que resulte de su uso en la práctica. No obstante, es posible que no se produzcan cambios significativo al respecto.

En este enlace te dejo copia al [documento-base] en formato .odt (LO-Writer). Recuerda que tienes que descargarlo y guardarlo en tu ordenador, pero también que tienes que tener instalado el [software Libre Office].

En buena lógica, el siguiente paso sería convertir el documento-base anterior en un formulario, lo que supone utilizar los controles propios de esta interfaz y su posterior conversión en un formulario .pdf (esta recomendable). Si alguien lo considera conveniente y lo solicita, no tengo ningún inconveniente en realizar una propuesta de este tipo, pero no es lo que entra dentro de mis planes en este momento, así que me ahorraré un trabajo que,  no obstante, considero puede ser de interés.

Lo que sí me voy a plantear es utilizar algunos de los recursos disponibles desde  la funcionalidad Grabar macro y/o OOo Basic para desarrollar una alternativa al uso del documento-base anterior. Para ello es conveniente analizar su naturaleza, ya que las alternativas disponibles son diversas y su idoneidad puede estar relacionada con el uso previsto para el documento en cuestión.

Partiré de que este documento va a ser utilizado en soporte informático (nada nuevo hasta ahora respecto al documento-base) y que posiblemente sea cumplimentado al menos por dos personas; OE y tutor/a (la firma de una tercera, no resulta especialmente relevante). (1)

Aunque las delimitaciones anteriores no condicionan en exceso ni cierran las opciones disponibles (un formulario sigue siendo una buena opción), en este caso voy a optar por utilizar las marcadores de texto como medio para facilitar la automatización de la escritura del documento y un sistema combinado de ventanas emergentes y/o cuadros de diálogo para recoger la información necesaria para cumplimentar el documento.

Esta alternativa es una concesión al aprendizaje de una estrategia concreta (la descrita), pero posiblemente sea una alternativa excesivamente costosas, por lo que no se debe considerar la idónea. Repito: un formulario podría ser suficiente en cuanto a prestaciones e incluso más funcional, al resultar menos costoso de construir. Los marcadores de texto y los cuadros de diálogo, por separado no constituyen novedad, pero sí la combinación de ambas técnicas, así como el código necesario para su funcionamiento.

Defiendo la necesidad de emplear marcadores por la escasa utilidad parece suponérseles o por mero desconocimiento, especialmente como recurso en documentos en los que es necesario cumplimentar información puntual a partir de un formato documental muy cerrado, similar en cuanto alternativa, a la utilidad de Combinar correspondencia, aunque ésta tiene la ventaja de contar con una base de datos como respaldo, lo que la hace útil para la generación masiva de documentos personalizados, pero no tanto para documentos como el presente, que no requiere producción masiva.

El hecho de que este documento pueda ser cumplimentado por varias personas hace que sea aun más atractivo el empleo de estrategias como la que propongo, sirviendo de paso como modelo para situaciones similares como la elaboración colaborativa de informes.

Partiendo de lo anterior, formularé en primer lugar la especificación de la supuesta demanda, para identificar el proceso a seguir según lo que podemos entender como aplicación (simplificada) de la lógica de diseño y desarrollo, incluyendo la de programación en sentido estricto. El output ha sido diseñado ya en la formulación del documento-base, por lo que los procesos anteriores hacen referencia al input y al procesamiento.

Especificación. Crear un soporte que permita el uso compartido pero diferenciado entre SEO y tutoría de un documento para la recogida de información de cara a solicitar la colaboración del ER para ACNEAE por parte de los SEO. La finalidad de esta solicitud es facilitar el uso de un instrumento que permita sistematizar el procedimiento de formulación de la citada demanda. A tal fin se ha elaborado un documento-modelo que se empleará como base para la elaboración del citado soporte (docap).

Fases del proceso

• Primera. Partiendo del documento-base (desarrollado a partir del documento-modelo original) introducir las marcas que sean necesarias para facilitar la automatizar la ubicación de la información. Comprobar el correcto funcionamiento de estas marcas.
• Segunda. Crear las interfaces necesarias, teniendo en cuenta el principio de simplicidad en el uso y la posible diferenciación entre al menos dos potenciales usuarios: OE y Tutor/a.
• Tercera. Generar el conjunto de rutinas, subrutinas y funciones que resulten necesarias para conectar el sistema de entrada (interfaces) con el procesamiento y elaboración de datos para generar la salida necesaria quede como resultado el correcto funcionamiento del docap.
• Cuarta. Comprobar el perfecto funcionamiento del conjunto y en diferentes condiciones de uso. En su caso, corregir los errores que se aprecien y abordar las mejoras que se consideren pertinentes.
• Quinta. Pilotar el empleo del docap en contextos reales de uso, recoger la información relevante sobre su funcionalidad e incorporar las mejoras que se aprecien necesarias.
• Sexta. Dar a conocer el docap como recurso para uso público mediante su inclusión en la página web del ER.

Esta formulación del proceso puede considerarse como teórica, por lo que me limitaré, por razones obvias, a desarrollarlo hasta la fase cuarta y en estos momentos me quedo con un primer desarrollo del docap que puede considerarse equivalente en funcionalidad y apariencia, a la que proporciona (en la práctica) el documento-base. 

Esto implica reconocer que podemos trabajar perfectamente con ese documento sin notar (aparentemente) ninguna diferencia respecto al docap, así que para quienes no estén interesados en ir un poco más allá de las formas y de las apariencias, y únicamente se preocupen por la funcionalidad, pueden quedarse perfecta y cómodamente con la citada formulación sin más preocupación.

Pero quienes sientan curiosidad e interés por profundizar en lo que aporta en realidad la formulación del documento como docap, diré que en realidad éste, aunque por ahora aun limitado, contiene un gran potencial de mejora  que, eso sí, hace falta explicar y evidenciar. De momento me limitaré a lo primero.

En efecto, utilizar un cuadro de diálogo como interfaz que concreta la fase de entrada (input) implica diferenciar esta fase de las subsiguientes (procesamiento y salida), lo que favorece que la fase output pueda desarrollarse de forma totalmente diferenciada en forma y contenido a lo que estamos acostumbrados. Esto se debe a que las formas de trabajo empleadas no diferencian input de output, resultando soluciones de compromiso entre ambos, posiblemente con predominio del input en cuanto a la forma y del output en cuanto al contenido. Un ejemplo de uso de la potencialidad que se deriva de esta diferenciación es su aplicación para la creación de informes de intervención a partir de cuestionarios, como por ejemplo, las entrevistas a familias o cuestionarios de observación

La segunda potencialidad que conlleva el algoritmo desarrollado tiene que ver con la potencial utilidad del uso de los marcadores de texto como referencias para la construcción de documentos. Y en principio se me ocurren dos líneas de desarrollo:

• La construcción de documentos en los que colaboran o participan varios profesionales de forma sucesiva (no simultánea) y con aportaciones diferenciadas y complementarias.
• Cumplimentar documentos personalizables basados en plantillas cuando no existe emisión masiva de documentos y el formato combinar correspondencia cuando no resulta pertinente.

Es posible ampliar el listado de potencialidades, incluyendo las resultantes de la combinación de ambas características, pero ya sería suficiente con desarrollar alguna de las citadas para comprobar que el esfuerzo de crear un docap basado en este algoritmo resulte "rentable". De ello me ocuparé en una próxima entrada.

De momento me contento con dejarte enlace a tres documentos en formato Writer que debes descargar:

• El [original del ER], para que lo tengas como referencia y por si te sirve de modelo y/o te es útil para el trabajo. Ten en cuenta que es el oficial del ER, al menos a la fecha de descarga (15/12/2022)
• El que llamé [documento-base], que no es otra cosa que la reformulación del anterior para ser utilizado mediante el procesador de texto. Su uso es tan simple que no requiere explicación alguna y no creo que utilizarlo suponga invalidar una posible demanda, así que lo puedes usar tranquilamente.
• Y el [formato docap] basado en el anterior aunque pero se cumplimenta mediante cuadros de diálogo (tres, uno por página) que se activan con botones de formulario (comandos asociados a script) visibles pero no imprimibles. Su funcionamiento se basa en el código asociado al que puedes acceder desde el IDE. Aunque el documento que te entrego no lo es, te propongo que crees una versión de trabajo de tipo plantilla y que trabajes desde este documento (desde las réplicas que se generan al hacer clic en la plantilla), de este modo no se alterarán los marcadores y no se corromperá el funcionamiento del algoritmo. 

NOTAS

(1) Lo que sí es relevante es que parezca preverse firma y sello manual. A falta de un recurso mejor aconsejo utilizar una firma digitalizada, así como también un sello de igual naturaleza. De este modo no es necesario el gasto de papel y puede ser enviado directamente por e-mail. No aprecio que exista motivo para que sea ineludible el tratamiento manual al que parece destinado este documento.

Evaluación. Autoconcepto.

Cuestionario CAG (2b)

Esta entrada finaliza la serie iniciada con la entrada publicada el 8 de abril y culmina la entrada Autoconcepto (2a) en la que presenté su primera parte. En ella ya anuncié que faltaba crear un cuestionario para aplicar CAG y a ello dedico la presente.

Cuestionarios y formularios en Calc

Los cuestionarios basados en Calc, creados únicamente con las funciones propias de este servicio, sin código (macros y/o script), suponen una ventaja evidente sobre los cuestionarios en papel:

• Ahorran material fungible (y gastos de fotocopiadora)
• Están siempre disponible, sin necesidad de intendencia ni organización, y son fácilmente reproducibles sin coste añadido.
• Unifican la aplicación con la corrección.
• Facilitan el análisis de los datos y la obtención de resultados de forma inmediata.
• Permiten crear informes modelo
• Y, opcionalmente, posibilitan la sustitución del papel por documentos informatizados en el expediente del alumnado, con la consiguiente mejora en su gestión y almacenamiento.

Pero cuando el cuestionario tiene un número elevado de ítem presenta también algunos inconvenientes que pueden hacer que las ventajas se queden en mera posibilidad. Suponiendo disponibilidad de medios informáticos...

• No resultan sencillos de manejar por parte del alumnado, que tiene que tener cierta experiencia en el uso de hojas de cálculo.
• Se pueden producir errores a la hora de realizar la lectura del ítem y la identificación de la línea de opciones de respuesta, dando lugar a errores de ubicación de la respuesta o de omisión.
• Las posibilidades de creación de informes individualizados tienen ciertos límites.

Primera alternativa

A corregir la última de las limitaciones dediqué la entrada precedente, pero aun disponemos de más posibilidades.

La primera de ellas es dividir el cuestionario en varias secciones, de modo que la relación entre pregunta y opciones de respuesta quede más claramente establecida, evitando así la segunda dificultad, que es la más peligrosa por sus consecuencias.

Sin abandonar la formulación de los ítem en base a las celdas, el primero de los docap (Docap2a)  puede considerarse una de las posibles soluciones.

No obstante aun no resulta del todo satisfactorio, ya que obliga a desplazarse por las celdas hasta ubicarse en la respuesta seleccionada, y eso multiplicado por el número de ítem a tratar.

A pesar de esas limitaciones me ha parecido conveniente aportar este docap por el tratamiento que conlleva al manejo de las hojas del libro Calc y por incorporar mecanismos de gestión y navegación por el documento, incluyendo el sistema de control de errores por dejar ítem sin contestar, como recordarás, una de las causas de invalidez del cuestionario que ya consideramos en su momento.

De hecho, el código necesario para este docap, continuación del precedente, lo amplía fundamentalmente por incorporación de código de navegación. LO encontrarás también en Documentos, como viene a ser habitual, en formato .txt.

Segunda alternativa

Podemos alejarnos aun más de la presentación del cuestionario en base a celdas y sustituir la presentación de las opciones de resta como control de un formulario. En eso se basa el segundo de los docap de esta entrada (Docap2b): tomando como base Docap2a, he procedido sustituido las opciones de respuesta sobre celda por controles Cuadro de lista, lo que mejora significativamente el procedimiento de trabajo para el alumnado. De hecho, aunque para los y las de menor edad sigue siendo cierta la necesidad de cierta práctica en el uso de formularios electrónicos, considero que con esta presentación se puede considerar que es posible sustituir el documento en papel por el propio docap, lo que facilita y agiliza mucho la aplicación individual y grupal del CAG.

El código

Y aquí es donde la flexibilidad de OOo Basic se manifiesta con nitidez: el código necesario para manejar Docap2b es el mismo que para manejar Docap2a, exactamente el mismo: puedes llamarlo indistintamente desde ambos docap, siempre y cuando lo hayas copiado previamente en el  módulo apropiado (ModCAG) dentro de la biblioteca Standard de Mis macros y diálogos.

Para los interesados e interesadas en cacharrear con el código, después de haber trabajado sobre el correspondiente al docap CAG_Docap1, aconsejo sustituirlo por el que te dejo ahora en Documentos.

Para cualquier duda o si se detectan errores de funcionamiento siempre queda la opción de informar en el propio blog vía Comentarios.

Me quedan cosas por comentar sobre el funcionamiento de ambos docap, pero tiempo habrá de hablar de ello.

Por ahora, de nuevo, gracias por tu interés.

Documentos

• Docap2a. Cuestionario basado en celdas. 
• Docap2b. Cuestionario basado en controles de formulario
• Código de docap. Sirve para los dos docap anteriores. Se debe ubicar en Mis macros y diálogos, sustituyendo al código de Docap1.