Version imprimable
Bonjour,
Est-il possible d'afficher plusieurs "colonnes" dans un champs liste ?
Je m'explique :
J'aimerais que mon champ liste affiche la liste de mes clients.
L'information affichée serait issue du fichier client et composée de :
La civilité + le prénom + le nom + la ville entre parenthèses
Le champ liste ne comporte qu'une seule colonne.
Comment la remplir avec plusieurs données assemblées ?
Merci de votre aide
Bonjour,
Pourquoi ne pas utiliser une table ? Ainsi plus de problème de nombre de colonne...
Tatayo.
Bonjour
Il suffit de modifier le type de la liste : dans l'onglet "Contenu" modifier "Type déroulé" en "Table". Un bouton "Editer les colonnes" apparait alors en haut à droite
Après ça se manipule comme une table
Le problème du champ table c'est que la largeur des colonne est "fixe". Je m'explique :
Si j'ai "Jean" "DUPOND" au dessus de "Jean Batiste Roland" "DE JEMLAJOUE" je trouve que la présentation est pas clean.
Je préfère un affichage plus optimisé.
Je ne trouve pas le "Type déroulé" dans "Contenu" pour modifier le type de la liste en table !?
Je parlais d'une liste déroulante (combo)
Un champ liste simple n'a pas cette option car dans ce cas je rejoins la réponse de tatayo : c'est un champ table qu'il te faut
Je ne comprends pas ta remarque sur les colonnes "fixes"
Les colonnes peuvent être redimensionnées à la main ou par programmation, on peut même faire un TableAjuste(TaTable) pour ajuster au mieux
Ensuite si les séparateurs de colonnes te gênent tu peux changer leur couleur
Bonjour,
Comme déjà répondu supra par tatayo puishpascal, la solution naturelle et évidente est un champ Table.
Maintenant, lolo, si vous voulez absolument passer par une liste, il vous faudra bricoler (si, si, j'ai osé).
Pour les longueurs fixes : Complète() qui va compléter ou tronquer vos chaînes.
Pour construire les lignes, tout simplement la concaténation des chaînes ou ChaineConstruit() à partir des paramètres ou à partir d'un tableau alimenté par une requête ou un parcours.
En gros :
Bon travailCode:
2
3
4
5
6
7
8
9
10
Hemgé
C'est bien une "liste" que je souhaite et pas un combo.
Pour le redimensionnement des colonne de table, je sais bien que l'on peut ajuster la largeur mais cela n’empêche que le prénom court ce retrouvera éloigné du nom parce que la largeur de colonne est conditionnée par la largeur du prénom le plus long. Et je trouve cela moche.
Mais j'ai bien compris que c'est la solution naturelle pour autant.
Hemgé, j'ai une question concernant ta suggestion :
Perso, j'ai utilisé le code suivant :
C'est très rudimentaire, je te l'accorde.Code:
2
3
4
5
6
7
8
Tu me confirmes que ta solution est plus rapide en termes de traitement des données ?
Merci encore ;-)
Tu peux aussi baser ta liste sur une requête qui concatène nom et prénom
Je te rappelle ta demande initiale : "Comment afficher plusieurs colonnes dans un champ liste"
Rien à voir avec ce que tu veux vraiment donc, enfin si mais mal formulé. Pour moi quand je lis liste et colonne, je pense à table. Là tu parlais surement des colonnes du "fichier"
Bonjour,
Donc, votre question prêtait effectivement à confusion.
Oubliez Complète() : j'avais compris que vous vouliez respecter une présentation en "colonnes" comme énoncé, ce qui est tout le contraire de votre souhait réel.
Quant à ma méthode (ChaineConstruit, je suppose), je n'ai aucune idée des performances comparées, mais le test n'est pas compliqué à mettre en place.
Je pense que la simple concaténation directe doit rester la méthode la plus rapide à l'exécution, mais à tester.
Elle est surtout plus aisée à maintenir, plus générique et paramétrable, mais ce n'est pas nécessairement indispensable.
Comme le suggère hpascal, une requête avec concaténation des rubriques extraites pourrait aussi faire l'affaire et serait - elle - peut-être plus rapide. A tester, de nouveau.
Elle présenterait aussi l'avantage de tout intégrer : parcours, extraction, tri et concaténation. Plus rapidité, sans garantir plus [U]de[/U ]rapidité.
Concernant votre code :
- HLitPremier : je suppose que vous avez défini un filtre, sinon vous parcourez dans l'ordre des numéros d'enregistrement, ce qui expliquerait le tri ultérieur mais n'est pas idéal du tout.
- ListeTrie() : je ne comprends pas ce tri, sauf si vous n'avez défini ni clé de parcours, ni filtre plus complexe qu'une simple clé.
En principe, HLitPremier, HLitSuivant génère votre un ordonné suivant le critère choisi pour le filtre défini par HFiltre.
Un HLitRecherchePremier sur une clé (éventuellement composée) devrait vous permettre d'éviter le tri et la définition du filtre.
Même sur une table mémoire, un tri prend du temps. Ici, à première vie, soit il est inutile, soit il est a priori évitable.
Bon travail,
Hemgé
Je crois que je vais abandonner l'idée du champ liste parce qu'en plus, j'aimerais faire du "responsive design". Les infos affichées sont plus ou moins nombreuses selon la largeur du champ qui, elle même, dépend de la largeur de la fenêtre.
Je continue de regretter de ne pas pouvoir utiliser le champ LISTE car sur le plan graphique, je le trouve plus efficace dans certain cas.
Je me demandais si je ne pourrais pas travailler avec une variable de type tableau.
Hemgé, je reviens sur vos remarques concernant mon code car une leçon est toujours bonne à prendre :
Hlitpremier : Non je n'ai pas définis de filtre. Dans la mesure où je veux voir l'intégralité des données, je n'en voyais pas l'utilité. En quoi n'est ce pas idéal de faire ainsi avec un tri en fin de procédure ?
Listetrie : En rapport avec le précédent sujet
Hlirecherchepremier : Pourquoi ou comment utiliser cette fonction alors que ne veux pas faire de recherche particulière, je veux tous les enregistrements ?
Merci de votre aide
Je ne vois pas très bien le rapport avec le type de champ que vous utiliserez pour l'affichage, puisque les fenêtres et les champs ont une largeur fixe, mais modifiables par programmation.Citation:
Envoyé par lololebricoleur
Dans cette perspective, il faudrait maintenir quelque part la plus grande largeur d'affichage nécessaire pour la liste en mettant ce mémo à jour à chaque création et modification de fiche, et en la récupérant à l'ouverture de la fenêtre.
Plus efficace que quel autre type de champ et pourquoi ?Citation:
Je continue de regretter de ne pas pouvoir utiliser le champ LISTE car sur le plan graphique, je le trouve plus efficace dans certain cas.
Vous pourriez. Il suffit de charger le tableau puis d'utiliser TableauVersChaine() puis d'afficher votre liste.Citation:
Je me demandais si je ne pourrais pas travailler avec une variable de type tableau.
Vous pourriez alors trier les colonnes du tableau en indiquent l'ordre dans lequel les colonnes doivent intervenir dans le tri et selon quel sens (asc/descendant).
Mais, à nouveau, pourquoi compliquer les choses alors qu'il y a les clés ?
Que vous vouliez voir la totalité des fiches, n'exclut pas d'ordonner les données. Et de fait, vous les triez.Citation:
Hlitpremier : Non je n'ai pas définis de filtre. Dans la mesure où je veux voir l'intégralité des données, je n'en voyais pas l'utilité. En quoi n'est ce pas idéal de faire ainsi avec un tri en fin de procédure ?
Listetrie : En rapport avec le précédent sujet
Même réponse : Que vous vouliez voir la totalité des fiches, n'exclut pas d'ordonner les données.Citation:
Hlirecherchepremier : Pourquoi ou comment utiliser cette fonction alors que ne veux pas faire de recherche particulière, je veux tous les enregistrements ?
Si vous triez votre liste, elle va être triée en principe selon les critères définis lors de la description du champ, puisque vous n'utilisez aucune des constantes de tri dans votre fonction.
Tablons sur un tri alphabétique croissant.
Vous aurez donc un tri par Civilité et à l'intérieur de celles-ci, par prénom, puis enfin éventuellement par patronyme si vous avez plusieurs occurrences identiques de Civilité-Prénom.
Donc après HlitPremier (*) /HLitSuivant
1. Monsieur Michel Dupontsera trié comme suit :
2. Docteur Albert Dupont
3. Colonel Jean Mercier
4. Mademoiselle Cécile Vanhée
5. Mademoiselle Rosine Bertouilli
3. Colonel Jean Merciercàd sans aucun respect de l'ordre alphabétique des noms, qui est sans doute celui attendu.
2. Docteur Albert Dupont
4. Mademoiselle Cécile Vanhée
5. Mademoiselle Rosine Bertouilli
1. Monsieur Michel Dupont
Dans ce cas, on ne saisit pas l'intérêt du tri.
Si vous avez une clé sur le nom ou sur l'association nom et prénom (concaténation ou clé composée), vous obtiendrez un résultat plus 'orthodoxe'.
Cette clé est maintenue par HF et ne nécessite aucun traitement additionnel au moment de son exploitation.
Votre manière d'aborder le problème et vos questions m'amènent à vous conseiller de relire attentivement toutes les instructions HLit*** et à vous pencher sur les clés.
Je n'utilise jamais les filtres et ne les connais pas. Je n'y ai fait allusion qu'au vu de votre manière d'utiliser HLitPremier.
* Extrait de la doc :
Rubrique de parcours
Si la rubrique de parcours utilisée est une clé, la fonction HLitPremier lit l'enregistrement pour lequel la valeur de la clé est la plus petite. L'ordre de tri pris en compte est l'ordre de tri spécifié dans l'analyse pour cette clé. En cas de doublons, HLitPremier lit le premier enregistrement "doublon" selon l'ordre des numéros d'enregistrement.
Si la rubrique de parcours n'est pas une clé, la fonction HLitPremier lit le premier enregistrement actif. En cas de parcours du fichier, les enregistrements seront triés selon leur numéro d'enregistrement.
Dans ce cas, la rubrique de parcours sélectionnée apparaîtra en rouge sous l'éditeur de code et un warning sera affiché dans le volet "Code".
Numéro d'enregistrement ne signifie pas identifiant automatique et Vous n'avez même pas d'ordre chronologique garanti puisque, en cas de suppression, les enregistrements sont réutilisés.