Discussion :

[Hibernatus34]

Bonjour,

J'aimerais publier les bugs ou erreurs de conception qui me dérangent dans WinDev et ne semblent pas choquer le support technique, ou sur lesquels il est impossible d'apporter un correctif à cause de la rétrocompatibilité.
Ca permettra d'éviter certains désagréments aux autres développeurs, et ça forcera peut-être PC Soft à réfléchir un peu plus à la qualité, car ça devrait au moins leur faire honte.

Je ne mets pas tout immédiatement, c'est un peu long.
Si vous en avez d'autres, faites passer.

1. Copie d'une Date vers un DateHeure

Quelle est la différence entre ces 2 codes ?

Code :

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

1
2
3
 
dhDateHeure est DateHeure = ChaîneVersDate("01/01/2013")
Trace(dhDateHeure)

Code :

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

1
2
3
4
 
dDate est Date = "20130101"
dhDateHeure est DateHeure = dDate
Trace(dhDateHeure)

Réponse :
Quand un DateHeure reçoit une Date, la partie Heure reste inchangée, et donc ici c'est l'heure de création de la variable.
ChaîneVersDate, comme son nom ne l'indique pas, renvoie une chaîne, et quand un DateHeure reçoit une chaîne trop courte, l'heure est implicitement "00:00:00.000".
La logique voudrait qu'une Date dans un DateHeure donne la date à minuit !

Vous en voulez encore ?

Code :

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

1
2
3
4
5
 
dDate est Date = "20130101"
vVariant est Variant = dDate
VariantConvertit(vVariant, wlDateHeure)
Trace(vVariant)

Là j'ai converti un Variant Date vers DateHeure, et me voilà avec l'heure de la conversion, ajoutée à une date qui n'a rien à voir ! (le 1er janvier)
Là c'est formidable, on a une conversion non déterministe !


2. Le type "Source de Données"

Deux problèmes majeurs :
- Les variables de type Source de Données ne sont que des références (par le nom !) à des sources de données globales. Les problèmes causés par ce système sont assez connus, je ne développe pas ici.
- Les sources de données ne sont pas partageables entre les threads, ce qui rend pénible le remplissage d'une IHM à partir de requêtes exécutées en arrière plan.


3. La fonction dCopieImage

On peut féliciter PC Soft pour cette perle.
dCopieImage prend comme paramètres : X, Y, Hauteur, Largeur, dans cet ordre.
La logique voudrait : X, Y, Largeur, Hauteur.

Mais ce n'est pas tout : si vous utilisez un champ image comme source de la copie, il paraît évident que le champ restera inchangé... pas pour PC Soft ! La propriété ..Valeur qui pouvait contenir un chemin d'image n'est plus lisible, car tout champ image impliqué dans un dessin devient un Bitmap mémoire.
Imaginez alors ce code :

Code :

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

1
2
3
4
5
 
// On dessine l'icône sur le plan
dCopieImage(IMG_MonIcône, IMG_Plan, 42, 42)
// Le bouton d'action prend la même icône
BTN_Action..Image = IMG_MonIcône

La deuxième ligne ne fonctionnera pas à cause de la première.
J'ai un collègue qui s'est arraché les cheuveux sur du code beaucoup plus complexe parce que certaines images ne s'affichaient plus.


4. Comparaison d'un Variant à Null

Alors là, attention les yeux, c'est spectaculaire.

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
 
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
SI (vVar1 <> vVar2) ALORS
	// On ne passera pas là
SINON SI (vVar1 = vVar2) ALORS
	// On passera là
	Trace("vVar1 = vVar2 uniquement")
FIN

Vrai = Faux... c'est ça un L5G !

Peut-être ont-ils voulu mimer la logique du NaN dans l'IEEE 754, ou bien celle du NULL de SQL... quoi qu'il en soit, ils se sont plantés.

