Discussion :

[Delphi-ne]

Bonjour,

Je bloque sur un problème au niveau d'un graphe en histogramme empilé
Le graphe est construit par programmation et valorisé à partir d'un tableau.

Mon code est le suivant

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
              	grSupprimeSérie(gr_GraphePrincipal)
                grType(gr_GraphePrincipal, grHistoEmpilé)
		grLibellé(gr_GraphePrincipal,grAfficheEtiquette,Vrai)
		POUR i = 1 A TableauOccurrence(LT_TableMemoire)			
		   grEtiquetteSérie(gr_GraphePrincipal, i, LT_TableMemoire[i].Legende)
		   grAjouteDonnée(gr_GraphePrincipal, i, Val(LT_TableMemoire[i].Valeur3))
		   grAjouteDonnée(gr_GraphePrincipal, i, Val(LT_TableMemoire[i].Valeur2))
		   grAjouteDonnée(gr_GraphePrincipal, i, Val(LT_TableMemoire[i].Valeur1))
		   grAjouteDonnée(gr_GraphePrincipal, i, Val(LT_TableMemoire[i].Valeur0))
	        FIN
                grDessine(gr_GraphePrincipal)

Le graphe s'affiche bien mais au niveau des légendes quand je passe sur les deux barres de droite le détail affiché répète deux fois la même ligne. Pourtant le chargement des séries est assez simple.
Merci de votre aide

[Hemgé]

Bonjour,

A première vue, je n'ai pas d'idée.
On va laisser décanter.

Par contre, quelques suggestions pour votre code :

Plutôt qu'une boucle POUR, optez pour un parcours de tableau POUR TOUT ..., instruction optimisée et qui vous évite la gestion des limites.

Dans le cadre de la répétition POUR, si vous utilisez une limite qui doit être évaluée, utilisez la forme optimisée :
Voir 3e ligne 'introduction et juste avant les Remarques

Une syntaxe optimisée est disponible : cette syntaxe permet de ne pas ré-évaluer la valeur limite et / ou la valeur du pas à chaque itération (utile par exemple dans le cas d'une répétition sur le nombre de ligne d'une table).
...
<_A_> :
Signale que la valeur finale doit être évaluée une seule fois

<_PAS_> :
Signale que le pas d'incrémentation doit être évalué une seule fois.

NB : voir également les instructions optimisées _ET_ et _OU_ .

Enfin, si je lis bien, vous utilisez un tableau de chaînes.
Sa dénomination prête à confusion : LT_TableMemoire.
Vous devez effectuer une conversion (Val() ) pour chaque grAjouteDonnée.
Vous énumérez chaque valeur que vous ajoutez. Quid si vous en avez 50 ?

Je vous suggère de travailler avec un tableau de structures, elle-mêmes composées d'une chaîne (LT_TableMemoire[i].Legende) et d'un tableau d'entiers ou de réels (LT_TableMemoire[i].Valeur3)
Vous pourrez alors avoir un parcours général (POUR TOUT, voire POUR i ...) qui traitera les séries et, outre l'affichage de la légende, un parcours interne à chaque série (POUR TOUT, voire POUR j ...) qui en affichera les valeurs.
Ce sera plus propre, plus lisible, paramétrable et optimisé.

Bon travail,

Hemgé

[tbc92]

+1 pour Hemgé.
Dans la boucle, j'aurais bien mis un GrAjouteSerie() pour commencer.
Et je pense qu'il faudrait vérifier combien de fois le programme passe dans la boucle. J'imagine que dans ta tête , il passe 2 fois ... mais vu l'image, je pense qu'il passe 3 fois.

En effet, sur la dernière colonne, on voit les valeurs 311 ; 0 et 16 ; C'est normal d'avoir le 0 ?

Bon. malgré ça, ça ne semble toujours pas clair.

[Delphi-ne]

Je vous suggère de travailler avec un tableau de structures

C'est déjà le cas.
On le voit dans cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grEtiquetteSérie(gr_GraphePrincipal, i, LT_TableMemoire[i].Legende)

