[WD12] variable écrasée par une fonction hyperfile

**manonoc** · 11/12/2008, 14h28

Bonjour,

Je suis souvent confronté à l'écrasement d'une variable locale lorsqu'une recherche dans la base ne trouve pas de données:

Code :

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

1
2
3
4
5
6
Info( IDTache) 
POUR TOUT Calendrier AVEC "IDTacheDePlanification = "+IDTache 
Calendrier.IDTacheDePlanification = -1 
HModifie ( Calendrier) 
FIN 
Info( IDTache)

le premier Info donne la valeur de l'ID, le deuxième renvoie -1 (qui est la valeur par défaut dans la base)

On dirait qu'il passe IDTache par adresse plutôt que par copie, ce à quoi on s'attendrait plutôt.

autre exemple encore plus bizarre, car on y voit pas la variable IDTache, à part en affichage: IDTache ayant une valeur de 212 dans la première Info, se retrouve avec la valeur -1 à la deuxième:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Info("IDTache ="+IDTache)
// on compte si la durée rentre dans le premier jour
nNbPériodesDisponible est un entier = 0
SI bTacheRepositionnéeHorsCalendrier ALORS
	nNbPériodesDisponible = gnAffichagePeriodeFin - nPériodedébut
SINON
	POUR TOUT Calendrier AVEC "NumeroPeriode >="+nPériodedébut+" et NumeroPeriode<="+nPériodeFin+...
		" et DatePeriode="+SAI_date+...
		" et IDUniteProduction="+COMBO_UniteProduction
 
		nNbPériodesDisponible++
	FIN
FIN
Info("IDTache ="+IDTache)

Ce comportement bizarre est-il normal, ou y-a-t-il un bug ?

merci

**vmolines** · 11/12/2008, 14h42

Vous parlez de passage par adresse mais je ne vois nulle part de passage de paramètre si ce n'est à la fonction "Info".

Et vous présentez un morceau de code où IDTache n'est pas déclaré, on ne sait pas d'où ça vient.

**manonoc** · 11/12/2008, 15h08

Envoyé par vmolines

Vous parlez de passage par adresse mais je ne vois nulle part de passage de paramètre si ce n'est à la fonction "Info".