(notez que j'ai mis à jour le code ci-dessus après avoir compris qu'il suffit d'un seul Null dans la comparaison)


5. Nouvelle fonction de recherche (WD18)

Si on cherche une expression régulière, ça cherche sur une ligne complète.
Ca oblige à ajouter .* en début et fin de pattern à chaque recherche.
On perd l'intérêt du surlignage (toute la ligne est surlignée, ou rien).
PC Soft ne connait peut-être pas les caractères ^ et $ ? On voit dans leur doc qu'ils ne maîtrisent pas la fonction VérifieExpressionRégulière puisqu'ils ne documentent pas toutes ses fonctionnalités.


6. dFusionne

Cette fonction ignore l'alpha de l'image source, alors que rien n'empêchait de l'utiliser uniquement pour le blend des couleurs, tout en conservant l'alpha de la destination.


7. Les fonctions gStylo, gCadrage, etc.

Complètement buggé depuis toujours : les alignements verticaux, l'espacement des caractères, le retour à la ligne automatique...
Une fenêtre de démo (en WD18) est jointe à ce message. Vous comprendrez immédiatement de quoi je parle.


8. SQLTable

Un classique.
SQLTable se base en interne sur le séparateur de colonnes TAB. Ca signifie que si vous avez des TAB dans vos données, le remplissage d'une table deviendra complètement faux.


9. Coche grisée mais active

Comme certains le savent déjà, si vous grisez une cellule de table de type case à cocher, l'utilisateur aura toujours des moyens de la cocher/décocher, via la touche Espace, la multisélection...


10. Portée de ..Défaut dans une fenêtre

Si vous utilisez la propriété ..Défaut sur un paramètre de fenêtre, celle-ci est accessible pendant toute la durée de vie du paramètre (donc la durée de vie de la fenêtre).
Pourtant, la valeur de cette propriété n'est correcte que dans le code de déclaration de la fenêtre, après c'est n'importe quoi. (toujours Vrai ou toujours Faux, je ne me souviens plus)
Pour le support, c'est normal...
Le plus fort, c'est qu'en observant cette propriété dans le débogueur on aura la bonne valeur... selon qu'on l'observe directement ou dans une expression !
Encore une fois, on peut prouver avec WinDev que Vrai = Faux.
(j'ai joint un projet de test pour mieux comprendre)

11. Précédence des opérateurs booléens

En algèbre de Boole, il est communément admis que le ET est prioritaire sur le OU.
Pourtant, dans WinDev, ces 2 opérateurs ont la même priorité.

Code :

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

1
2
3
4
5
bA est booléen = Faux
bB est booléen = Faux
bC est booléen = Vrai
Trace(bA ET bB OU bC) // Vrai
Trace(bC OU bA ET bB) // Faux !

.

[Arnaud B.]

C'est une super idée, on en avait également parlé il y a quelque mois sur ce même forum.

Problème : j'en ai plusieurs dizaines, si je les mets tous, bonjour l'indigestion

Le top ce serait de les poster sur un serveur bugzilla ou mantis hébergé quelque part...

Bonjour,

J'aimerais publier les bugs ou erreurs de conception qui me dérangent dans WinDev et ne semblent pas choquer le support technique, ou sur lesquels il est impossible d'apporter un correctif à cause de la rétrocompatibilité.
Ca permettra d'éviter certains désagréments aux autres développeurs, et ça forcera peut-être PC Soft à réfléchir un peu plus à la qualité, car ça devrait au moins leur faire honte.

Je ne mets pas tout immédiatement, c'est un peu long.
Si vous en avez d'autres, faites passer.
.

[R&B]

Bonjour.

Ces éléments sont vérifiés mais le ton à charge ne fera pas avancer les choses.

Il est clair que l'adressage dans WinDev est soumis a une abstraction qui permet le transtypage. Tout le monde l'utilise et la rétrocompatibilité est effectivement un problème. Mais comme toute abstraction, il faut lorsque que celle-ci évolue, se prémunir des fuites avec des effets de bord préjudiciables.

Par exemple sur les sources de données (point 2) arrivée avec WD7, il s'agit d'un effet de bord dans la gestion des portées que j'ai pu démontrer il y a un certain temps déjà.

En effet, si la variable source a une portée résolue par sa déclaration, elle est en fait un pointeur sur un contexte HyperFile qui lui à une portée strictement globale (les fichiers de l'analyse ont cette portée). C'est la raison qui conduit à la situation démontrée.
Ainsi donc, pour ce sujet seul, que faut-il faire si ce n'est améliorer la documentation ?
En effet, on ne peut déclarer une variable (la source de données) qui aura une portée strictement globale tout comme on ne peut indiquer la portée d'un fichier de l'analyse. C'est la fuite de l'abstraction du pointeur sur un fichier.

J'espère que ce petit exemple démontrera que le "faire simple" de WinDev est très souvent compliqué et certainement pas gratuit.
On ne peut se séparer de ce qui fait le produit (RAD, maj automatique des données, IHM liée aux données trés simplement) sans tolérer des limites. On a l'exemple de la vitesse de calcul divisée par 50 par rapport à un compilateur plus strict en raison du transtypage. Mais aussi de notions bas niveau tel que l'adressage et les pointeurs volontairement "floutées" pour plus de facilité d'approche.

Ainsi le fait de citer dans une même phrase L5G et adressage de variant pique les yeux. Je ne remet en cause ni les problèmes évoqués ni leurs démonstration mais plutôt l'amalgame entre des notions éloignées qui sort l'information du champ rationnel et fait perdre du crédit au propos.

J'espère donc que chaque problème à été soumis, comme il vient d'être fait ici, au ST par la voie normale.
Je sais que c'est un passage désagréable mais il demeure le seul concrètement efficace car il identifie le problème chez l'éditeur et permet des relances.

Enfin et pour en finir, quelque soit le problème et la compétence de celui qui le trouve, la place publique pour ce genre de chose dessert tout le monde !
Ces informations certes réelles vont alimenter hors contexte les sempiternelles conversations sur le fait que tel ou tel produit est meilleur ou que celui la est précisément mauvais... et comme vous l'utilisez, vous ne pouvez être crédibles : simple (mais pas facile à intégrer) retour des choses.
Et évidement j'ai le regret de préciser qu'il ne faut oublier que WinDev n'est pas un projet open-source que l'on peut piloter via des xxxZilla. Ce genre de liste posera des problèmes juridique déjà rencontrés il y a quelques années.

Ce n'est qu'un avis qui ne sera pas argumenté plus avant si non partagé.

[Hibernatus34]

J'aimerais éviter que ça tourne au débat, mais je vais quand même répondre.

Ces éléments sont vérifiés mais le ton à charge ne fera pas avancer les choses.

Le but c'est bien de montrer les erreurs grossières. Alors le ton, c'est le bon.

Il est clair que l'adressage dans WinDev est soumis a une abstraction qui permet le transtypage.

Qu'essayez-vous de dire ?

Par exemple sur les sources de données (point 2) [...]Ainsi donc, pour ce sujet seul, que faut-il faire si ce n'est améliorer la documentation ?

La seule solution serait de créer un nouveau type de données.
Dire que c'est lié au fonctionnement de WinDev n'a pas de sens.
Il est tout à fait possible dans WinDev d'avoir un type de données réellement "propriétaire" de la source de données.
Le type "Source de Données" a été mal conçu, ça ne fait pas de mal de le signaler, pour que les autres développeurs l'utilisent avec prudence, mais aussi en espérant, même si c'est peu probable, que PC Soft apporte une correction.

On ne peut se séparer de ce qui fait le produit (RAD, maj automatique des données, IHM liée aux données trés simplement) sans tolérer des limites. On a l'exemple de la vitesse de calcul divisée par 50 par rapport à un compilateur plus strict en raison du transtypage. Mais aussi de notions bas niveau tel que l'adressage et les pointeurs volontairement "floutées" pour plus de facilité d'approche.

Aucun rapport entre ces choses et les problèmes démontrés ici.
Tout ce qui est expliqué ici aurait pu être conçu correctement sans poser de souci.

Ainsi le fait de citer dans une même phrase L5G et adressage de variant pique les yeux. Je ne remet en cause ni les problèmes évoqués ni leurs démonstration mais plutôt l'amalgame entre des notions éloignées qui sort l'information du champ rationnel et fait perdre du crédit au propos.

Le fait d'appeler le WLangage un L5G est ridicule. PC Soft s'obstine à le faire et c'en est devenu un running gag. Maintenant, si vous n'admettez pas une pointe d'ironie...

J'espère donc que chaque problème à été soumis, comme il vient d'être fait ici, au ST par la voie normale.
Je sais que c'est un passage désagréable mais il demeure le seul concrètement efficace car il identifie le problème chez l'éditeur et permet des relances.

J'ai des dizaines de fiches de bugs enregistrées chez PC Soft.
J'ai toujours fourni des projets de repro impeccables, et ici vous ne trouverez que ce qui n'est pas admis comme bug. Je l'explique bien en début de message :

les bugs ou erreurs de conception qui me dérangent dans WinDev et ne semblent pas choquer le support technique, ou sur lesquels il est impossible d'apporter un correctif à cause de la rétrocompatibilité.

Enfin et pour en finir, quelque soit le problème et la compétence de celui qui le trouve, la place publique pour ce genre de chose dessert tout le monde !

Encore une fois, relisez le début de mon message :

Ca permettra d'éviter certains désagréments aux autres développeurs, et ça forcera peut-être PC Soft à réfléchir un peu plus à la qualité, car ça devrait au moins leur faire honte.

Pour finir, dites-moi qu'une conversion de Variant non déterministe est une bonne chose. Cette conversion je la leur ai fait corriger une première fois, car avant la partie heure était aléatoire et pouvait être invalide (comme 42h20 par exemple).
Dites-moi également que les points 4 et 10 ne vous choquent pas...

[Arnaud B.]

Bonjour.
Enfin et pour en finir, quelque soit le problème et la compétence de celui qui le trouve, la place publique pour ce genre de chose dessert tout le monde !
Ces informations certes réelles vont alimenter hors contexte les sempiternelles conversations sur le fait que tel ou tel produit est meilleur ou que celui la est précisément mauvais... et comme vous l'utilisez, vous ne pouvez être crédibles : simple (mais pas facile à intégrer) retour des choses.
Et évidement j'ai le regret de préciser qu'il ne faut oublier que WinDev n'est pas un projet open-source que l'on peut piloter via des xxxZilla. Ce genre de liste posera des problèmes juridique déjà rencontrés il y a quelques années.

Je ne peux pas être plus en désaccord avec cet argument.

C'est tout le contraire.

Mettre sur "la place publique" ce serait néfaste ? Alors là je ne pensais pas lire ça un jour

Au contraire, cela permet :
- aux autres développeurs de prendre connaissance de ces limitations et points de vue, et ainsi d'éviter de perdre du temps à se reposer les mêmes questions
- de valider le constat d'un dysfonctionnement supposé, ce qui permet ensuite de prendre la décision de transmettre le bug au ST.

Quand je pense à toute la compréhension et le temps que j'ai gagné avec le partage d'information des limitations de Windev sur "la place publique"... Je suis content que tous ne partagent pas ta conception.

Pour illustrer cela, un seul exemple : si je n'avais pas lu d'autres posts sur les problèmes de non-conformité SQL des jointures externes avec prédicat, que PC Soft refusait de reconnaitre comme bug :
- j'aurait peut être pensé que j'étais le seul à avoir ce problème
- je n'aurai pas incité d'autres développeurs/sociétés à transmettre également le problème et à faire pression sur PCsoft comme nous l'avons fait (merci Thierry )
- nous n'aurions peut être pas obtenu le résultat suivant : les jointures externes avec prédicat sont désormais conformes à la norme SQL ANSI 92 dans la version 17, alors que ce bug avait été signalé pour la 1ère fois en 2008.

J'espère que cela vous fera méditer.

Quand à l'alimentation d'une liste des bugs/limitations, elle ne pose de problème juridique que dans la mesure où elle est publique et que des affirmations ne sont pas étayées.

Et cela n'a aucun rapport avec l'open source.

C'est le rôle d'un modérateur de faire en sorte en sorte que des propos diffamants ne soient pas tenus, mais cela concerne tous les sites internets, non pas uniquement une liste de bugs.

Par ailleurs, tapez dans google "bugs 4D" et vous verrez une approche de transparence d'un éditeur totalement différente de PCsoft.

Cdlt, Arnaud.

[DelphiManiac]

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

On peut féliciter PC Soft pour cette perle.
dCopieImage prend comme paramètres : X, Y, Hauteur, Largeur, dans cet ordre.
La logique voudrait : X, Y, Largeur, Hauteur.

cela est étonnant c'est un fait, mais ce n'est pas un bug.

[Hibernatus34]

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

Pour être honnête, c'est le seul de la liste sur lequel le support n'a pas définitivement fermé la porte.
Je l'ai signalé il y a seulement 1 mois et le type du support a répondu en gros qu'il en parlerait à un développeur pour voir si c'est vraiment un bug.
Je l'ai mis quand même dans la liste parce que c'est mon "préféré" et surtout parce qu'il est invraisemblable de trouver un tel bug après tant d'années d'existence.

Les 2 autres qui me choquent le plus sont le 1 et le 10, et ceux-là ont été signalés et refusés il y a pas mal de temps.
Là où j'ai été consterné, c'est sur le point 1, quand ils ont "corrigé" un bug que j'ai signalé sur VariantConvertit pour générer un comportement toujours aussi indésirable et illogique : on est passé de (Date + garbage) à (Date + heure actuelle). Quel sens a l'heure actuelle quand elle est associée à une autre date qu'aujourd'hui ? A part WinDev, combien de langages ont des conversions de données non déterministes ?

Pour en revenir à la comparaison avec Null (point 4), c'est pas forcément une question évidente.
Null signifie une absence de valeur, et ça peut causer une logique un peu particulière.

Si on regarde NaN, en C++ par exemple, x <= 1.0 n'est pas 100% équivalent à !(x > 1.0), et x != x peut être vrai !

Si on prend l'exemple de NULL en SQL, toute expression ayant une opérande NULL vaut NULL, et dans une condition, NULL est équivalent à FALSE. Donc IF NULL = 0 fait la même chose que IF NULL <> 0 ou IF NOT NULL = 0.

On peut aussi regarder du côté des Variants d'autres langages. Mais aucun n'aura le même comportement délirant que WinDev !

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

Non, justement.
Je veux parler des erreurs de conception ou des bugs pour lesquels on nous répondra "c'est ainsi".
"It's not a bug, it's a feature." C'est justement ce que je ne veux pas entendre.
L'inversion des paramètres Largeur/Hauteur aura sûrement causé pas mal de bugs chez des développeurs trop habitués à des fameworks mieux conçus !

Je ne publie pas mes fiches de bug en attente, c'est complètement autre chose. (à part le point 4, peut-être, mais je ne sais pas s'ils le prendront réellement en compte)

[DelphiManiac]

Je suis désolé d'insister, mais les 2 points abordés n'ont rien avoir un avec l'autre.

Un bug est un bug, un dysfonctionnement auquel il faut apporter une solution ou une réponse. C'est objectif.

Un souci de conception est une question purement subjective et n'a rien avoir avec un bug. Ce point risque d'être perturber par énormément de troll.

Mélanger les 2 problèmes ne risque à terme que d'apporter le discrédit à cette démarche. De là, je ne soutien pas qu'il ne faut pas parler des questions concernant la conception, mais cela doit faire l'objet d'un sujet différent.

[Hibernatus34]

Je suis désolé d'insister, mais les 2 points abordés n'ont rien avoir un avec l'autre.

Un bug est un bug, un dysfonctionnement auquel il faut apporter une solution ou une réponse. C'est objectif.

Un souci de conception est une question purement subjective et n'a rien avoir avec un bug. Ce point risque d'être perturber par énormément de troll.

Mélanger les 2 problèmes ne risque à terme que d'apporter le discrédit à cette démarche. De là, je ne soutien pas qu'il ne faut pas parler des questions concernant la conception, mais cela doit faire l'objet d'un sujet différent.

Vous savez mieux que moi de quoi je souhaitais parler en ouvrant cette discussion ? C'est fort.

Si vous souhaitez parler de bugs "classiques", ouvrez un nouveau sujet. Mais je vous conseille plutôt d'en discuter directement avec le support, comme je le fais régulièrement.

Je le répète, ce qui m'intéresse ce sont ces points qu'on ne peut pas simplement faire corriger par le support, les erreurs de conception commises par PC Soft quand ils n'ont pas suffisamment réfléchi avant de créer une fonctionnalité, et qu'on se traine à vie.

Aucun des ces points n'est un bug à corriger selon PC Soft. Le 4 sera peut-être reconnu bientôt, mais c'est tout.

Un souci de conception est une question purement subjective et n'a rien avoir avec un bug.

Donc si je vous suis, PC Soft a fait le choix mettre Hauteur avant Largeur, un choix valable parmi d'autres.
Mais il ont changé d'avis pour la fonction dTransfertVersImage, par exemple.
Juste une question de point de vue, et il n'est pas permis de considérer ça comme une faute.

[Arnaud B.]

Un bug est un bug, un dysfonctionnement auquel il faut apporter une solution ou une réponse. C'est objectif.

Un souci de conception est une question purement subjective et n'a rien avoir avec un bug.

Je suis d'accord que bug et erreur de conception ne sont pas la même chose.

En revanche, je ne suis pas du tout d'accord pour dire qu'on peut objectivement distinguer les deux ! Ce serait si simple si c'était le cas...
Tout va dépendre du point de vue de celui qui a faire face à la difficulté.

Qu'est ce qu'un bug pour vous ? Un non-respect d'une spécification d'un cahier des charges ?
Mais il n'y a pas de cahier des charges dans le cas de Windev !
Dans certains cas, on ne peut que supposer les intentions de l'éditeur, et l'aide malheureusement n'est pas toujours très loquace.

Je prends juste un point que j'ai en tête, sur lequel je viens de tomber hier :
soit une fenêtre avec plusieurs champs "Modèles de champs" insérés à partir du même modèle. Chaque champ "Modèle de champs" contient un libellé de même nom (seul le nom du champ "Modèle de champs" diffère donc).

Dans l'init. de la fenêtre, on fait une indirection sur le libellé :

Code :

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

 {sNomLibellé, indChamp} = "toto".

(sNomLibellé contient le nom du libellé, sans préciser le nom du champ parent)

Logiquement, Windev devrait me signaler une ambiguïté qu'il ne peut pas résoudre, car à quel champ "Modèle de champs" appartient ce libellé? (je rappelle qu'il y en a plusieurs).
Comment peut il deviner à quel libellé je fais référence !?

Hé bien, pourtant Windev ne vous dira rien et affectera la valeur "toto" à un des libellés.

Alors est ce un bug du compilateur ? une erreur de conception ? un manque dans l'aide ? une fonctionnalité intéressante de tirage au sort de champs à affecter ?

[Hibernatus34]

Logiquement, Windev devrait me signaler une ambiguïté qu'il ne peut pas résoudre, car à quel champ "Modèle de champs" appartient ce libellé? (je rappelle qu'il y en a plusieurs).
Comment peut il deviner à quel libellé je fais référence !?

