Developpez.com

Télécharger gratuitement le magazine des développeurs, le bimestriel des développeurs avec une sélection des meilleurs tutoriels

Developpez.com - 4D
X

Choisissez d'abord la catégorieensuite la rubrique :


Préférences utilisateur

Date de publication : Avril 2006

Par Larry Sharpe (Infoservice)
 

Cette note fait suite à la note technique "Formulaire de sortie modifiable par l'utilisateur" et utilise la même base exemple. Elle permet de sauvegarder les colonnes du formulaire de sortie choisies par l'utilisateur et quelques autres variables modifiables dans une table de la base.

Introduction
La base exemple
Le code exemple
La structure
Les formulaires
Les méthodes
La méthode base Sur ouverture
La méthode base Sur démarrage serveur
La méthode projet xOutput_Columns
La méthode projet xPreferences_Users
La méthode projet xPreferences
Autres modifications possibles
Conclusion
Télécharger la base exemple


Introduction

Cette note fait suite à la note technique "Formulaire de sortie modifiable par l'utilisateur" (référence 4D-200604-10-FR) et utilise la même base exemple. Elle permet de sauvegarder les colonnes du formulaire de sortie choisies par l'utilisateur et quelques autres variables modifiables dans une table de la base. Je ne décris ici que la section du code qui concerne ces préférences.


La base exemple

Il y a trois utilisateurs : Designer, Administrator et Test User. Seul l'utilisateur Designer possède un mot de passe, qui est : designer (pour afficher la fenêtre des mots de passe et permettre de changer d'utilisateur).

La base exemple utilise trois tables, [Personnes], [Sociétés] et [xPreferences]. Les tables [Personnes] et [Sociétés] sont utilisées pour montrer comment du code et des formulaires de sortie similaires peuvent être utilisés, avec comme seule différence les champs/colonnes et leur formatage qui sont stockés dans la table [xPreferences]. La table [xPreferences] est l'essentiel de cette note, c'est là que sont stockées et chargées toutes les préférences nécessaires. En plus des colonnes sélectionnées pour chaque formulaire, il y a trois autres types de préférences nommées Startup Table (table de démarrage), Data Entry (données par défaut) et Server Settings (paramètres serveur). Startup Table sert à sélectionner la méthode exécutée au démarrage et Data Entry à proposer des valeurs par défaut pour la saisie.

Chaque utilisateur a le droit de modifier ses préférences, en utilisant la ligne de menu Préférences dans le menu Edition. S'il est connecté en tant que Designer ou Administrator, il peut modifier les préférences de tous les utilisateurs. En clients-serveur, il peut aussi fixer les préférences pour le serveur. Ces préférences sont utilisées par des process serveur qui sont différents sur plusieurs points des process client. Ce sujet sera exploré dans la troisième note de cette série.

Les préférences définies ici ne sont que des exemples et vous pouvez en ajouter, modifier ou supprimer selon vos besoins. Une autre remarque sur ces exemples est qu'on pourrait utiliser un enregistrement de [xPreferences] au lieu de deux. Mon objectif est de montrer comment stocker des variables dans des enregistrements pour répondre à des besoins.


Le code exemple


La structure

Le premier champ de chaque table est un identifiant, défini comme invisible, qui n'est ni montré ni autorisé dans le formulaire de sortie. Consultez le trigger pour voir en détail comment on procède. Tous les autres champs sont disponibles pour figurer dans le formulaire de sortie. La table [xPreferences] est celle où sont stockées les préférences utilisateurs, non seulement le nom de l'utilisateur, mais aussi le type de préférence qui peut être : Startup View (démarrage), Data entry (valeurs par défaut), CompanyList (formulaire de sortie des [Sociétés]) et PeopleList (formulaire de sortie des [Personnes]). Les valeurs courantes des préférences sont stockées dans un champ Blob de cette table. L'utilisation d'un blob nous permet d'utiliser n'importe quel type de données pour les préférences stockées. Il suffit de les écrire, puis de les relire dans le même ordre. Le point à vérifier en cas d'ajout ou de suppression de variable dans le blob est de faire cet ajout ou suppression dans le même ordre dans les deux sections de code pour la sauvegarde et le chargement, en utilisant le même type de variable. Croyez moi, si vous désynchronisez ces deux parties, vous aurez des problèmes.


Les formulaires

Il y a deux formulaires pour chacune des deux tables utilisateurs [Personnes] et [Sociétés] : "Input" et "Output". Les formulaires "Input" sont des formulaires standards d'entrée de données, sans programmation particulière. A plusieurs endroits, ils utilisent des valeurs par défaut qui proviennent de la méthode projet xPreferences. La question des formulaires de sortie a été traitée dans la note technique précédente, "Formulaire de sortie modifiable par l'utilisateur".