justement: j'affiche une variable, ou je la donne pour créer une chaine de caractères, et elle se trouve modifiée ! c'est précisément ce que je ne comprends pas, elle ne devrait pas être modifiée (ce genre de modif se trouve essentiellement en C, lorsqu'on passe à une fonction une variable par adresse, et que cette fonction modifie la variable, ce genre de passage est un passage par adresse par opposition au passage par copie, qui lui permet de protéger sa variable des modifications).

J'ai remarqué que ceci arrive sur une variable utilisée pour faire une requète avec les fonctions hyperfile, hlitrecherchepremier par exemple, lorsque aucune lignes n'est renvoyée. A ce moment là, ma variable locale qui normalement ne doit être utilisée qu'en lecture, est écrasé.

Envoyé par vmolines

Et vous présentez un morceau de code où IDTache n'est pas déclaré, on ne sait pas d'où ça vient.

c'est une variable locale, ou un paramètre de la fenêtre peu importe

**vmolines** · 11/12/2008, 15h32

Mettez un point d'arrêt au début de votre traitement. Ensuite ajoutez IDTache comme expression dans le debugger et activez l'arrêt du code si la valeur change (clic sur l'icone vert qui doit alors passer en rouge). Poursuivez l'execution du code avec F5 (ou bouton GO).

Le debugger arrêtera l'exécution du code lorsque la valeur de la variable aura changé. Vous saurez ainsi précisément quelle instruction a provoqué cela.

**manonoc** · 11/12/2008, 15h47

il s'agit de la fonction :

Code :

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

1
2
HLitRecherchePremier(Calendrier, DatePeriodeNumeroPeriodeIDUniteProduction,...
	HConstruitValClé(Calendrier, DatePeriodeNumeroPeriodeIDUniteProduction, SAI_date, nPériodedébut, COMBO_UniteProduction))

qui ne contient pas IDTache, et je ne comprends pas pourquoi cette fonction modifie cette variable.

**vmolines** · 11/12/2008, 16h07

C'est amusant car le code que vous aviez présenté au début et où IDTache était sensé être modifié ne comporte pas de HLitrecherchePremier. Maintenant vous nous montrez un nouveau code où il y a HLitrecherchePremier.

Je ne pense pas qu'on puisse vous aider si vous ne clarifiez pas vos explications.

**Louis Griffont** · 11/12/2008, 16h09

Il n'y aurait pas, par hasard, une rubrique du fichier Calendrier, ou d'un fichier lié, qui s'appelerait IDTache ? Ce qui pourrait expliquer ce changement !

**manonoc** · 11/12/2008, 17h22

Envoyé par vmolines

C'est amusant car le code que vous aviez présenté au début et où IDTache était sensé être modifié ne comporte pas de HLitrecherchePremier. Maintenant vous nous montrez un nouveau code où il y a HLitrecherchePremier.

oui, j'avais bien dit "recherche dans la base ne trouve pas de données:" ce qui rassemble toutes les formes de recherche, (POUR TOUT ... hlitrecherhchepremier, ...)

Envoyé par vmolines

Je ne pense pas qu'on puisse vous aider si vous ne clarifiez pas vos explications.

désolé, j'essaie d'être le plus clair possible

**manonoc** · 11/12/2008, 17h25

Envoyé par kwasin

Il n'y aurait pas, par hasard, une rubrique du fichier Calendrier, ou d'un fichier lié, qui s'appelerait IDTache ? Ce qui pourrait expliquer ce changement !

une rubrique s'appelle IDTacheDePlanification

mais je ne pense pas que ça soit la cause, il faudrait qu'il y ai le nom de la table avant, avec un point, du genre:
Calendrier.IDTache

sinon, qu'est ce qu'un fichier lié ?

**Jannus** · 11/12/2008, 17h32

Clair, ça l'est : une variable IDTache est modifié innoportunément.

Mais si le code est différent à chaque post, si les informations sont insufisantes on ne pourra guère, malgré toute notre bonne volonté, trouver de solution.

On sait qu'une variable IDTache est modifiée lors de la consultation d'un fichier alors qu'elle ne devrait pas l'être selon vous.
Nous savons par expérience qu'une variable ne change pas "toute seule" sans raison.

Il nous faut donc le code complet utilisé (pas des bouts de code) et une description des rubriques du fichier consulté.
Bref, tous les éléments qui pouraient nous donner une piste concrète, sinon, nous en sommes réduit à des suppositions.

L'idée de tracer la variable est évidemment une bonne piste pour visualiser ce qui se passe. Ça a été testé ?

**manonoc** · 11/12/2008, 17h37

bien sur, je l'ai testé comme conseillé, et c'est bien dans cette fonction que la variable change de valeur

je regarde plus en avant et vous donne le fin mot de l'histoire si je trouve.

merci à vous

**peijnoob** · 11/12/2008, 20h34

J'ai eu le même problème il y a quelques temps, et la raison était simple : Tous les passages de paramètres en Windev se font par adresse !

Même si comme ça, il parait que le rapport n'est pas évident à faire, un exemple valant mieux qu'un bon discours :

Imaginons un bouton qui supprime la tache actuellement en mémoire

Code :

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

1
2
3
 
//Code de clic sur un bouton par exemple
SupprimeTache(Calendrier.IDTacheDePlanification)

Le code de la procédure :

Code :

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

1
2
3
4
5
6
7
8
9
 
PROCEDURE SupprimeTache(IDTache)
 
Info( IDTache) 
POUR TOUT Calendrier AVEC "IDTacheDePlanification = "+IDTache 
  Calendrier.IDTacheDePlanification = -1 
  HModifie ( Calendrier) 
FIN 
Info( IDTache)

Et bien aussi étonnant que cela puisse paraître, car cela va à l'encontre du fonctionnement habituel de la plupart des langages de programmation, le 2e info affichera bien -1.

En effet, comme je l'ai dit, par défaut, Windev gère tous les passages de paramètres par adresse, et non par valeur, ce qui fait que dans la procédure SupprimeTache, IDTache pointe sur la zone mémoire dans laquelle est enregistrée IDTachePlanification de la structure correspondant à ton fichier Calendrier.

Du coup, si tu lis un autre enregistrement, la zone mémoire est modifiée, et donc ta variable IDTache avec.

Tu as donc 2 solutions :

Code :

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

1
2
3
 
SupprimeTache((Calendrier.IDTacheDePlanification))
// Mettre le paramètre entre parenthèse lors d'un appel de fonction force le passage de paramètre par valeur.

ou

Code :

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

1
2
3
4
 
IDTache est un entier = Calendrier.IDTacheDePlanification
 
SupprimeTache(IDTache)

Après, je n'ai pas connaissance de tout votre code, mais en voyant ton explication, et ayant déjà rencontré le problème, je suis quasiment sûr et certain qu'il s'agit bel et bien de la source de l'erreur.

Si ce n'est pas le cas, tu as le droit de donner cet aspect à ma tête :

(oui, j'adore ce smiley

)

En espérant avoir pu t'aider.

Bon dev !

**Louis Griffont** · 12/12/2008, 08h49

Envoyé par manonoc

sinon, qu'est ce qu'un fichier lié ?

Dans l'analyse si tu as décrits des liens entre fichiers, qui font que le déplacement dans un fichier entraine un déplacement dans un ou plusieurs autres fichiers, automatiquement...

Envoyé par peijnoob

JTous les passages de paramètres en Windev se font par adresse !

Par défaut, serait plus juste que "Toujours". Il faut spécifier à Windev que le passage se fait par valeur et non par adresse.

Envoyé par peijnoob

Code :

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

1
2
3
4
5
6
7
8
9
 
PROCEDURE SupprimeTache(IDTache)
 
Info( IDTache) 
POUR TOUT Calendrier AVEC "IDTacheDePlanification = "+IDTache 
  Calendrier.IDTacheDePlanification = -1 
  HModifie ( Calendrier) 
FIN 
Info( IDTache)

Et bien aussi étonnant que cela puisse paraître, car cela va à l'encontre du fonctionnement habituel de la plupart des langages de programmation, le 2e info affichera bien -1.

Aucune surprise, ni aucun étonnement, c'est décrit dans l'aide de windev !

Envoyé par peijnoob

Si ce n'est pas le cas, tu as le droit de donner cet aspect à ma tête :

(oui, j'adore ce smiley

)

Moi aussi, j'adore ce smiley...

**manonoc** · 12/12/2008, 08h55

merci pour ta réponse !

C'est en effet ce que j'avais déduis moi aussi, il s'agit d'un passage par adresse auquel on ne s'attend pas.

Indépendamment du pb de passage des parametres, le pb est que les structures hyperfile qu'on utilise pour manipuler les données (celles qui contiennent une ligne de la base de donnée)(comme Calendrier) sont apparemment des structures de pointeurs qui doivent pointer sur les variables comme IDTache, lorsqu'on effectue une requête.
Lorsque la requête ne renvoie rien, cette variable IDTache est changée, le pb c'est qu'elle doit normalement garder sa valeur, tant qu'on ne l'a pas modifié volontairement, quelquesoit le comportement des requêtes qu'on fait.

Ce genre de comportement me parait être un bug, qu'en pensez-vous ?

**manonoc** · 12/12/2008, 09h11

Envoyé par kwasin

Dans l'analyse si tu as décrits des liens entre fichiers, qui font que le déplacement dans un fichier entraine un déplacement dans un ou plusieurs autres fichiers, automatiquement...

Par défaut, serait plus juste que "Toujours". Il faut spécifier à Windev que le passage se fait par valeur et non par adresse.

Aucune surprise, ni aucun étonnement, c'est décrit dans l'aide de windev !

Moi aussi, j'adore ce smiley...

Je suis intéressé par savoir comment indiquer qu'on veut un passage de paramètres par copie, si tu veux bien me l'expliquer.
Car la doc d'autoformation n'en parle pas (pg 57: a propos du passage par paramètres)

Le pb vient plus du fait que la requête écrase une variable locale qu'on ne lui a pas demandé d'écraser (j'ai sans doute passé ce point dans la doc d'autoformation).

Pourrais-je avoir l'endroit ou ceci est décrit ?
(dans la doc d'autoformation ? dans l'aide en ligne ? un lien serait le bienvenue !)

merci

**peijnoob** · 12/12/2008, 10h11

Envoyé par manonoc

Je suis intéressé par savoir comment indiquer qu'on veut un passage de paramètres par copie, si tu veux bien me l'expliquer.
merci

J'avais mis un exemple dans mon post, il suffit de mettre le paramètre entre parenthèses :

Code :

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

1
2
 
MaFonction((MonParamètrePasséParAdresse))

Envoyé par kwasin

Aucune surprise, ni aucun étonnement, c'est décrit dans l'aide de windev !

Oui, c'est pour ça que je précise que ça va à l'encontre de la plupart des langages de programmations, c'est pour ça que c'est étonnant

Aussi, il est vrai que c'est écrit dans la doc de Windev, mais personnellement, avant d'avoir eu, un jour, besoin de faire du passage par adresse, j'étais persuadé que windev fonctionnait comme les autres : valeur pour les types simples, adresse pour les types complexes.

Ceci explique mon étonnement le jour où j'ai découvert ça (oui, je ne me suis pas encore amusé à lire toute l'aide de Windev de A à Z

)