Discussion :

[michel.souris]

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

T'inquiètes, c'est juste une expression... le contenu est plein de retenu... non ?

[Hibernatus34]

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.

En général chaque développeur connaît l'avis d'un ou deux profs sur cette question, et c'est un domaine beaucoup moins normé que les maths et donc où l'avis des profs est aussi subjectif que celui d'un développeur confirmé.

Personnellement, je connais pas mal de développeurs (profs compris) qui ont pour règle de ne jamais écrire de parenthèses inutiles, au moins quand une série d'opérateurs est homogène (par exemple en C : (&&, ||, !) ou (|, &, ^, ~) ou encore (*, /, -, +, %)).
Des parenthèses en trop peuvent alors faire apparaître un oubli, une faute de frappe... mais c'est pas le but premier, ce dernier étant seulement d'avoir une seule manière d'écrire une expression, ordre des opérandes mis à part.

Ceux-là n'écriront jamais x = y + (3 * z), ni même if ((x > 1 && y > 1) || (z > 1 && t > 1)). Moi non plus, d'ailleurs (sauf en WinDev, évidemment).

Quoi qu'il en soit il est possible d'écrire sans parenthèses dans WinDev, et dans ce cas, ça ne respecte pas la règle commune. C'est donc bien une faute.

PS. J'ai mis la réponse à mon petit exemple dans le post ci-dessus.

[Hibernatus34]

Allez, j'ai la flemme de le signaler comme bug.
En voici encore un bien gratiné et très ancien :

Code :

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

1
2
3
4
5
6
7
8
9
taValeursUniques est tableau associatif (*, *, wlEntier) de booléens
 
POUR j = 1 A 10
	TableauSupprimeTout(taValeursUniques)
	POUR i = 1 A 1000000
		taValeursUniques[Hasard(1, 100000)] = Vrai
	FIN
	Trace(TableauOccurrence(taValeursUniques))	// Affichera toujours 32768 valeurs uniques
FIN

Et oui, le tirage d'un nombre entre 1 et 100000 ne concerne que 32768 valeurs, les autres on s'en fiche !
Incroyable, non ?

Explication plausible : Hasard se baserait sur rand en C, qui va normalement de 0 à 32767. Ce qui n'empêche pas la doc de WinDev d'affirmer qu'on peut demander un intervalle de 0 à 2 milliards... c'est gonflé.

[mail.spam]

Bonjour,

Pour la fonction hasard c'est normale dans le sens où cette fonction est documenté et voici l'explication.

[Hibernatus34]

Bonjour,

Pour la fonction hasard c'est normale dans le sens où cette fonction est documenté et voici l'explication.

Je ne vois pas l'explication sur cette doc. Sauf pour la version WebDev navigateur où ils auraient pourtant pu avoir le même comportement, puisque la fonction utilisée en interne a les mêmes limites.

[tatayo]

En fait c'est plus sioux, car une boucle "prouve" le contraire:

Code :

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

1
2
3
4
5
6
 
nCompteur est un entier
 
POUR nCompteur = 1 A 10000
	Trace(Hasard(1,100000))
FIN

J'ai bien des nombres entre 1 et 100000.

Le problème semble donc venir du tableau associatif, et non de Hasard().

Tatayo.

[mail.spam]

Voici la note de l'aide mise en lien

Noyau aléatoire
Le "noyau" dans lequel le nombre aléatoire est "choisi" peut être initialisé par la fonction InitHasard.
Si la fonction InitHasard n'est pas appelée, les valeurs aléatoires générées par la fonction Hasard seront les mêmes à chaque exécution du programme.

[Hibernatus34]

En fait c'est plus sioux, car une boucle "prouve" le contraire:

Code :

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

1
2
3
4
5
6
 
nCompteur est un entier
 
POUR nCompteur = 1 A 10000
	Trace(Hasard(1,100000))
FIN

J'ai bien des nombres entre 1 et 100000.

Le problème semble donc venir du tableau associatif, et non de Hasard().

Tatayo.

Mon problème c'est qu'il y a des nombres qui ne sortiront jamais.
Exemples : 2, 3, 5, 6, 8, 9 etc.

Si en plus on parle de distribution uniforme... alors là...

[Hibernatus34]

Voici la note de l'aide mise en lien

Je fais 10 boucles, et les 10 ont le même nombre de résultats identiques. Je me fiche bien qu'au début de ma fonction le point de départ soit toujours le même.
Ajoutez un InitHasard si vous voulez, ça ne changera rien.

[mail.spam]

ok je comprend.
L'aide devrais indiquer que la limite de la borne maximale (on devrais même dire l'écart antre la borne min et max) n'est pas que pour Webdev Code navigateur mais bien pour toute la série de PC-Soft.