Le tableau de structure contient un certain nombre d'informations partagée entre le graphe évoqué dans ce topic et aussi un table de chiifres affichée à côté : la légende utilisée ici mais aussi d'autres informations comme les styles d'affichage, les couleurs.
Effectivement j'ai figé le nombre de valeurs à 4 parce que c'est spécifié en cahier de charges et on ne va pas aller suggérer à l'utilisateur de changer. Cela me semblait lourd de gérer un tableau de tableaux avec une structure qui aurait ressemblé à cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
LT_MemoireType est une Structure
	Legende est une chaîne
	Alias   est une chaîne
	ID      est une chaîne
	Valeurs est un tableau de 4 entiers
Fin

mais pourquoi pas.

Sinon pour la dénomination LT signifie variable Locale Tableau.
Table que c'est un tableau
Memoire fait référence au type utilisé.

<_A_>

Ca je ne connaissais pas. J'essaierai mais je ne comprends pas pourquoi WD essaierait de réévaluer à chaque fois ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

POUR i = 1 A TableauOccurrence(LT_TableMemoire)

Dans la boucle, j'aurais bien mis un GrAjouteSerie() pour commencer.

Cela aurait semblé logique mais en WD20 cette instruction n'est pas connue

[Hemgé]

C'est déjà le cas.
On le voit dans cette ligne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

grEtiquetteSérie(gr_GraphePrincipal, i, LT_TableMemoire[i].Legende)

Effectivement, cela m'avait échappé.
C'était surtout dans l'idée de gérer le tableau d'entiers (Valeurs) que je soulevais ce point que vous évoquez infra.

j'ai figé le nombre de valeurs à 4 parce que c'est spécifié en cahier de charges et on ne va pas aller suggérer à l'utilisateur de changer.

4 entiers ou un tableau de 4 entiers, c'est la même chose aujourd'hui, mais pas en terme d'évolutivité de l'application.
Imaginez de repasser partout pour passer à 5 alors qu'un TableauOccurence() ne demandera jamais aucune révision.
Hypothèse peut-être hautement improbable dans votre cas, mais réflexe assez systématique en ce qui me concerne.

Cela me semblait lourd de gérer un tableau de tableaux avec une structure qui aurait ressemblé à cela :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
LT_MemoireType est une Structure
	Legende est une chaîne
	Alias   est une chaîne
	ID      est une chaîne
	Valeurs est un tableau de 4 entiers
Fin

mais pourquoi pas.

Que vous répondre ? Chacun a ses habitudes (et "essayer c'est l'adopter" ?)

Sinon pour la dénomination LT signifie variable Locale Tableau.
Table que c'est un tableau
Memoire fait référence au type utilisé.

Vous êtes dedans, mais vu de l'extérieur ou vu dans un certain laps de temps, cela interpelle.
Pour le reste, vous pouvez aussi autoriser le préfixage des variables (que vous pouvez d'ailleurs modifier à votre guise).
Dans la version standard, vous auriez tabValeurs pour un tableau local de valeurs et gtabValeurs pour une variable globale.
Les tableaux sont de type simple ou 'avancés' : dynamique, fixe, associatif et toujours en mémoire.
Ce sont les tables qui demandent la distinction entre les types mémoire et fichier (et accessoirement fichier chargée en mémoire)

[QUOTE]Ca je ne connaissais pas. J'essaierai mais je ne comprends pas pourquoi WD essaierait de réévaluer à chaque fois ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

POUR i = 1 A TableauOccurrence(LT_TableMemoire)

Peu importe, PCsoft vous le dit, dans la mesure où il vous indique le moyen de l'éviter.
On peut cependant se dire que si vous renseignez une variable, cette variable peut être modifiée pendant une itération.
A plus forte raison, la fonction (qui peut avoir un horizon très large) peut ramener un autre résultat si elle est réévaluée.
WD ne peut pas décider à votre place que la limité est figée, indication que vous lui fournissez en utilisant la forme _A_.
Autrement, il doit évaluer cette variable ou cette fonction chaque fois qu'il la rencontre.

Hemgé