La méthode xPreferences est décrite en détail ci-dessous.

Nous avons aussi un formulaire nommé "Prefs_Users" dans la table [xPreferences], qui sert à modifier les préférences qui ne concernent pas les formulaires de sortie, essentiellement la méthode de démarrage et les valeurs par défaut. Ce formulaire utilise la même méthode xPreferences que les autres process de la base pour permettre la lecture ou l'écriture des préférences. Il a plusieurs pages, qui peuvent être mises à jour si besoin. La page 0 contient les variables d'interface utilisateur affichées sur chaque page. Les pages 1 et 2 contiennent les deux ensembles de variables de préférences utilisées dans cette base. La page 3 servira avec les process serveur.

En page 0, il y a un popup situé en haut à droite, qui montre tous les noms d'utilisateurs définis pour cette base. Si vous êtes en client-serveur, ce popup affiche aussi les options pour le serveur. L'onglet asPrefCategories permet à l'utilisateur de changer de page pour modifier les préférences de l'utilisateur choisi. Lorsque l'une ou l'autre de ces informations est modifiée, au changement de page ou au changement d'utilisateur, toutes les préférences pour la page et l'utilisateur spécifié sont stockées et rechargées.

C'est dans la méthode de ce formulaire que toutes les variables sont définies et initialisées sur chargement. Tous les tableaux sont redimensionnés à 0 pour libérer la mémoire lorsque le formulaire est refermé. Lorsque l'utilisateur change d'utilisateur ou de page, le code est géré dans l'objet lui-même.


Les méthodes


La méthode base Sur ouverture

Cette méthode, lancée au démarrage sur un client ou en monoposte, exécute les actions suivantes :

· xOutput_Columns ("OnStartUp") crée les variables interprocess utilisées dans cette partie du code. Voyez la note précédente pour plus de détails.

· xPreferences ("DefineVars";"Startup View")  est appelé pour définir les variables ou tableaux utilisés

· xPreferences ("Load";"Startup View")  vérifie si l'utilisateur a choisi sur quelle table ouvrir une fenêtre au démarrage. Si c'est le cas, il exécute la méthode qui lance le process et son code.


La méthode base Sur démarrage serveur

