Discussion :

[Arnaud B.]

Allez, je ne résiste pas au plaisir de partager un bug qui n'a jamais été corrigé en version 15 (mais plus présent en version 16 a priori).

Vous allez voir, il est particulièrement gratiné celui là

Soit un modèle de fenêtre avec une procédure locale PL_Procédure()

Soit une fenêtre rattachée à ce modèle de fenêtre.

La procédure PL_Procédure() de la fenêtre est surchargée dans la fenêtre.

Dans le code de cette procédure surchargée, on a notamment le code suivant

Code :

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

AjouteLigne(tTableauErreursSaisie, "Veuillez indiquer la fonction")

Le bug: lors d'une modification de la procédure du modèle, suivie d'une mise à jour de la fenêtre rattachée à ce modèle, le code de la procédure locale surchargée est modifié de manière intempestive :
le mot "fonction" dans la chaine de caractère est remplacé par l'intégralité du code de la procédure locale du modèle de fenêtre !

Contournement : utilisation du code suivant :

Code :

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

Remplace("Veuillez indiquer la fonctio_n","_","")

Voilà, en bref, en v15, on ne peut pas utiliser le mot fonction dans une chaine dans une procédure locale surchargée d'un modèle...

[e.haefele]

Mais quand tu dis "qui ne semble pas choquer PCSOFT" :
leur as tu soumis le bug ?
quelle a été leur réponse ?

Je ne m'en suis pas occupé personnellement mais oui ça aurait été fait et à l'époque de la version 9 ou 10 et on nous aurait indiqué que ce symptôme ne serait pas corrigé. Par conséquent c'est quand même à prendre avec les précautions d'usage mais suite à une redécouverte très récente de ce dysfonctionnement et à des incompréhensions et des mécontentements en clientèle nous avons décidé de le soumettre à nouveau dès réception de la version 19.

[=JBO=]

Allez, je ne résiste pas au plaisir de partager un bug qui n'a jamais été corrigé en version 15 (mais plus présent en version 16 a priori).
[...]
Voilà, en bref, en v15, on ne peut pas utiliser le mot fonction dans une chaine dans une procédure locale surchargée d'un modèle...

Ce bug m'impressionne !
et quelle leçon d'humilité pour tous les développeurs.

[=JBO=]

Bonjour,

Voici ce que j'ai constaté pour les versions plus anciennes de Windev (12 à 16).

MultiChaîne + caractère <0> comme délimiteur ==> ChaîneVersTableau() est myope

Dans les API Windows, mais aussi dans le registre Windows, il arrive qu'on ait à manipuler une donnée de type "MultiChaîne" (cf. multistring, aussi nommé REG_MULTI_SZ dans le registre Windows).
Une "MultiChaîne" est composée d'une série de chaînes séparées par le caractère Caract(0) et terminée par un Caract(0) final. Le tout peut être vu globalement comme une chaîne de caractères contenant un ou plusieurs Caract(0).

Le problème est d'extraire les chaînes "individuelles" contenues dans la "MultiChaîne".
Avec le délimiteur Caract(0), la fonction ExtraitChaîne() donne toute satsifaction.
L'instruction de parcours de chaîne POUR TOUT basée sur le délimiteur Caract(0) est aussi satisfaisante.

En revanche, la fonction ChaîneVersTableau() avec Caract(0) pour délimiteur bute sur une "MultiChaîne" et ne voit que la première chaîne.
Apparemment, l'implémentation de cette fonction considère que Caract(0) est forcément un marqueur de fin de parcours (comme ASCIIZ), et ne tient pas compte de la taille réelle de la MultiChaîne.

Je ne peux pas dire que c'est un bug. En revanche, cette implémentation n'est pas cohérente vis à vis de celles de ExtraitChaîne() et de POUR TOUT.
Ce fonctionnement particulier n'est pas documenté (d'où une suspicion de bug).
Voilà qui peut devenir un piège.