Hé bien, pourtant Windev ne vous dira rien et affectera la valeur "toto" à un des libellés.

Alors est ce un bug du compilateur ? une erreur de conception ? un manque dans l'aide ? une fonctionnalité intéressante de tirage au sort de champs à affecter ?

C'est vrai que c'est surprenant, mais ça me paraît assez discutable.

Comme il s'agit d'une indirection, l'erreur ne peut être détectée qu'à l'exécution, parfois dans un cas rare et non testé (donc chez l'utilisateur final !).
Le seul moyen pour WinDev de signaler l'ambiguité serait une exception, donc dans 99% des cas un "plantage" (du point de vue de l'utilisateur final).
Il vaut peut-être mieux que ça ait une chance de "tomber en marche", et éventuellement que l'ambiguité soit signalée à l'audit dynamique.

Ensuite, on peut essayer de comprendre pourquoi ils permettent de référencer le champ sans préciser son conteneur.
Probablement pour laisser un peu de souplesse et permettre de réutiliser du code à plusieurs endroits sans se soucier du contexte (le code est-il exécuté dans le contexte de la fenêtre ou du modèle ? etc.).
C'est pas toujours propre, mais c'est un choix de WinDev : dans les cas usuels, admettre qu'une info soit implicite.

[tatayo]