[tatayo]

Mon problème c'est qu'il y a des nombres qui ne sortiront jamais.
Exemples : 2, 3, 5, 6, 8, 9 etc.

Si en plus on parle de distribution uniforme... alors là...

Effectivement, je ne l'avais pas compris ainsi.

Je viens de refaire un test rapide:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
nCompteur est un entier
nNombre est un entier
 
POUR nCompteur = 1 A 1000000
	nNombre = Hasard(1,65536)
	SI nNombre < 10 ALORS
		Trace(nNombre)
	FIN
FIN

Je n'obtiens que 1,3,5,7 et 9 (dans le désordre). Avec 131072 je n'ai que 1,5 et 9, et avec 262144 je n'obtiens plus que 1 et 9...

C'est bon à savoir.

Tatayo.

[mail.spam]

Bonjour,

Pour le point 1 de Hibernatus34 au sujet des dates il est vrai que Par défaut, les variables de type Date, Heure et DateHeure sont initialisées avec l'heure et la date système au moment de l'exécution du programme. et que pour changer ce comportement il faut utiliser DateHeureParDéfaut
(ça ne change rien au problème d'utilisation avec un variant)

Pour les opérateurs logiques il y a une info dans l'aide http://doc.pcsoft.fr/fr-FR/?1512003&...TSPECIAL000116

Je ne dis pas que c'est normale, je dis juste que les fonctions sont documentées.
Ensuite d'autres logiciels ont leurs contraintes de programmation.

[Hibernatus34]

Bonjour,

Pour le point 1 de Hibernatus34 au sujet des dates il est vrai que Par défaut, les variables de type Date, Heure et DateHeure sont initialisées avec l'heure et la date système au moment de l'exécution du programme. et que pour changer ce comportement il faut utiliser DateHeureParDéfaut
(ça ne change rien au problème d'utilisation avec un variant)

Pour les opérateurs logiques il y a une info dans l'aide http://doc.pcsoft.fr/fr-FR/?1512003&...TSPECIAL000116

Je ne dis pas que c'est normale, je dis juste que les fonctions sont documentées.
Ensuite d'autres logiciels ont leurs contraintes de programmation.

Je sais ça, mais ça ne change rien, pour plusieurs raison :

1. La partie heure d'un DateHeure est relative à la partie date. Ainsi, 13h20 le 2 janvier n'a aucun lien avec 13h20 le 5 février. Ainsi, quand j'affecte à un DateHeure une Date, c'est un cast implicite puis une copie, et je devrais écraser le DateHeure complet (sémantique de valeur).
Ce que je veux dire par là, c'est que l'heure présente avant la copie ne devrait pas rester là, car elle n'a plus aucun sens, et donc on se fiche de sa valeur par défaut.

2. Une conversion de valeur devrait toujours être déterministe :

Code :

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

1
2
PROCEDURE Toto(LOCAL dhDate est DateHeure)
RENVOYER DateHeureDifférence(dhDate, gdhDateRéférence)

Code :

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

1
2
3
4
dDate est Date = "20130101"
Trace(Toto(dDate))
Multitâche(100)
Trace(Toto(dDate)) // N'affiche pas pareil que la 1ère fois !

3. Pour changer uniquement la partie date, il existe un moyen explicite :

Code :

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

dhDateHeure..PartieDate = dDate

Sur ce point, je n'ai aucun doute, le fonctionnement actuel est parfaitement illogique, et inexcusable.

PS. Je viens de trouver un argument plus clair et percutant :

Code :

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

1
2
3
rToto est un réel = 42.51
nBob est un entier = 8
rToto = nBob

rToto doit contenir 8.51 ou 8.0 ?
Pour un DateHeure c'est pareil.

[OnePoint]

Bonjour,

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.

[...]

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.

[...]

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

Personnellement, je préfèrerai qu'un éditeur s'implique pour fournir une liste de bugs.

J'ai regardé le "BugDisplayer 4D" à l'adresse http://www.bugs.4d.fr.
Hélas, il n'est pas si transparent que ça, car en "accès libre" on ne peut voir que quelques bugs corrigés.
Il y a un accès avec autorisation qui doit sans doute donner plus de visibilité.

Autre exemple avec Microsoft.
A plusieurs reprises recherchant sur le web la cause de fonctionnement bizarre ou plantage, je suis tombé sur des pages de la "Knowledge Base" Microsoft qui décrivaient le problème et annonçaient clairement que c'était un bug, soit pas encore corrigé, avec parfois la marche à suivre pour le contourner (en attendant), soit déjà corrigé avec un lien vers le correctif ou le Service Pack.

Je suis convaincu qu'une liste publique de bugs est vitale pour les concepteurs/développeurs...
Prendre un axe technique pour un développement et au bout constater qu'il y a un bug, fait perdre non seulement du temps et de l'énergie, mais aussi de la crédibilité vis à vis de ceux à qui le développeur rend des comptes.

Nous, "les clients de PC SOFT", pouvons comprendre que leurs produits ne soient pas exempts de bug.
Nous même avons notre part de bugs dans nos propres développements.

Alors une liste publique de bugs c'est déjà un moindre mal et offre des avantages.
(1) avantage pour le développeur qui n'a plus à signaler le bug si déjà répertorié, ni à fournir un projet de démonstration du bug (ouf !), et qui peut aussi éviter les bugs connus.
(2) avantage pour le Service Technique de PC SOFT qui n'a plus à suivre des signalements redondants du même bug.

C'est juste du bon sens.

[OnePoint]

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 ?

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.

Pour ma part, c'est la mise en avant de l'indirection "bonne à tout faire" que je remets en cause.

Dans l'exemple donné par Arnaud, une hiérarchie de types d'objets graphiques (Fenêtre, Champ) permettrait bien plus d'efficacité et de robustesse que la "rustine" indirection du WLangage.

[Arnaud B.]

Sinon, pour en revenir au sujet de départ, et si l'on parle de manques ou d'erreurs de conception, je dirai que la limitation la plus importante de windev à mon humble avis est l'impossibilité d'accéder/manipuler les classes de windev.

Par exemple, impossible de manipuler les fenêtres autrement que par les fonctions disponibles Ouvre(), etc...
Donc du coup impossibilité de dériver l'objet fenêtre de windev, et d'y ajouter ses propres méthodes, etc...

Si l'on veut créer des classes qui manipulent des objets windev de manière générique, on est obligé de passer par le nom de l'objet (du champ par exemple) et de fonctionner avec les indirections.
C'est lourd lourd...

Perso., je me heurte tous les jours à cette limitation.

[tatayo]

Sinon, pour en revenir au sujet de départ, et si l'on parle de manques ou d'erreurs de conception, je dirai que la limitation la plus importante de windev à mon humble avis est l'impossibilité d'accéder/manipuler les classes de windev.

Par exemple, impossible de manipuler les fenêtres autrement que par les fonctions disponibles Ouvre(), etc...
Donc du coup impossibilité de dériver l'objet fenêtre de windev, et d'y ajouter ses propres méthodes, etc...

Si l'on veut créer des classes qui manipulent des objets windev de manière générique, on est obligé de passer par le nom de l'objet (du champ par exemple) et de fonctionner avec les indirections.
C'est lourd lourd...

Perso., je me heurte tous les jours à cette limitation.

J'en avais parlé à un formateur WinDev il y a quelques années (ça remonte à la 15), et la seule réponse que j'ai eut était "Mais WinDev n'est pas un langage objet."... Attendons Windev++

Tatayo.

[lazariel]

J'en avais parlé à un formateur WinDev il y a quelques années (ça remonte à la 15), et la seule réponse que j'ai eut était "Mais WinDev n'est pas un langage objet."... Attendons Windev++

Tatayo.

E-Norme ! Si Windev n'est pas un langage objet, pourquoi peut-on faire de la POO avec alors ? Ca n'a strictement aucun sens !

Merci pour ces remontées ! Encore heureux qu'il y ait quelques canaux parallèles permettant de voir ce qui se trame ouvertement. Et cela permet surtout de connaître "ce qu'il y a sous le capot", même si je m'en doutais pour la plupart des choses...

[OnePoint]

Donc du coup impossibilité de dériver l'objet fenêtre de windev, et d'y ajouter ses propres méthodes, etc...

On peut considérer que ce besoin est envisagé "dans l'autre sens", avec les modèles: modèles de champs, de fenêtres, de pages et d'états.

Par l'héritage, un modèle permet "d'injecter" des fonctionnalités génériques dans d'autres objets d'IHM.

Ainsi, il est possible d'hériter et de surcharger tes propres objets d'IHM.

Si l'on veut créer des classes qui manipulent des objets windev de manière générique, on est obligé de passer par le nom de l'objet (du champ par exemple) et de fonctionner avec les indirections.
C'est lourd lourd...

... et source d'erreurs, comme déjà dit plus haut dans la discussion.

Perso., je me heurte tous les jours à cette limitation.

[Hibernatus34]

En même temps le formateur n'a pas tout à fait tort. WinDev n'est pas C# ou Java, sinon ça n'aurait aucun intérêt. C'est ça qu'il voulait probablement dire.