Bug sur opérateur égalité et valeur NULL dans instruction SI ALORS SINON

Dans une instruction conditionnelle SI ALORS SINON où la condition est composée de l'opérateur de comparaison 'égalité' et d'un opérande dont la valeur est un "NULL évalué",
(j'appelle "Null évalué" une valeur Null obtenue indirectement par l'évaluation d'une expression, à distinguer d'un Null littéral)
je constate que l'égalité est toujours vraie entre ce NULL évalué et n'importe quelle valeur scalaire à laquelle il est comparé.

Pour contourner ce bug, il faut évaluer la valeur de vérité de la condition en dehors de l'instruction SI ALORS SINON.

Je donne ci-dessous le code pour visualiser le bug, et aussi le code de contournement.
Le test consiste à rechercher la valeur "D" dans un tableau de 4 variant qui contient les valeurs "A", 2, Null et "D".

Code WLangage :

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
30
31
t est un tableau de Variant = ["A",2,Null,"D"]
v est un Variant = "D"
sInfo est une chaîne
 
// BUG sur Null évalué
 
POUR i = 1 _A_ t..Occurrence
SI t[i] = v ALORS
sInfo += [RC] + i + " trouvé"
SINON
sInfo += [RC] + i + " -"
FIN
FIN
 
sInfo += [RC] + "-------------"
 
// Contournement du BUG sur Null évalué
 
b est un booléen
 
POUR i = 1 _A_ t..Occurrence
b = t[i]=v
SI b ALORS
sInfo += [RC] + i + " trouvé"
SINON
sInfo += [RC] + i + " -"
FIN
FIN
 
Info(sInfo)
RENVOYER sInfo

Voilà la trace du résultat pour le bug et son contournement

Code Trace :

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

1
2
3
4
5
6
7
8
9
1 -
2 -
3 trouvé
4 trouvé
-------------
1 -
2 -
3 -
4 trouvé

J'imagine que ce bug existe toujours dans les versions suivantes.

[Hibernatus34]

Merci beaucoup, =JBO=, c'est typiquement le genre de problème auquel je faisais allusion. Mais si vous n'avez pas signalé ces cas au support technique, vous devriez le faire.

Concernant le 1er point, il n'y a pas besoin de leur parler de multichaîne (du chinois pour eux), WinDev est censé fonctionner avec des chaînes contenant tout type de caractère. C'est donc bien un bug.

Pour le 2ème point, au 1er coup d'oeil ça semble être la même chose que mon 4ème point dans le tout premier message. J'avais appelé ça "comparaison d'un variant à Null", mais en regardant de plus près ça aurait dû être "comparaison d'un variant valant Null à n'importe quoi".

[=JBO=]

Ce bug m'impressionne !
et quelle leçon d'humilité pour tous les développeurs.

Mon commentaire a reçu un et comme il n'y avait pas de malice dans mon propos, je vais le réécrire de façon à lever toute ambigüité (je ne peux plus corriger mon précédent message):

Ce bug m'impressionne !
Il s'agit probablement d'un "effet de bord" qui a une conséquence vraiment surprenante.
Aussi je me dis que c'est une belle leçon d'humilité pour tous les développeurs, puisque c'est un excellent exemple de la fragilité d'un développement logiciel complexe.
Bravo pour avoir levé ce "lièvre".

Et je profite de ce message pour proposer un autre contournement pour ce bug:
il s'agit de transformer la chaine de caractères en "message multilangue", ce qui devrait avoir pour effet de la remplacer par un code de message qui lui ne sera pas réécrit accidentellement lors de l'intégration des modifications du modèle.
A tester...

[Ben13d10]

Celui là est tout de même assez impressionnant !!

Code :

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

1
2
3
4
5
6
7
8
9
vVar1	est Variant	= Null
vVar2	est Variant	= 0
 