Bonjour,
Je ne comptais pas prendre part à la discussion, mais là je ne suis pas du tout d'accord:

C'est vrai que c'est surprenant, mais ça me paraît assez discutable.

Comme il s'agit d'une indirection, l'erreur ne peut être détectée qu'à l'exécution, parfois dans un cas rare et non testé (donc chez l'utilisateur final !).
Le seul moyen pour WinDev de signaler l'ambiguité serait une exception, donc dans 99% des cas un "plantage" (du point de vue de l'utilisateur final).
Il vaut peut-être mieux que ça ait une chance de "tomber en marche", et éventuellement que l'ambiguité soit signalée à l'audit dynamique.

Ensuite, on peut essayer de comprendre pourquoi ils permettent de référencer le champ sans préciser son conteneur.
Probablement pour laisser un peu de souplesse et permettre de réutiliser du code à plusieurs endroits sans se soucier du contexte (le code est-il exécuté dans le contexte de la fenêtre ou du modèle ? etc.).
C'est pas toujours propre, mais c'est un choix de WinDev : dans les cas usuels, admettre qu'une info soit implicite.

Je préfère largement que mon application "plante", ce qui dans l'exemple cité arrivera au premier test, qu'une application qui fait "un peu n'importe quoi" sans avertir.
Le debugage de l'application n'en sera que plus facile.

