En algún sitio hemos dicho que toda aplicación puede responder a ciertos Apple Events muy básicos, como mínimo, aunque no sea en absoluto scriptable (o sea, que carece de un diccionario de comandos). Por ejemplo, la aplicación que viene (o venía) con el sistema «SimpleSound», no es en absoluto scriptable. Tú le hablas en AppleScript, pero él no entiende nada.
Pues bueno; a pesar de eso, aún puede comprender algunos comandos, como por ejemplo estos tres:
run
activate
quit
end tell
En principio, cualquier aplicación debe entender estos comandos (y algún otro por ahí), dado que es el sistema mismo quien se los envía a través de nosotros.
Este es el primer término de nuestro silogismo: «Toda aplicación entiende ciertos comandos».
El segundo término es: «Un script salvado como aplicación es una aplicación».
Y, para terminar, el tercero: «Por tanto, una aplicación de script entiende ciertos comandos».
Esto es «por defecto». Ahora bien, en el apartado de handlers (o subrutinas), hemos dicho que un handler es un auténtico comando creado por el usuario (yo, tú, él…). La palabra «handler», en inglés, viene a ser algo así como «guardian», pero en programación AppleScript, es un verbo sustantivado que hace referencia al verbo «handle», que significa «manejar».
O sea, que un «handler» es un «manejador de eventos». Quiere decirse que si yo llamo a mi handler «karakapullo», entonces puedo utilizar el mencionado «handler» como manejador del evento recién bautizado como «karakapullo».
Veamos el ejemplo:
on karakapullo()
display dialog «Tu padre»
end karakapullo
Bien. Tenemos una aplicación o script capaz de responder a este evento nuevo que hemos inventado, y podemos utilizarlo sin problemas desde dentro de nuestra aplicación (o script).
Ahora, por fin, se descorre el velo semi-transparente que da título a este apartado: también podemos utilizar este «comando» desde fuera de nuestra aplicación. ¿Cómo? Comiendo. Haciéndolo. Y, concretamente desde AppleScript, llamando al contenedor del comando (la aplicación o script) y utilizándolo sin más.
Cuando el «contenedor» del comando (o comandos) es una aplicación, entonces no hay problema. Se le trata como a una aplicación cualquiera, como hicimos más arriba con «SimpleSound»:
karakapullo()
end tell
Cuando el «contenedor» del comando es un script, entonces tenemos que «cargar» el script en memoria, y ya podemos utilizarlo igual que en el caso anterior (pero sin llamarlo «aplicación», porque no lo es).
set Script_Cargado to (load script el_script)
tell Script_Cargado
karakapullo()
end tell
En la primera línea hemos obtenido un «alias» del script (por ejemplo, alias «HD:Desktop Folder:script de ejemplo»), que es lo que necesitamos para cargar el script (en la segunda línea, con el comando «load script», de las Adiciones Estándar).
Y, una vez cargado, podemos llamarlo y utilizar sus comandos (el resto de líneas).
Muchas veces me habría gustado también que hubiera un comando llamado «unload script», para descargarlos de memoria, y creo que hasta puede que haya existido. Habitualmente no es necesario, ya que se utiliza para rutinas no demasiado «grandes», pero a veces sí se echa en falta cuando uno quiere cargar una «biblioteca de comandos» muy grande y, una vez utilizada, descargarla para que las cosas vayan más rápido, aunque puede que tal vez esto no sea tan útil como para ser tenido en cuenta por nadie, ya que las bibliotecas se «descargan» solas cuando termina de correr la aplicación que las cargó.
Como hemos visto, o veremos, o lo que sea, podemos ejecutar los «handler» contenidos en otros scripts y, por tanto, pasarles y devolverles parámetros. Un ejemplo sencillito:
dime_Algo(«kapullo»)
–> «y tu padre también»
end tell
Y el «Script_Cargado» contiene:
display dialog x
return «y tu padre también»
end dime_Algo
Cuando ejecutemos el original, enviaremos un parámetro cualquiera («kapullo», en este caso) y también recibiremos el resultado de ejecutar ese handler («y tu padre también»). Facilito.
Los restantes artículos sobe AppleScript se pueden encontrar en la categoría de Tutorial