SI vVar1 <> vVar2 ALORS
	SI vVar1 = vVar2 ALORS
		// On passera bien là !
		Trace("vVar1 <> vVar2 et vVar1 = vVar2")
	FIN
FIN

Il est vrai que personne n'est à l'abri de bug, de plus, ce ne doit pas être un code couramment utilisé, mais si comme le signale l'auteur, le bug a été signalé et est resté non corrigé, là c'est beaucoup plus gênant :/

Reste à savoir quand il a été signalé. Ce serait peut être un information supplémentaire à ajouter à cette liste.

Par contre si l'on veut rester le plus objectif possible, il faut vraiment se limiter au bugs. Exemple de cette remarque cela est étonnant c'est un fait, mais ce n'est pas un bug.

je dis peut être une bétise, mais le type variant accepte tout et n'importe quoi. Dans ce cas, nous comparons des choux et des carottes. Un numérique avec null ? cette valeur Nulle représente le vide.

[Hibernatus34]

Il y a 2 cas, quand on compare des choux et des carottes :
1. Conversion implicite (je compare une chaîne à un entier, ça fonctionne)
2. Conversion impossible (une exception est levée, ça plante)

Mais Null, ce n'est ni un chou ni une carotte, c'est l'absence de légume.
Et un langage rigoureux ne tente pas de le convertir implicitement.

Ce cas est géré de manière très particulière dans chaque langage.
Voir par exemple :
- la logique du NULL en SQL : comparaison renvoyant NULL à la place d'un booléen, et condition traitant le NULL comme un FALSE
- la logique du NaN en C/C++ (pour les flottants), avec x != x qui est vrai.

Mais en WinDev c'est n'importe quoi, et la preuve est que si on met des parenthèses autour de la comparaison, on n'obtient pas le même résultat.
(voir la suite de mon code, tronqué dans votre message)

[Arnaud B.]

Il y a 2 cas, quand on compare des choux et des carottes :
1. Conversion implicite (je compare une chaîne à un entier, ça fonctionne)
2. Conversion impossible (une exception est levée, ça plante)

Mais Null, ce n'est ni un chou ni une carotte, c'est l'absence de légume.
Et un langage rigoureux ne tente pas de le convertir implicitement.

Ce cas est géré de manière très particulière dans chaque langage.
Voir par exemple :
- la logique du NULL en SQL : comparaison renvoyant NULL à la place d'un booléen, et condition traitant le NULL comme un FALSE
- la logique du NaN en C/C++ (pour les flottants), avec x != x qui est vrai.

Mais en WinDev c'est n'importe quoi, et la preuve est que si on met des parenthèses autour de la comparaison, on n'obtient pas le même résultat.
(voir la suite de mon code, tronqué dans votre message)

Je plussoie : la gestion du Null (absence de valeur) est typiquement le genre de thème sur lequel un langage doit proposer :
- une gestion précise : conversion, comportement avec les différents opérateurs...
- et la documentation qui va avec

Force est de constater que Windev ne propose ni l'un ni l'autre.

D'autre part, il y a un mélange des genres que je trouve particulièrement gênant dans Windev, et là je veux aussi parler du typage :

1°) on a à la fois un typage fort explicite (s est une chaine, i est un entier...)
... et une variable sans type (v est un variant)

2°) d'autre part, on a un mécanisme de conversion implicite :

Code :

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

1
2
3
i est un entier = 1
s est une chaine = i
// ça fonctionne

... et pas de conversion possible dans certains cas : passage de paramètres par adresse dans des paramètres de type différent (ce qui est logique)
... sauf si le paramètre n'a justement pas de type (donc est un variant)
... ou si on force la conversion en entourant la variable de parenthèses...