Tatayo.

[michel.souris]

Je préfère largement que mon application "plante", ce qui dans l'exemple cité arrivera au premier test, qu'une application qui fait "un peu n'importe quoi" sans avertir.
Le debugage de l'application n'en sera que plus facile.

Tatayo.

Je suis entièrement d'accord avec toi... et c'est bien ce que je reprocherais à Windev d'une manière générale...

Un vieil exemple: val("0.1") renvoi 0... j'aurais préféré que ça plante... ça m'a faussé des stats et avant que je comprenne d'où ça venait...

[Hibernatus34]

Bonjour,
Je ne comptais pas prendre part à la discussion, mais là je ne suis pas du tout d'accord:


Je préfère largement que mon application "plante", ce qui dans l'exemple cité arrivera au premier test, qu'une application qui fait "un peu n'importe quoi" sans avertir.
Le debugage de l'application n'en sera que plus facile.

Tatayo.

Moi aussi, en réalité.
Mais c'est un choix réellement discutable. D'ailleurs c'est une question qui concerne tous les développeurs de tous les langages et qui dépend souvent du type de projet.

Un autre exemple que je viens de trouver :

Code :

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

1
2
3
4
xToto est numérique = 0n1 / 0n0  // Donne 0n0 (WD <= 17)
rToto est réel = 1.0 / 0.0 // Exception
nToto est entier = 1 / 0 // Exception
mToto est monétaire = 0m1 / 0m0 // Exception

