Discussion :

[Hibernatus34]

Bonjour,

J'en ai vraiment marre de l'incapacité de WinDev à gérer le NULL correctement.
Pour l'instant, le problème est qu'on ne peut pas écrire proprement/simplement du code laissant à l'utilisateur la possibilité de distinguer "0" de "rien".
Après, il faudra aussi vérifier comment se comporte WinDev avec les opérateurs arithmétiques etc.

Voici 4 bugs illustrés par un projet de test joint à ce message : WinDevEtNull.zip

1. Comparer 2 variants dont l'un est Null :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
vVar1	est Variant	= Null
vVar2	est Variant	= 0
 
Trace("vVar1 est Variant = Null")
Trace("vVar2 est Variant = 0")
Trace("----")
SI vVar1 <> vVar2 ALORS
	Trace("SI vVar1 <> vVar2 : Oui")
SINON
	Trace("SI vVar1 <> vVar2 : Non")
FIN
SI vVar1 = vVar2 ALORS
	// On passera bien là !
	Trace("SI vVar1 = vVar2 : Oui")
SINON
	Trace("SI vVar1 = vVar2 : Non")
FIN
SI (vVar1 <> vVar2) ALORS
	// On ne passera pas là
	Trace("SI (vVar1 <> vVar2) : Oui")
SINON
	Trace("SI (vVar1 <> vVar2) : Non")
FIN
SI (vVar1 = vVar2) ALORS
	// On passera là
	Trace("SI (vVar1 = vVar2) : Oui")
SINON
	Trace("SI (vVar1 = vVar2) : Non")
FIN

2. Comparaison d'un variant à Null, selon qu'il est dans une expression, renvoyé par une fonction, ou immédiat :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
vVar	est Variant	= 0
 
Trace("vVar est Variant = 0")
SI vVar = Null ALORS
	Trace("BUG : vVar = Null")
SINON
	Trace("OK : vVar <> Null")
FIN
SI (vVar) = Null ALORS
	Trace("BUG : (vVar) = Null")
SINON
	Trace("OK : (vVar) <> Null")
FIN
SI pRenvoieVariant(0) = Null ALORS
	Trace("BUG : pRenvoieVariant(0) = Null")
SINON
	Trace("OK : pRenvoieVariant(0) <> Null")
FIN

3. Les rubriques d'analyse qui ne permettent pas d'écrire un code simple, et obligent inutilement à tester la propriété ..Null :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
vVar	est Variant
 
HRAZ(TableTest)
HAjoute(TableTest)
Trace("TableTest.ColTest = Null")
SI TableTest.ColTest = 0 ALORS
	Trace("SI TableTest.ColTest = 0 : Oui")
SINON
	Trace("SI TableTest.ColTest = 0 : Non")
FIN
SI TableTest.ColTest = 1 ALORS
	Trace("SI TableTest.ColTest = 1 : Oui")
SINON
	Trace("SI TableTest.ColTest = 1 : Non")
FIN
vVar = TableTest.ColTest
Trace("vVar = TableTest.ColTest")
Trace("vVar = " + pNullableVersChaîne(vVar))

4. "Null si vide" dans une colonne de table et affectation par programmation :

Code :

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

1
2
3
4
5
6
7
8
9
10
TableAjouteLigne(TABLE_Test, Null)
COL_Test[1] = Null
Trace("COL_Test[1] = Null")
Trace("Valeur affichée : """ + COL_Test[1]..ValeurAffichée + """")
Trace("Valeur mémorisée : " + pNullableVersChaîne(COL_Test[1]..Valeur))
COL_Test[1] = ""
Trace("-----")
Trace("COL_Test[1] = """"")
Trace("Valeur affichée : """ + COL_Test[1]..ValeurAffichée + """")
Trace("Valeur mémorisée : " + pNullableVersChaîne(COL_Test[1]..Valeur))

NB. La première partie de cet exemple est corrigée en WD19, car si on affecte Null ça affiche bien une chaîne vide. Mais la suite reste vraie : on peut se débrouiller pour avoir une chaîne vide à l'affichage et un zéro en valeur. (pas très grave, mais PC Soft ne fait jamais les choses à fond, c'est dommage)


Si ça vous pose problème autant qu'à moi, merci d'envoyer une requête au support technique.

Si, en revanche, vous pensez qu'il y a une explication logique à ce comportement, merci de me l'expliquer.
Je pense qu'il suffit de montrer ça lors du choix d'un outil de développement pour éliminer WinDev immédiatement. Ca le décrédibilise, et le ferait passer pour un outil d'amateurs. C'est comme la conversion de Date vers DateHeure... ça fait peur.

[Hibernatus34]

Je fais une petite mise à jour pour WinDev 19 :
Il y a un cas qui est maintenant correctement géré : si on met <NULL> dans une colonne de table "Null si vide", ça affiche bien une chaîne vide.
Ce n'est pas le cas en version 18.

En fait, WinDev reproduit à peu près le comportement de SQL : toute expression contenant Null renvoie Null.

Mais en SQL, une condition n'est validée que par TRUE. Si l'expression testée vaut FALSE ou NULL, la condition n'est pas validée.
Et en SQL, il y a IS NULL et IS NOT NULL qui permettent d'écrire une expression renvoyant TRUE ou FALSE, seule exception à la règle de propagation du NULL.

En WinDev, le test IS NULL/IS NOT NULL est de la forme "= Null" / "<> Null".
Mais on a 2 problèmes :
- Le test "= Null" ne fonctionne que si l'expression testée est un variant nommé. Dès que c'est une expression plus complexe, la règle de propagation du Null reprend le dessus (d'où les différences avec ou sans parenthèses)
- La condition "SI Null" est validée au lieu d'être invalidée comme en SQL.
Pourtant, si on met Null dans un booléen, ça donne Faux... Là aussi, ça doit expliquer la différence entre "vVar1 = vVar2" et "(vVar1 = vVar2)", mais pas totalement, car dans les 2 cas ces expressions doivent être Null.

[Ben13d10]

Bonjour,
il me semble que ce sujet avait déjà été évoqué dans le forum.

En ce qui me concerne, j'ai résolu (du moins je pense ) ce soucis en affectant des valeurs à la variable de type VARIANT.

En effet, cette variable pouvant contenir des choux et des carottes, il a été nécessaire de lui affecter une valeur afin de pouvoir tester son contenu

Bon test
Cordialement

[R&B]

A ceux qui ne comprenne pas l'irritation que ce "petit" problème évoque, c'est que vous utilisez WinDev pour ce qu'il est : un EDI L4G qui résoud vos problème de typage par le mécanisme de trans-typage natif : la capacité de WinDev d'interpréter une chaine en nombre et réciproquement. On peut pratiquement tout coder avec des chaines.

Dès qu'on veut maîtriser les types on se cogne à des raccourcis pris pour satisfaire à cette fonctionnalité.

La valeur NULL en est effectivement un triste exemple.
Comme souvent, ce n'est que remontées utilisateur après remontées utilisateur que le système évolue.
C'est déjà un problème en soi, mais si on ajoute le développement en agilité, on arrive parfois à des corrections unitaires sans remise à plat de la gestion du problème dans son ensemble (plus lourd on peut le concéder facilement)...

Bref, Hibernatus34 soulève une fois de plus un problème épineux et j'espère que le code exemple permettra à PCSoft de se sortir de ces désagréments pour nous permettre un code cohérent.