3°) enfin (et c'est là le lien avec Null), seul un type supporte le marqueur Null, c'est le "type" Variant... alors qu'il n'y a a priori pas de rapport entre le typage et la valeur Null (en SQL, par exemple, le typage est souvent implémenté de manière très forte dans les SGBD, ce qui n'empêche pas que le marqueur Null est supporté par tous les types...)

Bref, tout ça est assez confusant je trouve...

[Hibernatus34]

Effectivement, un tag <nullable> pour toute variable serait intéressant.
Mais sans aller jusque là, il suffirait que la comparaison de 2 variants soit un tant soit peu cohérente, et ça serait déjà pas mal. Par exemple, je veux bien que Null = Null, même si c'est discutable, mais pas 0 = Null quand on a 2 opérandes de type variant et donc aucune conversion à faire.

[Ben13d10]

Il y a 2 cas, quand on compare des choux et des carottes :
1. Conversion implicite (je compare une chaîne à un entier, ça fonctionne)
2. Conversion impossible (une exception est levée, ça plante)

Mais Null, ce n'est ni un chou ni une carotte, c'est l'absence de légume.
Et un langage rigoureux ne tente pas de le convertir implicitement.

Ce cas est géré de manière très particulière dans chaque langage.
Voir par exemple :
- la logique du NULL en SQL : comparaison renvoyant NULL à la place d'un booléen, et condition traitant le NULL comme un FALSE
- la logique du NaN en C/C++ (pour les flottants), avec x != x qui est vrai.

Mais en WinDev c'est n'importe quoi, et la preuve est que si on met des parenthèses autour de la comparaison, on n'obtient pas le même résultat.
(voir la suite de mon code, tronqué dans votre message)

Hibernatus34 bonjour,
je suis entièrement d'accord avec toi. la conversion implicite quand tu définis un variant = 0 par exemple. Mais quand tu définis un variant = null nous sommes vraiment dans le potager

[michel.souris]

Je ne résiste pas à l'envie de partager ce "bug" qui a occupé mon après-midi (merci PC-Soft)...

Le contexte : j'utilise deux états qui sont éditables séparément ou ensemble en mode recto/verso. Le produit est en WD17.

J'avais, à la base, utilisé une image en fond d'état au format PNG... il s'est avéré que la visionneuse avant impression laissait apparaitre une bordure dégueulasse noire... genre un truc de transparence mal géré ou je sais pas trop...

J'ai donc intégré un fond en PDF et c'était joli ! sauf que à ma grande déception (et après livraison pour la petite histoire) il s'avère que le fait d'utiliser un fond PDF avec iEnchaînementAjoute ou avec des états composites ne fonctionne pas sur "certaines" config... le "certaines" me casse particulièrement les c...... Sur XP le message laisse comprendre que c'est une adresse mémoire qui n'a pas pu être être read...

Mon cheminement :
1. Environnement de dév = BUG
2. VM monoprocesseur = OK
3. Environnement de dév en désactivant tous mes processeurs sauf 1 (pour simuler un mono comme sur ma VM) = OK
4. VM multiprocesseur = BUG
5. PC d'un collègue multiproc = OK (??? alors là je pète un plomb... ???)
6. Autre PC d'un collègue multiproc = BUG

C'était pas peut être la bonne piste mais j'ai quand même regardé pas mal de choses avant... et puis j'ai pas trop d'idée... je comprends pas... quand je pense que tout marchait très bien en PNG....

Bref voilà c'est très ciblé comme pb mais ça illustre bien ma frustration quotidienne

[michel.souris]

Allez un petit autre... magique !

Donc, comme nous le savons tous, Hyperfile a une vision bien à lui des standards SQL (comme la plupart des SGBD diront les puristes).

Je devais faire une requête du style (bon je vous laisse penser ce que vous voulez du modèle, c'est de la merde je le sais... jointure croisée et cie... c'est pas mon oeuvre) :

Code :

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

1
2
 
UPDATE T1 INNER JOIN T2 ON T1.idT1=T2.idT1 SET T1.idT2=T2.idT2

ouais quand t'en ai là c'est que ça pue... mais c'est pas le sujet !

Bon ça passe pas....
Je vérifie, c'est bien la syntaxe SQL2....

Ok la même en SQL1 :

Code :

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

1
2
 
UPDATE T1, T2  SET T1.idT2=T2.idT2 WHERE T1.idT1=T2.idT1

Bon ça passe pas...
Je me dis tant pis pas d'update avec jointure... je vais faire un sous requête !
Donc :

Code :

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

1
2
 
UPDATE T1SET T1.idT2=(SELECT T2.idT2 FROM T2 WHERE T1.idT1=T2.idT1)

Bien sûr ça passe pas....

Bon ok je vais bricoler un truc qui va me générer autant de requête SQL que nécessaire :

Code :

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

1
2
3
 
SELECT 'UPDATE T1 SET idT2='+T2.idT2+' WHERE idT1='+T1.idT1
FROM  T1 INNER JOIN T2 ON T1.idT1=T2.idT1

Ca passe pas... il ne connait soit disant pas la table T1....

Et bien devinerez vous d'où ça vient ?????

... je vous le donne en mille, Emile, ça vient du 'WHERE'... car notre ami HF cherche a interpréter ce qui est entre quote... paye ton parseur... je sais que c'est pas standard comme cas d'utilisation... mais de contournement en contournement on fini par faire des trucs bizarres et en plus par trouver d'autres bugs...

Voilà fin de l'histoire, ce qui aurait pris 15 minutes prends 2 heures...

[tatayo]

Sans Paul ni Mickey, avec une requête de ce genre ça doit passer:

Code sql :

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

1
2
3
4
5
6
 
insert into ti(c1,c2)
select c1,c3
from t1 inner join t2 on x=y
where z=w
update duplicates

Tatayo.

[michel.souris]

T'inquiète, pas de paul et mic....

Je m'en vais tester de suite !!!

Par contre j'avoue ne pas comprendre le UPDATE duplicates je vais me renseigner ! merci pour l'idée en tout cas !

Et pis pour finalement polémiquer... devoir passer par un INSERT pour faire un UPDATE c'est un peu tordu !

Et enfin pour faire l'unanimité... traiter les chaines à concaténer comme des mots clés... ça craint !

[Hibernatus34]

Et enfin pour faire l'unanimité... traiter les chaines à concaténer comme des mots clés... ça craint !

J'ai voulu vérifier ce bug et je ne l'ai pas reproduit sous WD18.
De toute façon, ça serait un bug que vous pourriez faire corriger via le support technique.

[tatayo]

L'option "update ???" indique au moteur quoi faire en cas de doublons sur la clé primaire (et uniquement sur celle-ci):
Update duplicates => met à jour la ligne de la table (en gros transforme un insert en update)
Ignore duplicates => ne fait rien (ignore les doublons, mais sans remonter d'erreur).

C'est très pratique, par exemple quand on fait des imports de masse: au lieu de tester à chaque ligne si elle existe déjà, pour choisir entre insert et update, on lance un insert into ... update duplicates. Moins de code, une seule requête, et tout est géré !

Reste à savoir si HF connait cette syntaxe.

Tatayo.

[michel.souris]

Le UPDATE duplicates ne passe pas....

Mais merci beaucoup ! très très très pratique en effet !!!! comment combiner des lignes en INSERT pure et éventuellement en doublon ! excellent

[Hibernatus34]

http://en.wikipedia.org/wiki/Merge_(SQL)

C'est quelque chose qu'on peut facilement faire avec un UPDATE suivit d'un INSERT ... WHERE NOT EXISTS ...

[bruno.a]

bonjour,

Je reviens sur la requete WDR complétée ensuite dans une chaine (Arnaud B je crois).
Je n'ai pas bien compris ce qu'il faut faire pour intégrer cette requete à la table une fois transformée en chaine.
Quelqu'un peut m'expliquer ?

Moi je n'utilise pratiquement jamais les WDR et pour remplir une table je passe par un hexecuterequetesql et un POUR TOUT.

Merci