La méthode base Sur démarrage serveur (en cas d'exécution sur un serveur) est exécutée au premier chargement de la base et charge les préférences nécessaires. Ces préférences seront définies dans la note technique suivante, "Process serveur".


La méthode projet xOutput_Columns

Cette méthode a été discutée dans la note technique précédente. La partie qui concerne la présente note est l'enregistrement des préférences utilisateurs dans la table [xPreferences].


La méthode projet xPreferences_Users

code 4D

: (Nombre de parametres = 0)
Ceci s'exécute lorsque la méthode est appelée par une ligne de menu. Cette section nous permet de créer un nouveau process pour gérer l'édition des préférences de l'utilisateur. Elle rappelle la méthode xPreferences_Users avec les paramètres "Setup" et *. Le paramètre * passé à la commande Nouveau process permet de créer le process s'il n'existe pas de process de ce nom, sinon, de passer au premier plan le process identifié par son numéro. De cette manière, nous ne créons pas plusieurs instances du même process, ce qui pourrait être source de problèmes.


La méthode projet xPreferences

Cette méthode contient l'essentiel du code utilisé pour cet exemple. Lisez les commentaires dans la base pour des explications détaillées sur chaque section de code.

code 4D

: ($command ="Load")
Cette section, ainsi que les sections suivantes du Au cas ou, est appelée par un process existant ("People" ou "Companies", par exemple). Elle fait une recherche dans [xPreferences] pour trouver l'enregistrement correspondant à l'utilisateur et au type de préférences demandé, (par exemple Designer et Data entry). Si aucun enregistrement ne correspond, un enregistrement est créé avec les valeurs par défaut définies ci-dessous. Si un enregistrement est trouvé, les variables nécessaires sont chargées depuis le blob. Si plus d'un enregistrement est trouvé pour cet utilisateur et ce prefType, tous ces enregistrements sont supprimés et un nouvel enregistrement est créé avec les valeurs par défaut, puis les variables nécessaires sont mises à jour.

code 4D

: ($command ="Save")
Cette section est très similaire à la section "Load", sauf que nous sauvons les variables dans l'enregistrement de [xPreferences] au lieu de les lire.

code 4D

: ($command = "Defaults")
Chaque type de préférence a des valeurs par défaut qui sont définies ici. Ces valeurs peuvent être une chaîne vide, un nombre, ou n'importe quel tableau de données, comme celui utilisé pour le code de xOutput_Columns.

code 4D

: ($command = "DefineVars")
Ceci est appelé juste avant la ligne de code qui fait appel à xPreferences ("Load";…) pour définir les variables ou tableaux de préférences nécessaires.


Autres modifications possibles

Cette base Exemple crée et utilise un enregistrement de préférences par utilisateur. Vous pourriez avoir un seul jeu de préférences pour tous les utilisateurs de la base. En repérant tous les appels à la commande Utilisateur courant et en les remplaçant par une valeur fixe, vous auriez les mêmes préférences pour tout le monde. N'oubliez pas de mettre à jour le popup des utilisateurs, si cette option est retenue.


Conclusion

Cette note technique couvre plusieurs sujets :

1. Elle complète la note technique "Formulaire de sortie modifiable par l'utilisateur"
2. Elle montre comment charger et sauvegarder des valeurs saisissables par un utilisateur qui sont alors utilisées pour l'interface (formulaires de sortie), pour le choix d'une action (vue au démarrage) ou pour des valeurs par défaut.

Tous les éléments cités dans cette note sont abondamment commentés dans les méthodes.

La note suivante montrera comment construire des process exécutés sur le serveur lui-même mais contrôlés par les préférences stockées dans les données et mises à jour par l'interface de 4D client.


Télécharger la base exemple



Télécharger la base exemple.

__________________________________________________
Copyright © 1985-2009 4D SA - Tous droits réservés
Tous les efforts ont été faits pour que le contenu de cette note technique présente le maximum de fiabilité possible.
Néanmoins, les différents éléments composant cette note technique, et le cas échéant, le code, sont fournis sans garantie d'aucune sorte. L'auteur et 4D S.A. déclinent donc toute responsabilité quant à l'utilisation qui pourrait être faite de ces éléments, tant à l'égard de leurs utilisateurs que des tiers.
Les informations contenues dans ce document peuvent faire l'objet de modifications sans préavis et ne sauraient en aucune manière engager 4D SA. La fourniture du logiciel décrit dans ce document est régie par un octroi de licence dont les termes sont précisés par ailleurs dans la licence électronique figurant sur le support du Logiciel et de la Documentation afférente. Le logiciel et sa documentation ne peuvent être utilisés, copiés ou reproduits sur quelque support que ce soit et de quelque manière que ce soit, que conformément aux termes de cette licence.
Aucune partie de ce document ne peut être reproduite ou recopiée de quelque manière que ce soit, électronique ou mécanique, y compris par photocopie, enregistrement, archivage ou tout autre procédé de stockage, de traitement et de récupération d'informations, pour d'autres buts que l'usage personnel de l'acheteur, et ce exclusivement aux conditions contractuelles, sans la permission explicite de 4D SA.
4D, 4D Calc, 4D Draw, 4D Write, 4D Insider, 4ème Dimension ®, 4D Server, 4D Compiler ainsi que les logos 4e Dimension, sont des marques enregistrées de 4D SA.
Windows,Windows NT,Win 32s et Microsoft sont des marques enregistrées de Microsoft Corporation.
Apple, Macintosh, Power Macintosh, LaserWriter, ImageWriter, QuickTime sont des marques enregistrées ou des noms commerciaux de Apple Computer,Inc.
Mac2Win Software Copyright © 1990-2002 est un produit de Altura Software,Inc.
4D Write contient des éléments de "MacLink Plus file translation", un produit de DataViz, Inc,55 Corporate drive,Trumbull,CT,USA.
XTND Copyright 1992-2002 © 4D SA. Tous droits réservés.
XTND Technology Copyright 1989-2002 © Claris Corporation.. Tous droits réservés ACROBAT © Copyright 1987-2002, Secret Commercial Adobe Systems Inc.Tous droits réservés. ACROBAT est une marque enregistrée d'Adobe Systems Inc.
Tous les autres noms de produits ou appellations sont des marques déposées ou des noms commerciaux appartenant à leurs propriétaires respectifs.
__________________________________________________
 



Valid XHTML 1.1!Valid CSS!

Ce document est issu de http://www.developpez.com et reste la propriété exclusive de son auteur. La copie, modification et/ou distribution par quelque moyen que ce soit est soumise à l'obtention préalable de l'autorisation de l'auteur.
Contacter le responsable de la rubrique 4D