Caravantes
20/12/13, 18:52:40
Dentro de una tarea, algunas veces tenemos grupos de acciones que realizan una labor concreta y bien definida. En ese caso, puede ser buena idea pasar ese conjunto de acciones a una tarea independiente que pueda ser invocada (lanzada) desde la tarea principal. De este modo creamos una tarea “secundaria” que funcionará como una subtarea de la tarea principal. Esto es especialmente ventajoso en el caso de que ese conjunto de acciones deban realizarse en varias tareas principales.
Crear subtareas de este tipo aporta tres ventajas concretas: 1) Resulta muy fácil integrarlo con otra tarea que ya tengas o que construyas de forma independiente y en esa tarea principal no tienes que preocuparte por esos detalles que ya están resueltos de forma independiente en la subtarea. 2) La misma subtarea puede ser utilizada por varias tareas principales, sin que aumente el volumen de código en ellas. 3) El mantenimiento y optimización de la subtarea se hace en un solo sitio, y esas mejoras se aplican automáticamente a todas las tareas principales que utilicen los resultados de la subtarea.
En un comentario posterior (que podéis ver más abajo) el compañero Mlesir apunta otras dos ventajas que yo no había pensado. La primera es que algunas acciones pueden fallar y detener la tarea en la que se están ejecutando; si esa acción está en una subtarea, la tarea principal podrá continuar funcionando a pesar de la acción fallida. La segunda ventaja es similar, pero deliberada: en algunas circunstancias nos puede interesar detener la subtarea y -nuevamente- la tarea principal continuará funcionando.
Hay subtareas muy sencillas que simplemente hacen una serie de cosas, siempre de la misma forma. Así, por ejemplo, yo tengo una subtarea que establece todos los ajustes que me interesan (enciende el GPS y el Bluetooth, ajusta el volumen, etc). Tengo un widget para activar manualmente esta tarea en momentos concretos como por ejemplo al salir del cine. Pero la misma tarea es invocada automáticamente cuando desconecto el cargador de batería. Esto funciona porque la tarea asociada al cargador tiene una acción EJECUTAR-TAREA (del grupo TAREA) que activa la subtarea de los ajustes. Además, cada vez que reinicio el smartphone también se activa una tarea que incluye la misma acción EJECUTAR-TAREA para invocar a esa subtarea de ajustes, y de esta forma me aseguro de que tengo todos los ajustes como me gusta tras cada recarga de batería o tras cada reinicio.
También hay subtareas que reciben información de entrada y devuelven información de salida hacia la tarea principal. Esto es bastante más complejo y ahora vamos a ver con cierto detalle la forma en que se comunican.
Las tareas y subtareas no se transmiten la información por variables “compartidas”, sino de un modo más directo. En la acción EJECUTAR-TAREA se puede especificar cuáles parámetros (máximo dos) hay que pasarle a la subtarea. En la configuración de esa acción hay dos casillas para poner los parámetros (parámetro1 y parámetro2). Lo más frecuente es que esos parámetros sean en variables de la tarea principal, aunque también podrían ser parámetros fijos (textos fijos) o una mezcla de ambas cosas (texto/s y variable/s).
Los parámetros no son obligatorios, puede haber subtareas que se ejecutan siempre del mismo modo, sin ninguna información de entrada (o mejor dicho: ignorando la posible información de entrada). En otras subtareas puede haber parámetros (uno o dos) que son imprescindibles porque la subtarea no funcionará bien si no se han recibido esos parámetros. Por último puede haber subtareas con parámetros opcionales: la tarea utiliza un valor o texto por defecto, salvo que se reciba otra información como parámetro.
La subtarea o tarea subordinada recibe esos parámetros siempre como variables, y siempre con los nombres %par1 y %par2. O sea que DENTRO de la subtarea hay que usar las variables %par1 y %par2 para hacer referencia a los parámetros recibidos de la tarea principal y eso es totalmente independiente de que la tarea principal utilice esos mismos nombres de variable u otros (o textos fijos).
Luego, la subtarea hará lo que tenga que hacer y tal vez ocurra que finalmente la subtarea genera una información que debe ser devuelta a la tarea principal. Hay subtareas que siempre van a devolver algo y también puede haber subtareas que devuelven algo "si todo ha ido bien" y no devuelven nada si "algo ha fallado" (y por ese fallo fue imposible obtener la información que se buscaba). La forma de retornar esa información desde la subtarea a la tarea principal se hace poniendo en la subtarea una acción DEVOLVER (del grupo TAREA). En esa acción DEVOLVER se indica cuál información hay que retornar a la tarea principal; igualmente se pueden usar variables, textos fijos o cualquier combinación de ambos. Pero aquí solo se devuelve UNA cosa (una subtarea puede recibir hasta DOS parámetros de entrada, pero solo devuelve UNA información de salida). La configuración de la acción DEVOLVER incluye una opción PARAR que podemos activar si queremos que la subtarea sea detenida justo después de haber devuelto la información a la tarea principal.
Habíamos dejado la tarea principal en la acción EJECUTAR-TAREA. Pues bien, en la configuración de esa acción también hay una casilla rotulada como DEVOLVER VALOR DE VARIABLE que sirve para especificar cuál es la variable que recogerá la información devuelta por la subtarea. En las acciones siguientes se puede usar esa variable que contiene la información aportada por la subtarea.
Todas estas variables pueden ser variables locales, y en tal caso serán independientes dentro de cada tarea, sin importar que otras tareas (y/o subtareas) tengan variables locales con nombres idénticos, pues las variables locales solo son tenidas en cuenta “dentro” de su propia tarea (y por eso se llaman “locales”). O sea que es indistinto usar en la tarea principal una variable que se llame %par1 o de cualquier otra forma; y lo mismo puede aplicarse a la información retornada, pues en la tarea y en la subtarea se puede usar el mismo nombre de variable o un nombre distinto, eso no influye.
Por supuesto, cualquier tarea o subtarea puede usar variables Globales (con alguna letra mayúscula en su nombre) y esas variables Globales sí son compartidas por todas las tareas de Tasker, e incluso mantienen su valor cuando las tareas han finalizado. Así, las variables Globales son otro recurso para transmitir información de unas tareas a otras, pero solo deben usarse cuando sea imprescindible, para no acumular variables Globlales más allá de lo necesario; en caso contrario acaban siendo un estorbo.
Otro detalle importante es que la configuración de EJECUTAR-TAREA nos permite activar una casilla PARAR con la que hay que tener cuidado porque esa casilla detiene la tarea principal, pero lo hace de forma definitiva y permanente; si se activa esa casilla, las siguientes acciones de la tarea principal no serán ejecutadas nunca, ni siquiera cuando haya finalizado la subtarea. De lo cual se deduce que -normalmente- es preferible no activar esa casilla, para que la tarea principal también siga ejecutándose, pero hay que saber cómo se van a alternar las dos tareas.
Si la subtarea y la tarea principal tienen la misma prioridad, ambas se ejecutarán en paralelo por turnos, una acción de cada una. Si tienen distinta prioridad, la de menor prioridad será la que quedará en espera hasta que la otra finalice. En la configuración de EJECUTAR-TAREA podemos especificar la prioridad que le damos a la subtarea (de 0 a 50). Lo más habitual es asignar a la subtarea una prioridad mayor para que la tarea principal continúe su ejecución cuando la subtarea ya haya completado todas sus acciones.
En cualquier tarea puedes usar la variable %priority que contiene la prioridad de la propia tarea. Por defecto, la acción EJECUTAR-TAREA pone en la prioridad de la subtarea la variable %priority, de forma que asigna a la subtarea la misma prioridad que tiene la tarea principal. Pero si quieres que la subtarea se ejecute primero, le puedes añadir un punto (%priority + 1) y de este modo sabes que la subtarea tendrá una prioridad un punto más alta que la tarea principal. Por el contrario, si quieres que la tarea principal se ejecute primero, le puedes asignar a la subtarea un punto menos (%priority - 1).
En este sentido, quizá nos interese conocer o modificar la prioridad de la tarea principal, del siguiente modo: las tareas asociadas a un perfil (como tareas de entrada o de salida) se ejecutan con la misma prioridad que el perfil correspondiente, y es posible ver o modificar esa prioridad en las propiedades del perfil; la prioridad de las tareas ejecutadas por un widget o acceso-directo puede ser establecida en la configuración de Tasker (Preferencias / Acción).
Puede haber dudas respecto a que una subtaea ya se esté ejecutando, con lo cual tal vez no conviene volver a lanzarla. A este respecto conviene tener en cuenta dos detalles:
A) Que la variable %TRUN contiene una lista con el nombre de todas las tareas que se están ejecutando (nombres separados por comas, incluyendo coma inicial y coma final, de forma similar a la variable %PACTIVE). Si quieres saber si la subtarea BBB se está ejecutando, la condición es
%TRUN ~ *,BBB,*
(Esto es válido para cualquier tarea, no solo para subtareas.)
B) En las propiedades de la propia subTarea se puede establecer el manejo de incompatibilidades en el caso de que una (sub)Tarea pueda ser lanzada mientras todavía hay en marcha una ejecución previa de la misma tarea. Se puede elegir: abortar la tarea previa, abortar la nueva tarea o ejecutar ambas a la vez (esto es igual para las tareas principales y las subtareas).
Más comentarios sobre estos temas de prioridades y coordinación entre tareas, en:
http://www.htcmania.com/showthread.php?p=11796544
http://www.htcmania.com/showthread.php?t=1188002
Hay otro asunto curioso que debemos tener en cuenta: las modificaciones en una tarea (o subtarea) no son "Globales" hasta cerrar la sesión de trabajo. Esto significa que mientras tienes el Tasker abierto y estás modificando una tarea o varias, cada una de esas tareas aplicará localmente los cambios que hagas en sus propias acciones, pero ninguna tarea reconocerá los cambios hechos a otras tareas (ni la aparición de tareas nuevas) porque esas novedades todavía no se han hecho "Globales". Salir de Tasker (pulsando varias veces en el botón de volver atrás) es un paso crucial para que la creación o modificación de una tarea pueda ser utilizada por otra tarea. Y esto es algo fundamental cuando se trata de subtareas que van a ser utilizadas por tareas principales. Por ejemplo, si estás en una sesión de Tasker y creas una tarea, no podrá ser utilizada como una subtarea hasta cerrar la sesión (o salir de Tasker). Este comportamiento tan curioso es algo que he aprendido en la práctica tras dar muchos tropiezos. He buscado en la documentación de Tasker (en español) y no hay ninguna referencia a ello, pero ya digo que es algo que tengo bien comprobado y que os invito a verificar.
Otra cuestión añadida posteriormente: Los ajustes realizados por una tarea de entrada son automáticamente revertidos cuando el perfil deja de estar activo. Pero si la tarea de entrada lanza una subtarea, los ajustes de la subtarea no son revertidos. O sea que puedes utilizar una subtarea si prefieres que los ajustes sean mantenidos después de que el perfil deje de estar activo.
Veamos un ejemplo sencillo de tarea principal y subtarea:
Alfa (tarea principal)
A1: Establecer variable %uno a Pinocho
A2: Ejecutar tarea Beta, Prioridad 10, Parametro1 %uno, Devolver variable %dos
A3: Flash %dos
Beta (subtarea)
A1: Establecer variable %tres a hoy es %DAYW
A1: Devolver %par1 dice que %tres
Al ejecutar la tarea Alfa (tras salir de Tasker y volver a entrar) deberíamos obtener un flash con el texto “Pinocho dice que hoy es lunes”, frase que está compuesta por la subtarea pero que es mostrada (flash) por la tarea principal.
Hay ejemplos reales de tareas y subtareas en los enlaces siguientes:
http://www.htcmania.com/showpost.php?p=11594637
http://www.htcmania.com/showpost.php?p=11696058
La documentación dice que no hay ningún problema en anidar subtareas que dependen de otras subtareas, en tantos niveles como se quiera. Yo solo he probado un nivel de anidamiento (tarea principal - subtarea de primer nivel - subtaera de segundo nivel) y funciona sin problemas.
Sin recurrir a las variables Globales hay otro truco para transmitir varias informaciones (más de dos hacia la subtarea, o más de una de retorno). Consiste en agrupar varias informaciones utilizando algún separador específico que luego nos permita volver a desmontar las piezas del conjunto. Por ejemplo, yo tengo una subtarea que envía un mensaje de correo electrónico. Las tareas principales tienen cuatro datos que deben transmitir a la subtarea, dos de ellos en variables y otros dos como textos fijos (distintos en cada tarea principal). Pongamos por caso que los datos son
%titulo
#Telefono (texto fijo)
imagensms.jpg (texto fijo)
%cuerpo
La tarea principal agrupa esos cuatro datos dentro del parámetro1 para transmitirlos todos juntos, al estilo siguiente:
%titulo;#Telefono;imagensms.jpg;%cuerpo
En una situación concreta, eso puede ser algo como
SMS recibido de Paco;#Telefono;imagensms.jpg;texto:Este finde no trabajo, si quieres nos vemos
La subtarea utiliza una acción SEPARAR VARIABLE %par1 usando un punto y coma como separador, y así obtiene cuatro sub-variables:
%par11: SMS recibido de Paco
%par12: #Telefono
%par13: imagensms.jpg
%par14: texto: Este finde no trabajo, si quieres nos vemos
La subtarea utiliza estos datos independientes para enviar el mensaje de correo con su título, su cuerpo, su fichero adjunto, etc.
De forma parecida se podrían retornar varios datos desde una subtarea a la tarea principal. Basta con que una y otra estén de acuerdo en cuál es el carácter separador, y hay que asegurarse de que ese carácter separador no formará parte de ninguno de los datos a transmitir, como es lógico.
Crear subtareas de este tipo aporta tres ventajas concretas: 1) Resulta muy fácil integrarlo con otra tarea que ya tengas o que construyas de forma independiente y en esa tarea principal no tienes que preocuparte por esos detalles que ya están resueltos de forma independiente en la subtarea. 2) La misma subtarea puede ser utilizada por varias tareas principales, sin que aumente el volumen de código en ellas. 3) El mantenimiento y optimización de la subtarea se hace en un solo sitio, y esas mejoras se aplican automáticamente a todas las tareas principales que utilicen los resultados de la subtarea.
En un comentario posterior (que podéis ver más abajo) el compañero Mlesir apunta otras dos ventajas que yo no había pensado. La primera es que algunas acciones pueden fallar y detener la tarea en la que se están ejecutando; si esa acción está en una subtarea, la tarea principal podrá continuar funcionando a pesar de la acción fallida. La segunda ventaja es similar, pero deliberada: en algunas circunstancias nos puede interesar detener la subtarea y -nuevamente- la tarea principal continuará funcionando.
Hay subtareas muy sencillas que simplemente hacen una serie de cosas, siempre de la misma forma. Así, por ejemplo, yo tengo una subtarea que establece todos los ajustes que me interesan (enciende el GPS y el Bluetooth, ajusta el volumen, etc). Tengo un widget para activar manualmente esta tarea en momentos concretos como por ejemplo al salir del cine. Pero la misma tarea es invocada automáticamente cuando desconecto el cargador de batería. Esto funciona porque la tarea asociada al cargador tiene una acción EJECUTAR-TAREA (del grupo TAREA) que activa la subtarea de los ajustes. Además, cada vez que reinicio el smartphone también se activa una tarea que incluye la misma acción EJECUTAR-TAREA para invocar a esa subtarea de ajustes, y de esta forma me aseguro de que tengo todos los ajustes como me gusta tras cada recarga de batería o tras cada reinicio.
También hay subtareas que reciben información de entrada y devuelven información de salida hacia la tarea principal. Esto es bastante más complejo y ahora vamos a ver con cierto detalle la forma en que se comunican.
Las tareas y subtareas no se transmiten la información por variables “compartidas”, sino de un modo más directo. En la acción EJECUTAR-TAREA se puede especificar cuáles parámetros (máximo dos) hay que pasarle a la subtarea. En la configuración de esa acción hay dos casillas para poner los parámetros (parámetro1 y parámetro2). Lo más frecuente es que esos parámetros sean en variables de la tarea principal, aunque también podrían ser parámetros fijos (textos fijos) o una mezcla de ambas cosas (texto/s y variable/s).
Los parámetros no son obligatorios, puede haber subtareas que se ejecutan siempre del mismo modo, sin ninguna información de entrada (o mejor dicho: ignorando la posible información de entrada). En otras subtareas puede haber parámetros (uno o dos) que son imprescindibles porque la subtarea no funcionará bien si no se han recibido esos parámetros. Por último puede haber subtareas con parámetros opcionales: la tarea utiliza un valor o texto por defecto, salvo que se reciba otra información como parámetro.
La subtarea o tarea subordinada recibe esos parámetros siempre como variables, y siempre con los nombres %par1 y %par2. O sea que DENTRO de la subtarea hay que usar las variables %par1 y %par2 para hacer referencia a los parámetros recibidos de la tarea principal y eso es totalmente independiente de que la tarea principal utilice esos mismos nombres de variable u otros (o textos fijos).
Luego, la subtarea hará lo que tenga que hacer y tal vez ocurra que finalmente la subtarea genera una información que debe ser devuelta a la tarea principal. Hay subtareas que siempre van a devolver algo y también puede haber subtareas que devuelven algo "si todo ha ido bien" y no devuelven nada si "algo ha fallado" (y por ese fallo fue imposible obtener la información que se buscaba). La forma de retornar esa información desde la subtarea a la tarea principal se hace poniendo en la subtarea una acción DEVOLVER (del grupo TAREA). En esa acción DEVOLVER se indica cuál información hay que retornar a la tarea principal; igualmente se pueden usar variables, textos fijos o cualquier combinación de ambos. Pero aquí solo se devuelve UNA cosa (una subtarea puede recibir hasta DOS parámetros de entrada, pero solo devuelve UNA información de salida). La configuración de la acción DEVOLVER incluye una opción PARAR que podemos activar si queremos que la subtarea sea detenida justo después de haber devuelto la información a la tarea principal.
Habíamos dejado la tarea principal en la acción EJECUTAR-TAREA. Pues bien, en la configuración de esa acción también hay una casilla rotulada como DEVOLVER VALOR DE VARIABLE que sirve para especificar cuál es la variable que recogerá la información devuelta por la subtarea. En las acciones siguientes se puede usar esa variable que contiene la información aportada por la subtarea.
Todas estas variables pueden ser variables locales, y en tal caso serán independientes dentro de cada tarea, sin importar que otras tareas (y/o subtareas) tengan variables locales con nombres idénticos, pues las variables locales solo son tenidas en cuenta “dentro” de su propia tarea (y por eso se llaman “locales”). O sea que es indistinto usar en la tarea principal una variable que se llame %par1 o de cualquier otra forma; y lo mismo puede aplicarse a la información retornada, pues en la tarea y en la subtarea se puede usar el mismo nombre de variable o un nombre distinto, eso no influye.
Por supuesto, cualquier tarea o subtarea puede usar variables Globales (con alguna letra mayúscula en su nombre) y esas variables Globales sí son compartidas por todas las tareas de Tasker, e incluso mantienen su valor cuando las tareas han finalizado. Así, las variables Globales son otro recurso para transmitir información de unas tareas a otras, pero solo deben usarse cuando sea imprescindible, para no acumular variables Globlales más allá de lo necesario; en caso contrario acaban siendo un estorbo.
Otro detalle importante es que la configuración de EJECUTAR-TAREA nos permite activar una casilla PARAR con la que hay que tener cuidado porque esa casilla detiene la tarea principal, pero lo hace de forma definitiva y permanente; si se activa esa casilla, las siguientes acciones de la tarea principal no serán ejecutadas nunca, ni siquiera cuando haya finalizado la subtarea. De lo cual se deduce que -normalmente- es preferible no activar esa casilla, para que la tarea principal también siga ejecutándose, pero hay que saber cómo se van a alternar las dos tareas.
Si la subtarea y la tarea principal tienen la misma prioridad, ambas se ejecutarán en paralelo por turnos, una acción de cada una. Si tienen distinta prioridad, la de menor prioridad será la que quedará en espera hasta que la otra finalice. En la configuración de EJECUTAR-TAREA podemos especificar la prioridad que le damos a la subtarea (de 0 a 50). Lo más habitual es asignar a la subtarea una prioridad mayor para que la tarea principal continúe su ejecución cuando la subtarea ya haya completado todas sus acciones.
En cualquier tarea puedes usar la variable %priority que contiene la prioridad de la propia tarea. Por defecto, la acción EJECUTAR-TAREA pone en la prioridad de la subtarea la variable %priority, de forma que asigna a la subtarea la misma prioridad que tiene la tarea principal. Pero si quieres que la subtarea se ejecute primero, le puedes añadir un punto (%priority + 1) y de este modo sabes que la subtarea tendrá una prioridad un punto más alta que la tarea principal. Por el contrario, si quieres que la tarea principal se ejecute primero, le puedes asignar a la subtarea un punto menos (%priority - 1).
En este sentido, quizá nos interese conocer o modificar la prioridad de la tarea principal, del siguiente modo: las tareas asociadas a un perfil (como tareas de entrada o de salida) se ejecutan con la misma prioridad que el perfil correspondiente, y es posible ver o modificar esa prioridad en las propiedades del perfil; la prioridad de las tareas ejecutadas por un widget o acceso-directo puede ser establecida en la configuración de Tasker (Preferencias / Acción).
Puede haber dudas respecto a que una subtaea ya se esté ejecutando, con lo cual tal vez no conviene volver a lanzarla. A este respecto conviene tener en cuenta dos detalles:
A) Que la variable %TRUN contiene una lista con el nombre de todas las tareas que se están ejecutando (nombres separados por comas, incluyendo coma inicial y coma final, de forma similar a la variable %PACTIVE). Si quieres saber si la subtarea BBB se está ejecutando, la condición es
%TRUN ~ *,BBB,*
(Esto es válido para cualquier tarea, no solo para subtareas.)
B) En las propiedades de la propia subTarea se puede establecer el manejo de incompatibilidades en el caso de que una (sub)Tarea pueda ser lanzada mientras todavía hay en marcha una ejecución previa de la misma tarea. Se puede elegir: abortar la tarea previa, abortar la nueva tarea o ejecutar ambas a la vez (esto es igual para las tareas principales y las subtareas).
Más comentarios sobre estos temas de prioridades y coordinación entre tareas, en:
http://www.htcmania.com/showthread.php?p=11796544
http://www.htcmania.com/showthread.php?t=1188002
Hay otro asunto curioso que debemos tener en cuenta: las modificaciones en una tarea (o subtarea) no son "Globales" hasta cerrar la sesión de trabajo. Esto significa que mientras tienes el Tasker abierto y estás modificando una tarea o varias, cada una de esas tareas aplicará localmente los cambios que hagas en sus propias acciones, pero ninguna tarea reconocerá los cambios hechos a otras tareas (ni la aparición de tareas nuevas) porque esas novedades todavía no se han hecho "Globales". Salir de Tasker (pulsando varias veces en el botón de volver atrás) es un paso crucial para que la creación o modificación de una tarea pueda ser utilizada por otra tarea. Y esto es algo fundamental cuando se trata de subtareas que van a ser utilizadas por tareas principales. Por ejemplo, si estás en una sesión de Tasker y creas una tarea, no podrá ser utilizada como una subtarea hasta cerrar la sesión (o salir de Tasker). Este comportamiento tan curioso es algo que he aprendido en la práctica tras dar muchos tropiezos. He buscado en la documentación de Tasker (en español) y no hay ninguna referencia a ello, pero ya digo que es algo que tengo bien comprobado y que os invito a verificar.
Otra cuestión añadida posteriormente: Los ajustes realizados por una tarea de entrada son automáticamente revertidos cuando el perfil deja de estar activo. Pero si la tarea de entrada lanza una subtarea, los ajustes de la subtarea no son revertidos. O sea que puedes utilizar una subtarea si prefieres que los ajustes sean mantenidos después de que el perfil deje de estar activo.
Veamos un ejemplo sencillo de tarea principal y subtarea:
Alfa (tarea principal)
A1: Establecer variable %uno a Pinocho
A2: Ejecutar tarea Beta, Prioridad 10, Parametro1 %uno, Devolver variable %dos
A3: Flash %dos
Beta (subtarea)
A1: Establecer variable %tres a hoy es %DAYW
A1: Devolver %par1 dice que %tres
Al ejecutar la tarea Alfa (tras salir de Tasker y volver a entrar) deberíamos obtener un flash con el texto “Pinocho dice que hoy es lunes”, frase que está compuesta por la subtarea pero que es mostrada (flash) por la tarea principal.
Hay ejemplos reales de tareas y subtareas en los enlaces siguientes:
http://www.htcmania.com/showpost.php?p=11594637
http://www.htcmania.com/showpost.php?p=11696058
La documentación dice que no hay ningún problema en anidar subtareas que dependen de otras subtareas, en tantos niveles como se quiera. Yo solo he probado un nivel de anidamiento (tarea principal - subtarea de primer nivel - subtaera de segundo nivel) y funciona sin problemas.
Sin recurrir a las variables Globales hay otro truco para transmitir varias informaciones (más de dos hacia la subtarea, o más de una de retorno). Consiste en agrupar varias informaciones utilizando algún separador específico que luego nos permita volver a desmontar las piezas del conjunto. Por ejemplo, yo tengo una subtarea que envía un mensaje de correo electrónico. Las tareas principales tienen cuatro datos que deben transmitir a la subtarea, dos de ellos en variables y otros dos como textos fijos (distintos en cada tarea principal). Pongamos por caso que los datos son
%titulo
#Telefono (texto fijo)
imagensms.jpg (texto fijo)
%cuerpo
La tarea principal agrupa esos cuatro datos dentro del parámetro1 para transmitirlos todos juntos, al estilo siguiente:
%titulo;#Telefono;imagensms.jpg;%cuerpo
En una situación concreta, eso puede ser algo como
SMS recibido de Paco;#Telefono;imagensms.jpg;texto:Este finde no trabajo, si quieres nos vemos
La subtarea utiliza una acción SEPARAR VARIABLE %par1 usando un punto y coma como separador, y así obtiene cuatro sub-variables:
%par11: SMS recibido de Paco
%par12: #Telefono
%par13: imagensms.jpg
%par14: texto: Este finde no trabajo, si quieres nos vemos
La subtarea utiliza estos datos independientes para enviar el mensaje de correo con su título, su cuerpo, su fichero adjunto, etc.
De forma parecida se podrían retornar varios datos desde una subtarea a la tarea principal. Basta con que una y otra estén de acuerdo en cuál es el carácter separador, y hay que asegurarse de que ese carácter separador no formará parte de ninguno de los datos a transmitir, como es lógico.