Celui-là me paraît moins discutable, ceci dit.

PS. Ah, c'est corrigé en 18 (bug trouvé sous WD17)

[michel.souris]

puisque tout le monde se lâche... y a un autre truc que je calcule même plus mais qui est complètement délirant je trouve... la gestion des OR et des AND

Pour avoir un "vrai" OR dans le sens "traditionnellement optimisé" il faut faire un _OR_ afin que le second test ne soit effectué que si le premier n'est pas vérifié... et de même avec un AND... donc un _AND_... chelou !!!

On parlera du passage des paramètres par référence par défaut une autre fois !

Bien sûr, c'est des choix, des orientations mais pas des bugs mais des orientations franchement discutables....

[Hibernatus34]

Le comportement par défaut, du moment qu'on a le choix c'est pas très grave.

Concernant le _ET_ et _OU_, ce n'est plus intuitif que pour ceux qui ont déjà de l'expérience dans un autre langage.
Ce qui me choque un peu plus c'est la précédence entre ET et OU qui n'est pas définie :

Code :

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

SI A ET B OU C ALORS

N'est pas équivalent à :

Code :

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

SI C OU A ET B ALORS

Quand on mélange le ET et le OU, les parenthèses sont obligatoires.

Il me semble qu'en algèbre de Boole (sur papier) il est communément admis que A+B.C équivaut à A+(B.C). Donc ça pourrait être mon point n° 11, non ?
(cf. Wikipédia, chapitre "Priorité")

