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 client-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. À 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 utilisateur dans la table [xPreferences].
La méthode projet xPreferences_Users▲
: (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.
: ($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.
: ($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.
: ($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.
: ($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.