Le modèle d'objet CHOIX
Comme le modèle ACCES, le modèle CHOIX complète les fonctionnalités du modèle SCRITERE par les automatismes composants et par un certain nombre de méthodes normalisées. Il diffère du modèle ACCES par son rôle qui est de permettre à l'utilisateur la recherche, puis la sélection d'un enregistrement précis. La sélection provoque la sortie de l'objet et rend le choix effectué à l'objet appelant.
Rappels :
- Les automatismes composants sont pris en charge par le système dès lors que les conventions de la programmation composant sont respectées.
- Les méthodes normalisées ont pour objectif de rendre l'interface utilisateur homogène quel que soit le logiciel utilisé. Dans le cas du modèle CHOIX, le résultat rendu à l'objet appelant est standardisé. Le modèle permet également l'accès à l'objet GESTION du composant.
Liste des déclarations standards
| BASE | Base de données | ||
TABLE |
Table principale |
||
| ECRAN | Ecran | ||
MENU |
Menu déroulant et barre d'outils. Par défaut, choix.key |
Liste des paramètres
| Chaine | Reference | pident | Identifiant de l'enregistrement choisi par l'utilisateur | |
| Entier | Reference | erreur | Code de retour |
Liste des variables héritées et contexte de table
| Chaine | CodeListe | Code de la liste (par défaut "LST") | ||
| Chaine | CodeClassement | Critère de classement de la liste | ||
| Contexte | LISTEINDEX | Contexte sur les champs indexés de la table |
Liste des méthodes héritées de SCRITERE
| REMPLIT_CLASSEMENT | Met en mémoire la liste des champs indexés | ||
ANALYSE_ECRAN |
Analyse les extensions de l'écran | ||
| AJOUTE_CRITERE | Ajout par programme d'un critère | ||
ANALYSE_SAISIE |
Analyse de l'action de l'utilisateur | ||
ACTIVE_REQUETE |
Positionne les filtres sur la table principale | ||
COMPARE_REQUETE |
Compare les critères pour optimiser | ||
POSITIONNE_REQUETE |
Positionne la liste avant réaffichage | ||
ACTIVE_REQUETE_DEFINITIVE |
Transmet les filtres vers un autre objet |
Liste des méthodes spécialisées
| VALIDATION | Clic sur le bouton "Valider" (ou touche Entrée) | ||
ABANDON |
Clic sur le bouton "Annuler" (ou touches F3 ou Echap) | ||
| AUCUN | Clic sur le bouton "Aucun" | ||
| GERER | Appel à l'objet GESTION du composant | ||
<CodeListe>_CHOIX |
Double-clic dans la liste |
Fonctionnement du modèle
En général l'objet CHOIX est appelé depuis la méthode CHOIX de l'interface du composant.
CHOIX dérive du modèle SCRITERE qui est conçu pour faciliter la recherche d'informations. L'interface utilisateur est en général constituée d'un bandeau contenant des critères de recherche et d'une liste affichant les enregistrements de la table principale. Les points forts du modèle sont les suivants :
- L'ergonomie du modèle est particulièrement intuitive pour l'utilisateur
- La programmation est très simple et bénéficie des automatismes composants
- Les critères de filtre sont déduits directement de l'écran
- La simple modification de l'écran permet d'ajouter de nouveaux critères de recherche
Exemple : écran de choix d'un modèle de tarif.
Les déclarations standards du modèle
BASE et TABLE :
Ces déclarations sont indispensables, elles définissent la table principale sur laquelle seront posés les filtres déduits de l'écran. Notez cependant que nous préconisons dans le cas d'une programmation composant de déclarer la base au niveau des déclarations globales du composant.
ECRAN et MENU :
L'écran doit contenir un contrôle de type "liste" affichant les informations de la table principale. Le code de la liste (LST par défaut) peut être redéfini par l'intermédiaire de la variable héritée CodeListe. Afin de minimiser la programmation, le nom de l'écran et celui du menu déroulant ont été normalisés. Le modèle utilise par défaut l'écran CHOIX.ECR et le menu CHOIX.KEY.
Les
écrans, menu déroulants, menus contextuels et bitmaps sont en général
regroupés dans un fichier de ressources appelé GLOBAL. Ce fichier est
déclaré par l'intermédiaire de la déclaration GLOBAL du langage. Il est
cependant inutile d'effectuer la déclaration dans chaque objet. Une déclaration
unique au niveau des déclarations globales du composant est suffisante.
La déclaration REP_OBJ permet de définir les répertoires de recherche
des ressources du composant. Contrairement à la déclaration GLOBAL, cette
déclaration doit être effectuée dans chaque objet. En pratique, elle n'est
utile que pendant les phases de développement et de "relookage"
du produit.
Les méthodes et variables héritées de SCRITERE
Les méthodes et variables héritées du modèle SCRITERE ne sont pas redéfinies par le modèle CHOIX. Pour plus d'informations consultez la documentation du modèle SCRITERE.
Les variables héritées du modèle
pIdent
Cette variable héritée est en fait le premier paramètre reçu par l'objet CHOIX. Cette donnée de type Chaine est passée par référence et reçoit en retour l'identifiant de l'enregistrement sélectionné par l'utilisateur. La valeur reçue au démarrage permet de se positionner sur un enregistrement voulu.
Erreur
Cette variable de type Entier correspond au deuxième paramètre reçu par l'objet CHOIX. Elle est passée par référence et rend à l'appelant une valeur représentative de l'action de l'utilisateur. La valeur vaut 0 en cas de sélection d'un enregistrement, 1 en cas d'abandon et 2 en cas de sélection d'aucun enregistrement. Des explications complémentaires sont fournies ci-dessous.
Les méthodes spécialisées du modèle
Méthode VALIDATION
Elle est déclenchée lorsque l'utilisateur effectue la sélection d'un enregistrement. Elle affecte le paramètre pIdent par l'identifiant de l'enregistrement en cours, elle force le paramètre erreur à zéro et provoque la sortie de l'objet.
Méthode ABANDON
Elle met à vide le paramètre pIdent, force le paramètre erreur à 1 et provoque la sortie de l'objet.
Méthode AUCUN
Elle met à vide le paramètre pIdent, force le paramètre erreur à 2 et provoque la sortie de l'objet. Le choix AUCUN diffère du cas ABANDON par l'utilisation qu'en fera l'appelant. En effet, en cas d'abandon l'objet appelant doit considérer que l'utilisateur n'a effectué aucune opération, alors qu'au contraire le cas AUCUN correspond à un choix délibéré qui conduit à une modification des données de l'objet.
Méthode GERER
La méthode GERER fait appel à l'objet GESTION du composant en lui passant en paramètre l'identifiant de la fiche en cours. L'objet GESTION est appelé de manière synchrone (Instruction AppelerObjet). Au retour de l'appel, la liste de l'objet CHOIX est actualisée pour tenir compte des modifications éventuelles apportées aux données du composant.
Méthode <CodeListe>_CHOIX
Lorsque l'utilisateur effectue un double-clic dans une liste (ou tape Entrée dans la norme clavier standard), Oxygène++ déclenche la méthode générique CTRL_CHOIX qui elle-même fait appel à la méthode <CodeListe>_CHOIX (<CodeListe> symbolisant ici le code du contrôle de type "Liste" défini dans l'écran). Dans le cas du modèle CHOIX, ce mécanisme a été redéfini de façon à ce que le double-clic provoque la sélection de l'enregistrement. La méthode CTRL_CHOIX redirige donc l'événement vers la méthode VALIDATION. L'événement <CodeListe>_CHOIX n'est donc plus déclenché dans ce modèle.