[michel.souris]

Il me semble qu'en algèbre de Boole (sur papier) il est communément admis que A+B.C équivaut à A+(B.C). Donc ça pourrait être mon point n° 11, non ?
(cf. Wikipédia, chapitre "Priorité")

Oui.... c'est sûr, ça peut être un point 11 !

En ce qui concerne ma remarque j'admets volontiers que c'est pas grave et contournable... je calcule même plus mais je fais que _OR_ et des _AND_ mais je trouve quand même que le comportement par défaut ne soit pas le comportement optimal... tu me diras on n'est plus à ça près !

Et tu penses quoi du passage par référence plutôt que par valeur ? c'est contournable aussi () mais quand même je me fais souvent baiser...

[Hibernatus34]

Et tu penses quoi du passage par référence plutôt que par valeur ? c'est contournable aussi () mais quand même je me fais souvent baiser...

Ce n'est pas un passage par référence au sens où on l'entend habituellement, c'est plus proche d'une indirection avec {}, en réalité.

Par exemple :

Code :

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

1
2
3
4
5
6
7
8
PROCEDURE Toto(MonParam)
Trace(MonParam..Nom) // Champ ou rubrique (sans guillemets)
Trace(MonParam[MonParam].COL_Colonne1) // Champ table
Trace(MonParam[1, 2]) // Tableau à 2 dimensions
Trace(MonParam / 3.0) // Variable, champ de saisie, etc. mais numérique
MonParam..Couleur = Blanc // Champ de fenêtre ou d'état
MonParam["Bob"] = "Bill" // Tableau associatif
Transfert(&MonParam, "John", 4)

