Re: Script Debugger & 1.0.8 disponible

Après mûre réflexion, le 28 février 2022 à 12:25, Joseph-B eu l'idée
d'écrire :

"Benoît L." <benoit@leraillez.com.invalid> wrote:
>

Puisque je vise le développement d'une appli*, ne serait-il pas
intéressant, à terme, de faire un script par routine ?
 
Je pose la question parce que dans ce cas on a un script principal
« léger » facile à lire et pas des « tonnes » de lignes au milieu
desquelles on se promène à la recherche de l'erreur.

>
L'idée que tu émets de structurer une "appli" en différents scripts qui
seront appelés en cas de besoin par le handler principal s'applique déjà
et en premier au handler maître.
>
Quand tu as une succession de lignes de commandes, effectuant une action
ou retournant une valeur, susceptible de constituer une routine à part
entière, crée-la en lui donnant un nom et des paramètres, ce qui permet
ensuite de l'appeler depuis n'importe où, et autant de fois que
nécessaire, depuis le handler maître.

C’est exactement pourquoi je l’ai fait. Cela permet aussi de vraiment
séparer le code en éléments auxquels on ne touche plus une fois
« validés ».

D'ailleurs, de la même manière cette routine pourra appeler une ou
plusieurs sous-routines construites sur le même principe. (toutefois,
attention de ne pas trop saucissonner les routines, pour ne pas les
rendre incompréhensibles à leur tour).

Je suis déjà tombé dedans, mais juste un étage au-dessus du rdc.

Au niveau de la modestie (sans offense de ma part) en terme de volume de
lignes de code du projet auquel tu t'attaques, nul besoin d'enregistrer
une sous-routine dans un script indépendant qu'il faudra aller
positionner dans un dossier "Libraries" du dossier "Resources" de
l'application.*

Je l’avais deviné en créant un :
tell application "Finder" to set pathToMe to (container of (path to me))
as text
Mais je ne l’utilise pas pour le moment.

Par commodité de lecture, en général on sépare le handler maître des
sous-routines positionnées en dessous par une barre de commentaire.
Mais c'est purement conventionnel et selon l'idée que l'on se fait du
pratique de la chose.
[…]
*Néanmoins, si tu y tiens essentiellement, une explication de la méthode
ici.
<https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/UseScriptLibraries.html>
>
ou cette série d'articles, qui bien qu'à but de vulgarisation, me paraît
plus "confusionnante"
<https://macosxautomation.com/mavericks/libraries/index.html>
et une mise en exemple
<https://macosxautomation.com/mavericks/libraries/simple.html>

Je garde ça pour plus tard. Merci,


En attendant, voici la 1.0.8 avec laquelle je ne trouve pas de problèmes
(étonnant, non ?)
<https://www.cjoint.com/data/LBCr6YfpxAt_SignAuPif-1.0.8.zip>
L’appli et le script pour ceux qui ne veulent pas chercher dans l’appli.
(mon premier avec Script Debugger qui, comme son nom l’indique, est le
rêve pour qui veut débugué)

Nouveautés :
— On peut remplacer le fichier de signature quand on le souhaite ;
— Le tirage au sort ne permet plus de revoir une signature tant que
toutes les autres n’ont pas été présentées ;
— Des raccourcis clavier. Mais le bouton « Copier » n’a pas de raccourci
affiché. La raison est que si on clique sur le bouton on copie le texte
d’origine et cela ne tient pas compte de modification ou de sélection de
texte, alors que le cmd-c est préempté par le système et copie
uniquement la sélection. (Mes tentatives de system event et keystrokes
ont, pour l’instant, échouées.)


P.S. Je n’arrive pas à avoir de problème quoi que je fasse. Cela étant,
je suis sûr que tu sauras en dénicher. :)

Prochaine étape (je l’espère) pouvoir saisir des signatures, les
modifier… Et rédiger un read me.

--
C'est pas parce qu'on a rien à dire qu'il faut fermer sa gueule.
-+- Audiard dans « La Grande Luciole avec une chaussure noire » -+-