|
| Accueil → WINDEV 2025 → Comment créer un tableau croisé ou un état avec des en-têtes de colonnes fusionnées (et nombre de sous-colonnes variable) ? |
| Comment créer un tableau croisé ou un état avec des en-têtes de colonnes fusionnées (et nombre de sous-colonnes variable) ? |
| Débuté par HSM, 29 mai 2026 14:38 - 2 réponses |
| |
| | | |
|
| |
Membre enregistré
2 messages |
|
| Posté le 29 mai 2026 - 14:38 |
Bonjour à tous,
Je cherche à réaliser un état sous WinDev dont la structure ressemble à l'image ci-jointe.
Comme vous pouvez le voir, le tableau présente :
En ligne : Une liste d'éléments fixes ou dynamiques (CLIENT1, CLIENT2, etc.).
En colonne : Des groupes principaux (LOCAL1, LOCAL2, LOCAL3, etc.).
La particularité : L'en-tête de chaque groupe fusionne un nombre de sous-colonnes qui peut varier. Par exemple, LOCAL1 a 3 sous-colonnes (Adresse, Tel, C. Affaire), tandis que LOCAL2 en a 4 (avec Plafond en plus).
J'aimerais savoir quelle est la meilleure approche sous WinDev pour concevoir ce type d'état de manière propre et dynamique:
Est-ce qu'il vaut mieux passer par un État sur Tableau Croisé (TCD) ? Si oui, comment gérer les sous-colonnes asymétriques/variables ?
Est-il préférable de générer l'état entièrement par programmation (avec des fonctions comme ChampClone pour dupliquer les blocs de colonnes dynamiquement) ?
Existe-t-il une astuce directement dans l'éditeur d'états pour lier/fusionner des blocs d'en-têtes ?
Précision importante sur mes données :
Mes données ne proviennent pas directement d'un fichier HFSQL, mais d'un tableau structuré généré entièrement par programmation (en mémoire). Le nombre de colonnes (et de sous-colonnes) est donc totalement variable et dynamique d'une exécution à l'autre.
Au vu de cette contrainte, quelle est selon vous la méthode la plus robuste ?
Merci d'avance pour vos pistes ou exemples de code !
| LOCAL1 | LOCAL2 | LOCAL3 |
-----------------------------------------------------------------------------------------------------------------------------------
| Adresse | Tel | C. Affaire | Adresse | Tel | C. Affaire | Plafond | Adresse | Tel | C. Affaire |
-----------------------------------------------------------------------------------------------------------------------------------
CLIENT1 | | | | | | | | | | |
CLIENT2 |
CLIENT3 |
CLIENT4 |
CLIENT5 |
CLIENT6 |
CLIENT7 |
CLIENT8 |
CLIENT9 |
Cordialement.Message modifié, 29 mai 2026 - 15:01 |
| |
| |
| | | |
|
| | |
| |
Membre enregistré
2 messages |
|
| Posté le 29 mai 2026 - 15:00 |
| |
| |
| | | |
|
| | |
| |
| Posté le 31 mai 2026 - 06:10 |
Salut,
Avant de partir sur le code, je commencerais par cadrer deux points :
* le nombre de locaux est-il toujours limité à 3 ?
* chaque client a-t-il toujours les mêmes locaux, ou cela peut varier de 1 à N ?
Si le nombre de locaux peut dépasser 3, je fixerais d'abord une limite maximale d'affichage, sinon l'état risque de devenir illisible même en paysage.
Ensuite, je partirais sur un état paysage avec quelques champs modèles invisibles (entête, sous-colonne, cellule, etc.) qui seront dupliqués dynamiquement à partir de la structure mémoire.
Le principe serait :
* calculer le nombre définitif de colonnes ;
* calculer la largeur disponible ;
* répartir automatiquement la largeur ;
* dupliquer les colonnes ;
* alimenter les cellules.
Pour éviter de mettre toute cette logique dans l'état, je créerais même une classe dédiée réutilisable avec des méthodes du type :
* CalculeLargeurDisponible()
* FixeLargeurColonnes()
* DupliqueColonne()
* DupliqueEntete()
* AffecteCellule()
* GenereLigneClient()
* GenereLocal()
* AjustePositionColonnes()
Cela permet de réutiliser la même mécanique sur d'autres états dynamiques et de garder un code beaucoup plus maintenable.
Du coup, dans ce contexte, je partirais clairement sur une génération par programmation plutôt qu'un TCD.
--
Maher
https://codeetcompetences.fr |
| |
| |
| | | |
|
| | | | |
| | |
|