Tout ça pourra fonctionner selon le type d'objet passé : champ, rubrique de l'analyse, perso-dossier de l'analyse, variable simple, instance de classe, type avancé...

C'est plus puissant et plus souple que ça en a l'air. WD est à mi-chemin entre le langage strict façon Java, et un langage de scripting où des raccourcis monstrueux sont possibles. Personnellement ça me plaît, mais seulement quand tous les développeurs d'un projet sont bien au courant de tout ça.
Très souvent, j'utilise "LOCAL" pour mes paramètres, et j'aime bien avoir les 2 fonctionnements à dispo.

Cependant, voici un exemple bien méchant des problèmes que ça peut poser :

Code :

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

1
2
3
4
5
6
PROCEDURE AfficheValeur(MaValeur)
HLitDernier(Bob, Val)
// On ne prend pas une valeur supérieure au maxi de la base
SI MaValeur <= Bob.Val ALORS
    SAI_Valeur = MaValeur 
FIN

Code :

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

1
2
3
// On démarre avec la plus petite valeur de la base
HLitPremier(Bob, Val)
AfficheValeur(Bob.Val)

Quel est le problème de ce code ?

Réponse : (sélectionnez)
Bien qu'aucune écriture soit faite dans MaValeur en apparence, la fonction AfficheValeur() la modifie quand elle exécute HLitDernier(Bob, Val), car le mot "MaValeur" est alors un véritable alias de "Bob.Val"

[Emmanuel Lecoester]

IMPORTANT
En parcourant les posts je suis surpris par une phrase "vu que tout le monde se lache"

Nous laissons ce post ouvert pour que les développeurs fassent part des bugs reconnus et reproductibles facilement ou des points qui méritent l'attention du développeur.

Si il advenait que ce fil serve de défouloir et finisse en troll, nous devrions revoir notre vision.

Merci

[Emmanuel Lecoester]

Le comportement par défaut, du moment qu'on a le choix c'est pas très grave.

Concernant le _ET_ et _OU_, ce n'est plus intuitif que pour ceux qui ont déjà de l'expérience dans un autre langage.
Ce qui me choque un peu plus c'est la précédence entre ET et OU qui n'est pas définie :

Code :

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

SI A ET B OU C ALORS

N'est pas équivalent à :

Code :

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

SI C OU A ET B ALORS

Quand on mélange le ET et le OU, les parenthèses sont obligatoires.

Il me semble qu'en algèbre de Boole (sur papier) il est communément admis que A+B.C équivaut à A+(B.C). Donc ça pourrait être mon point n° 11, non ?
(cf. Wikipédia, chapitre "Priorité")

Je ne connais pas de prof qui conseille de laisser faire la machine quand on commence à imbriquer des ET et des OU : à chaque fois et ce quelque soit le langage et le niveau du développeur (débutant ou confirmé) on insiste sur le parenthèsage.