Date de mise à jour : 13 novembre 2016
la commande à distance d'Aud'ACE peut se faire via des programmes tels que VNC ou Teamviewer : l'opérateur agit directement sur l'interface comme s'il était devant le PC en utilisant son clavier et sa souris sans avoir à connaître le langage tcltk.
Dans le cas d'une connexion internet via un serveur, sans accès direct, l'utilisateur actionne des macrocommandes. Comment rédiger ces macrocommandes ? Cette aide apporte quelques éléments de réponse.
Les scripts sont une suite ordonnée de commandes placées dans des procédures tcl (les proc). Il en va de même pour l'exécution des commandes Tk permettant de gérer l'interface graphique entre l'utilisateur et Aud'ACE : il est donc possible d'écrire des scripts simulant des actions de l'utilisateur pour automatiser des séquences spécifiques, répétitives, pour gagner du temps et éviter des oublis, des erreurs.
Deux actions sont traitées ci-après :
Le menu comporte deux types de commandes très différentes :
Certains outils du menu sont permanents et ne peuvent être désactivés. L'appel d'un de ces outils se fait comme suit :
$menuPath invoke $menuIndex
| Appel des fonctions du menu | ||||
|---|---|---|---|---|
| nom du menu principal | Item du menu | variable mName | variable mLabel | Exemple de commande |
| Fichiers | Ouvrir | file | charger | catch { |
Les outils se présentent soient sous forme de panel (panneau latéral gauche) ou de window (fenêtre) associé à une visu (son numéro, 1 pour la visu principale).
Le nom de l'outil est son namespace.
Voici quelques commandes, intégrées dans ::confVisu, permettant de les actionner ou de connaître leur état :
| Information sur les outils d'une visu | |
|---|---|
| Nature | Commande |
| Retourne la liste des outils actifs de la visu | set tools [::confVisu::getToolList $visuNo] |
| Retourne la liste des outils visibles de la visu | set tools [::confVisu::getVisibleToolList $visuNo] |
| Retourne la liste des outils occupés dans la visu | set tools [::confVisu::getBusyToolList $visuNo] |
| Information et Action sur un outil particulier | |
|---|---|
| Information et Action | Commande |
| Retourne le N° de la visu contenant un outil ou rien | set visu [::confVisu::getToolVisuNo $toolName] |
| Indique si l'outil est prêt (1 = OK | 0 pas OK) | set state [::confVisu::isReady $visuNo $toolName] |
| Indique si l'outil est occupé (1 = oui | 0 non) | set state [::confVisu::isBusy $visuNo $toolName] |
| Ouvre un outil et retourne son nom | ::confVisu::selectTool $visuNo $toolName |
| Ouvre un panneau dans la visu principale ou dans une nouvelle visu s'il en existe un dans la visu principale et retourne son N° |
set visu [::confVisu::getToolVisuNoOrOpenToolNewVisuNo $toolName] |
| Masque le panneau courant | ::confVisu::hidePanelTool $visuNo |
| Ferme un outil | ::confVisu::stopTool $visuNo $toolName |
Ouvrir et fermer une fenêtre Tk est un minimum. Mais comment faire pour simuler une saisie ? la sélection d'une combobox ou celle d'un radiobutton ? le clic sur un bouton ?
Deux solutions sont praticables :
Les commandes Tk associées aux widgets permettent d'agir sur eux. Le tableau ci-dessous résume quelques commandes Tk disponibles pour les widgets :
| Commandes actionnant les widgets | ||
|---|---|---|
| Widget | Action | Commande |
| button | actionner le bouton | $buttonPath invoke |
| checkbutton | sélectionner un checkbutton | $buttonPath select |
| checkbutton | désélectionner un checkbutton | $buttonPath deselect |
| checkbutton | modifier l'état d'un checkbutton | $buttonPath toggle |
| radiobutton | désélectionner un radiobutton | $buttonPath select |
| entry | saisir un texte (à l'indice 0) | $entryPath insert 0 $value |
| combobox | sélectionner l'argument à l'index | $comboPath setvalue @$index |
| notebook | sélectionner un onglet de nom "$name" | $notebookPath raise "$name" |
Comme le montre le tableau il faut toujours identifier le chemin (xxxPath) du widget donc il faut plonger dans le code du script et examiner de près les commandes spécifiques du widget concerné.
Une autre solution consiste à repérer la proc lancée par un bouton et à l'appeler directement avec tous les (bons) paramètres. Dans certains cas il faut au préalable spécifier les valeurs des variables utilisées en interne dans la proc.
Il est prudent d'examiner les conséquences d'une erreur éventuelle dans un paramètre et de mettre en place des messages d'erreur exploitables ; un essai est toujours indispensable.
Si les commandes d'entré sont toujours des commandes TclTk ; les informations retournées doivent être au format exploité par le serveur (tcl, json, etc.).