Bugs et erreurs de conception de WinDev

**Hibernatus34** · 15/04/2013, 14h32

C'est un mauvais exemple, puisque si ça dépend de données utilisateur alors on ne veut pas d'un stack overflow. Donc c'est au développeur de coder ça de manière robuste. D'ailleurs un développeur suffisamment naïf pour faire ça en récursif ne penserait probablement pas aux dépendances cycliques. (testez dans l'exemple de la LST, vous verrez que ça plantera)
Les applis WinDev tournent dans une machine virtuelle, donc utiliser la stack (et l'utiliser à fond) ne fait pas partie du contrat.
La pile des appels pourrait être sur le tas, et elle pourrait être plus "lourde" que vous pensez.

Et pour répondre à la question de la limite : dans un logiciel comme Excel je m'attends à une limite bien au-delà de 600, mais aussi à un algo optimisé et robuste, pas naïf.

PS. Je voudrais quand même signaler que je viens de tester cette fameuse limite à 600 et qu'elle ne semble pas exister. En réalité on a un plantage, dans mon cas à 489 itérations, sous WD17 en Exe compilé 32 bits. A 246 sur un autre projet, même code, sous WD18 en Exe. Et ça semple être la profondeur d'appel, toutes fonctions confondues.

**tatayo** · 15/04/2013, 15h31

Je dirai plutôt que la pile est limitée, donc la profondeur dépend de ce que le programme met dans la pile (donc de l'occupation mémoire des paramètres et de la "tambouille interne" de Windev).

Tatayo.

**Tober** · 15/04/2013, 15h48

Envoyé par Hibernatus34

PS. Je voudrais quand même signaler que je viens de tester cette fameuse limite à 600 et qu'elle ne semble pas exister. En réalité on a un plantage, dans mon cas à 489 itérations, sous WD17 en Exe compilé 32 bits. A 246 sur un autre projet, même code, sous WD18 en Exe. Et ça semple être la profondeur d'appel, toutes fonctions confondues.

Moi j'ai fais une petite fonction qui ne fait rien et j'obtiens bien la limite de 600 exactement

**mail.spam** · 15/04/2013, 15h53

Bonjour.

Donc OnePoint vous n'avez jamais été confronté à ce problème qui pourtant à l'air de vous tenir à cœur. Il y des limitations pour chaque logiciels de développement et pour chaque langage.
Il est facile de trouver des exemples quand on connais le problème.
Le but de cette discussion est, et je le répète encore une fois, Bugs et erreurs de conception de WinDev. Si vous relisez les premiers messages le but est de dire qu'il y a des comportement pas "logique" et qu'il faut y faire attention.

Une limite d'un langage n'est en rien un problème, c'est une limite.

et pour faire une comparaison dont j'ai le secret afin de répondre à OnePoint

Et il s'agit de savoir au "nom de quoi" cette fonctionnalité est bridée, parce que techniquement WinDev/WLangage est capable.

Il s'agit de savoir au "nom de quoi" la vitesse est limité à 130 sur les autoroutes de France alors que ma voiture peux aller plus vite.

Oui c'est null mais j'aime bien.

**Hibernatus34** · 15/04/2013, 16h14

Envoyé par tatayo

Je dirai plutôt que la pile est limitée, donc la profondeur dépend de ce que le programme met dans la pile (donc de l'occupation mémoire des paramètres et de la "tambouille interne" de Windev).

Tatayo.

Oui, très probablement.

J'ai essayé de faire grossir l'usage de la supposée "pile" (plus de paramètres, paramètres locaux, variables locales), mais ça n'a pas changé le nombre de récursions avant plantage.
J'ai aussi doublé la taille de la pile de l'exe, ça n'a rien changé.

Ca semble être une limite fixée (genre tableau fixe), mais dans ce cas pourquoi ça semble être divisé par 2 en WD18 ? Peut-être un allocator de taille fixe servant uniquement à la pile des appels, et l'objet stocké dedans qui a doublé de volume entre WD17 et WD18.

Tober : Dans quelle version ? C'est peut-être un bug de WD17/18.

Voici du code à tester :

Code :

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

1
2
3
4
5
PROCEDURE TestRécursion(i = 1)
nFic est entier = fOuvre("r.txt", foAjout)
fEcritLigne(nFic, "" + i)
fFerme(nFic)
TestRécursion(i + 1)

Code :

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

1
2
fSauveTexte("r.txt", "")
TestRécursion()

Puis ouvrir r.txt dans le répertoire Exe pour voir jusqu'où c'est allé.

PS. Maintenant j'ai "votre code a causé un dépassement de la pile d'exécution". Ca dépend, mais je ne sais pas de quoi. En revanche ça reste à 258 niveaux d'appel.

**Tober** · 15/04/2013, 16h17

En faisant mon projet de test, je suis tombé sur un bug de l'interface : quand on est dans un projet vierge, et qu'on veut créer une procédure globale, je suis allé dans le code du projet, j'ai fais clique droit > créer une procédure globale vide > là, WinDev me demande gentillement dans quel collection de procédure ?
Mon projet étant vide, je n'en ai pas, mais je fais quand même OK au cas où il me demande d'en créer une... Bref plantage de l'application.

Sinon, je sais pas si on peut classer ça en erreur de conception, mais dans le GDS (gestion des sources), j'essaye depuis un moment d'exporter mes modifications, les commentaires, ...
Aux dernières nouvelles c'est impossible... (à part version par version et éléments par éléments, ce qui prendrait un temps infini)

Enfin bref, je trouve le GDS encore beaucoup trop limité/simpliste.

Edit : Pour la version utilisée, je suis en WinDev 16 (et vue tout ce que je vois sur le forum pour la v17/18, j'y suis pour lontemps

)
Mais j'ai pas fais d'écriture de fichier, c'est ça qui doit plomber tes tests.
J'ai fais une récursion du genre :

Code incomplet... :

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

1
2
Procédure Iteration()
renvoyer Iteration() + 1

Donc le plus simple possible...

**DelphiManiac** · 16/04/2013, 10h25

Et ce qui était prévisible est arrivé, discutions sur des points autres que des bugs, vue subjective et argument tout autant :/

**Arnaud B.** · 16/04/2013, 19h27

Envoyé par DelphiManiac

Et ce qui était prévisible est arrivé, discutions sur des points autres que des bugs, vue subjective et argument tout autant :/

Ce qui ne rend pas la discussion moins intéressante pour autant

Invité · 08/11/2013, 10h15

Pas de discussion là-dessus depuis le mois d'avril?

Pourtant tout n'a pas encore été dit.

J'en ai un qui est pas mal : lorsqu'un thread s'exécute, il se retrouve complètement bloqué dès qu'un menu contextuel qui n'est pas au look système est ouvert avec la fonction "OuvreMenuContextuel". Notamment, les threads sont bloqués lors du code du traitement de clic de l'une des options du menu contextuel, ce qui est gênant si on veut faire une syncro avec des "threadattend"...

J'ai du insisté lourdement auprès de PC soft avant qu'ils ne me fournissent un correctif. De plus, ils n'ont pas encore fait de release officiel contenant ce correctif et ça semble bien parti pour qu'il ne soit pas disponible avant la version 19.

J'ai vraiment été étonné que personne ne s'en soit rendu compte avant car ça trainait depuis au moins la version 17, peut-être même 16 (je me suis mis à windev seulement à partir de la v17). De nos jours, l'exécution parallèle devient de plus en plus importante!

Plus généralement je trouve que PC soft a un bon train de retard sur la facilité de programmation avec les threads ainsi que leur fiabilité. Je dis ça car je connais actuellement les tâches avec le Framework dotnet et je peux vous dire que c'est BEAUCOUP plus fiable et beaucoup plus pratique avec le Framework dotnet qu'avec le Framework windev, car j'ai eu pas mal d'autres comportements bizarre avec les threads sous windev que je n'aurais jamais imaginé avoir. L'explication principale de ces anomalies, à mon avis, c'est la possibilité de manipuler des objets d'IHM en dehors du thread principal qui est une hérésie...

**WDKyle** · 08/11/2013, 10h29

Oui ! J'ai eu ce problème avec les menu contextuels...

C'est très grossier comme bug en plus... Bref, j'ai du faire autrement

Invité · 08/11/2013, 10h39

Ah oui, et un autre encore très fun qui nous a fait perdre beaucoup de temps:

à un moment donné, on n'arrivait plus du tout à ouvrir états et requêtes v18 avec notre projet. On a testé sur la version 17 et ça fonctionnait... Après que le support technique ait regardé notre code (parce que sur le coup on avait commencé à ouvrir une demande de support technique payant) ils nous ont dit qu'en fait c'est parce que nous avions utilisés des énumérations dans notre projet (nouveauté de WinDev 18) et ce n'était pas encore supporté par "états et requêtes" v18. Incroyable! Et en plus rien n'indiquait que les énumérations n'étaient pas supportées dans leur documentation, et ça ils l'ont bien reconnu.

Heureusement, ils ne nous ont rien fait payer.

Mais cela est bon à savoir quand même si vous aussi vous rencontrez ce problème.

**michel.souris** · 08/11/2013, 10h46

Rien à voir mais j'ai perdu un temps monstre à cause de la fonction XMLVersTexte qui ne décode pas certains caractère (pour info : "’", "‘", "Œ", "œ", "…" soit respectivement les codes ASCII 0145, 0146, 0140, 0156, 0133)
Potentiellement cette "omission" de la part de PCSoft a pourri toutes nos bases clients...

**Hibernatus34** · 08/11/2013, 10h53

Ph_Gr: En fait, ce n'était pas le sujet. Il s'agissait ici de bugs ou fautes de conception qui ne seraient probablement jamais corrigées (pour un problème de rétrocompatibilité la plupart du temps).

Concernant vos bugs, vous avez bien fait de les signaler, et il faut continuer à le faire. Je pense qu'au moins une centaine de bugs est corrigée chaque année grâce aux retours utilisateurs, car certaines années j'en ai fait corriger une vingtaine à moi seul.

Au passage, le bug spectaculaire de la comparaison à Null est toujours là, bien que PC Soft en ait été informée... (point 4 de mon 1er message)

Invité · 08/11/2013, 11h02

Envoyé par Hibernatus34

Ph_Gr: En fait, ce n'était pas le sujet. Il s'agissait ici de bugs ou fautes de conception qui ne seraient probablement jamais corrigées (pour un problème de rétrocompatibilité la plupart du temps).

Ah bon? Le titre c'est pourtant juste "Bugs et erreurs de conception de Windev"...

D'autre part, si je reprend ta phrase d'introduction :

Envoyé par Hibernatus34

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é.

Le fait que tu aies mis un "ou" devant "sur lesquels il est impossible d'apporter un correctif à cause de la rétrocompatibilité" implique que le sujet concerne notamment les bugs ou fautes de conception qui ne seraient probablement jamais corrigées mais pas seulement.

Donc c'est bien le sujet ou alors je n'ai rien compris...???

**Hibernatus34** · 08/11/2013, 11h04

"Ne pas choquer le support technique" était une manière de dire qu'il ne l'admettait pas en tant que bug, et donc ne le ferait pas corriger.

Désolé si ce n'était pas clair.

Dans ma liste, tout a été signalé à PC Soft, rien n'a été corrigé, et presque rien ne sera jamais corrigé.

Lister publiquement les bugs que PC Soft corrige de bonne foi ne servirait pas à grand chose, si ce n'est scier la branche sur laquelle nous sommes assis, à mon humble avis.

(par exemple il y a un bug extrêmement grave sous WD17, corrigé en WD18 dont je n'ai pas parlé. Je vous déconseille juste d'utiliser le type monétaire dans une analyse avec connexion en OLEDB si vous êtes encore en version 17...)

Invité · 08/11/2013, 11h15

Envoyé par Hibernatus34

Lister publiquement les bugs que PC Soft corrige de bonne foi ne servirait pas à grand chose, si ce n'est scier la branche sur laquelle nous sommes assis, à mon humble avis.

En fait il faut voir aussi un autre aspect de cela : il y a des anomalies qui ne seront pas corrigées avant la version 19, comme par exemples celles que j'ai mentionnées. C'est pourquoi je pense qu'il est quand même utile que quelqu'un qui se met par exemple à la version 18 sache qu'il y a des anomalies dans la version qu'il a pris qui ne seront jamais corrigées dans sa version.

Envoyé par Hibernatus34

(par exemple il y a un bug extrêmement grave sous WD17, corrigé en WD18 dont je n'ai pas parlé. Je vous déconseille juste d'utiliser le type monétaire dans une analyse avec connexion en OLEDB si vous êtes encore en version 17...)

Encore un très bon exemple de ce que je viens juste de dire.

Envoyé par Hibernatus34

Au passage, le bug spectaculaire de la comparaison à Null est toujours là, bien que PC Soft en ait été informée... (point 4 de mon 1er message)

Oui, c'est vraiment un très beau bug qui est digne de rentrer dans l'Histoire!

**jdsetls** · 08/11/2013, 11h19

Bonjour,

Une fois acquis que Windev est un excellent produit il me semble fort utile de lister et commenter les bugs. Sans pour autant se gausser. Je travaille sur mon doctorat d'économie dont le thème est "Economie de la pensée dans la prévention et l'éradication des bugs logiciels'. Les exemples sont tous en Windev. Je cherche, merci de faire passer le message, un superviseur de thèse qui soit un informaticien professeur ou ancien professeur à l'université.

Sur le thème des bugs, j'en publierai une liste commentée dès que j'aurai lu la totalité des posts afin de ne pas faire double emploi. Enfin je dispose de textes fondamentaux sur la nature des bugs.

Pour conclure, je citerai le bug du paramétrage par défaut du Contexte Indépendant à faux, ce qui a dû faire perdre de nombreux clients à PCSoft. D'autant que les nouveaux utilisateurs ignorent ce concept jusqu'à en avoir vécu les effets destructeurs.

En pièce jointe un texte qui constitue l'un des premiers chapitres de mon doctorat : Les bugs les plus célèbres de l'histoire.

Bien cordialement,

Jacques De Schryver

**Hibernatus34** · 08/11/2013, 11h22

Envoyé par Ph_Gr

En fait il faut voir aussi un autre aspect de cela : il y a des anomalies qui ne seront pas corrigées avant la version 19, comme par exemples celles que j'ai mentionnées. C'est pourquoi je pense qu'il est quand même utile que quelqu'un qui se met par exemple à la version 18 sache qu'il y a des anomalies dans la version qu'il a pris qui ne seront jamais corrigées dans sa version.

Oui, pour une version en cours, c'est bon à savoir, effectivement.

Ceci étant dit, j'attends de savoir quels autres problèmes le ST a refusé de faire corriger.

**e.haefele** · 13/11/2013, 14h40

Bonjour,

Je vous propose ici un dysfonctionnement qui ne semble pas choquer PC-SOFT, j'espère donc être au bon endroit pour l'évoquer.

Pour l’illustrer facilement je vais m'appuyer sur WDMAP (développé avec WinDev) mais on le verra plus tard qui est facilement reproductible dans nos applications.

Pré-requis :
WDMAP en version 18
Un fichier HF avec plus d'un enregistrement et une rubrique date au minimum.

Reproduction :
Ouvrir le fichier HF avec WDMAP
Entrer en saisie dans la rubrique date et saisir une date erronée, par exemple : 31/02/2013
Tout en restant dans le champ date, donner le focus à une autre application.
Puis dernière action redonner le focus à WDMAP mais _impérativement_ en cliquant sur un autre enregistrement que celui précédemment modifié.

Constat :
Le contrôle de la date n'a pas été effectué et sauf à revenir sur la rubrique, le contrôle ne sera jamais effectué.
Par ailleurs il est possible de quitter WDMAP, en y revenant on constatera que la date erronée a été mémorisée dans le fichier.

Dans nos applications c'est la même chose mais le symptôme apparaît également entre deux fenêtres filles.
Ce phénomène n'est reproductible qu'avec des tables, sur un champ classique dans une fenêtre tous les contrôles sont effectués correctement.

L'exemple s'appuie ici sur un champ date, mais ce problème est reproductible sur n'importe quelle table où il y aurait un contrôle automatique de WinDev (saisie obligatoire ou autres ...). Par ailleurs si dans le code de sortie du champ vous avez du code, celui-ci n'est pas exécuté non plus, vive les erreurs d'intégrité !

Ce dysfonctionnement existe depuis la version 9 sur des tables sans sélection, depuis peu (je ne sais pas exactement depuis quelle version) également sur les tables en sélection.

Qu'en pensez-vous, n'est-ce pas complètement aberrant ? Moi en tout les cas ça me choque et j'aimerais bien qu'un jour ce dysfonctionnement soit corrigé.