Discussion :

[Arnaud B.]

Bonjour,

Attention ! Je constate aussi des erreurs dues à des variables date qui ne s'initialisent pas de la même façon que dans les versions précédentes.

Dans le code d'init de mon projet, j'ai :

Code :

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

DateHeureParDéfaut("", "")

Avant la 62h, cela fonctionnait et les variables date étaient effectivement initialisées avec une chaine vide
Dans la version 62h, elles sont désormais initialisées à la date du jour.

Il semblerait que ce soit DateHeureParDéfaut() qui n'accepte plus les chaines vides, bien que le compilateur ne signale rien.

Je vous laisse imaginer les effets de bord !!!

Je vous conseille de tester tous vos appels à dMaDate = "" dans vos applis, c'est ce que je vais faire de ce pas...

--
Cdlt, Arnaud.

[Hemgé]

Bonsoir,

Ce comportement est normal et correspond en tout cas à la description de la fonction.

Initialisation avec une heure et une date déterminées


DateHeureParDéfaut(<Date> , <Heure>)
--------------------------------------------------------------------------------

<Date> : Chaîne de caractères (avec guillemets)
Date utilisée pour l'initialisation des variables de type Date et DateHeure. Cette date est au format "AAAAMMJJ" où AAAA correspond à l'année, MM correspond au mois et JJ correspond au jour.

<Heure> : Chaîne de caractères (avec guillemets)
Heure utilisée pour initialiser les variables de type DateHeure et Heure. Cette heure est au format HHMMSSCC (HH correspond aux heures, MM aux minutes, SS aux secondes et CC aux centièmes de seconde).

Cela signifie que le contrôle a vraisemblablement été amélioré, mais n'est sans doute pas encore complètement abouti (puisque le compilateur reste muet).

Hemgé

[Hibernatus34]

Bonsoir,

Ce comportement est normal et correspond en tout cas à la description de la fonction.

Cela signifie que le contrôle a vraisemblablement été amélioré, mais n'est sans doute pas encore complètement abouti (puisque le compilateur reste muet).

Hemgé

Et puis quoi encore ?
Cette fonction sert à définir la valeur par défaut d'un type de variable donné.
Elle doit supporter toutes les valeurs admissibles par ce type de données.
Il s'agit d'une régression.

[Hemgé]

Bonjour,

Elle doit supporter toutes les valeurs admissibles par ce type de données.

Quelle est la portée précise de votre remarque ?

"" est une chaîne de caractères, mais n'est pas une valeur admissible par une variable de type Date, Heure ou HeureDate.

Référez-vous à l'aide pour les variables de type Date, Heure et DateHeure.
Vous n'y trouverez aucune échappatoire dans le sens que vous défendez.

Que certains aient éventuellement adopté une pratique "particulière" au détour d'une faille dans les contrôles de Windev est dommage, mais la documentation est claire.
Et quand la documentation m'indique une règle, je m'y conforme si possible.
Si je découvre un "truc et astuce" qui me facilite la vie et que je l'utilise, c'est à mes risques et périls.

La réaction d'Arnaud B., de l'ordre de la mise en garde, était mesurée, même s'il évoquait une erreur.
Evoquer une "régression" est exagéré.


Ce n'est pas la première fois qu'on constate un resserrement des tolérances à l'occasion d'une mise à jour ou d'une nouvelle version.
Et il n'y a aucune raison de critiquer PC Soft lorsqu'elle apporte des modifications allant dans le sens du respect de ses spécifications.

Je peux comprendre que vous souhaitiez l’institutionnalisation d'une lacune que d'aucuns exploitent, pour en faire une exception admise ET documentée (donc garantie pour l'avenir), ne me pose aucun problème et n'est pas le sujet de ma réaction initiale.
Dans ce cas, il faut déposer une demande auprès de PC Soft.

[Hibernatus34]

Le type Date des bases HF, le champ de saisie de type Date et le type DateHeure avaient le même comportement.
Si la valeur "" ne doit plus être admise dans le type date, on devrait avoir un plantage quand on écrit :

Code :

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

dDate est Date = ""

Le minimum, c'est la cohérence.
Ensuite, les choix au niveau du comportement du type Date c'est autre chose. Mais une chose qui doit être définie suffisamment tôt. Au bout de 11 versions ça fait un peu tard (je compte à partir de la 7).

[Arnaud B.]

Bon, moi, je suis d'accord avec chacun d'entre vous...

D'un côté, je suis d'accord avec Hemgé : la fonction n'est censée acceptée qu'une date, éventuellement au format chaine. OK, je n'ai pas respecté cette contrainte, tant pis pour moi.
J'aurai cependant apprécié que l'on m'avertisse de ce changement de comportement, qui fait quand même planter toutes mes applis.

Je ne connais aucune autre techno qui se permettrait de changer le comportement du compilateur sur quelque chose d'aussi sensible que la valeur par défaut d'une variable sans avertir ses utilisateurs.

D'un autre côté, je suis assez en phase avec Hibernatus34 : qui de la cohérence ? On peut mettre une chaine vide dans une date, mais pas par défaut ????

[Hibernatus34]

J'ajoute que le cas de la chaîne vide est justement le plus utile en tant que valeur par défaut. C'est un peu comme un type nullable.

[digi12]

bonjour

en déclarant DateHeureparDéfaut(" "," ") ( 1 espace entre les guillemets ) une variable déclarée en date retourne 1 espace

effectivement avec ("","") cela retourne la date du jour

peut être déclarer votre variable avec une affectation ( c'est plus sûr non ? )

Ddate est une date=""

ce qui manque le plus en fait, c'est la liste exacte et complète de tous les changements qui ont eu lieu dans une mise à jour mais je ne pense pas que nous l'aurons car il y a aussi des corrections de bug qu'il ne faut pas dévoiler ...

demander aussi à PCSOFT si c'est voulu ou si c'est involontaire : peut être ils ne sont pas au courant de ce comportement ... ou peut être il y a une raison valable

bon dev

[Hemgé]

Re bonjour

La discussion prend des "proportions" qu'elle ne mérite pas, parce qu'elle dérive comme à l'habitude.

1. Arnaud nous alerte, ce qui est toujours agréable puisque cela nous évite la surprise.
   
2. Il évoque une erreur et je lui oppose la syntaxe de PC Soft, ce qu'il accepte de bonne grâce.
   
3. Les vieux ressentis se ravivent et la discussion dérive, ce qui est dommage.
   
4. Pour être complets, il faut encore envisager l'hypothèse que PC Soft n'a peut-être pas corrigé ce point et qu'il s'agit éventuellement d'un effet de bord d'une autre intervention sur le code.
   Pourquoi pas, tant qu'à faire ?

Le minimum, c'est la cohérence.

Ensuite, les choix au niveau du comportement du type Date c'est autre chose. Mais une chose qui doit être définie suffisamment tôt. Au bout de 11 versions ça fait un peu tard (je compte à partir de la 7).

Mais ce n'est pas cohérent non plus de flinguer PC Soft parce qu'elle se décide enfin à bouger, en lui reprochant de bouger (même après 11 versions : on sait qu'il leur arrive de prendre leur temps ...)
Par contre, j'aurais applaudi à un relevé des corrections complémentaires à apporter pour que le job ne soit pas fait à moitié et que le problème soit réglé une fois pour toute.
Et qu'il y ait une cohérence, quelle qu'elle soit.

Je, vous, nous (et eux aussi) tentons de gérer au plus près les arguments et paramètres de nos procédures / fonctions.
La différence est que nous avons un accès immédiat à notre code et dépendons de PC Soft pour Windev.
La frustration vient comme toujours du manque d'information et de l'aspect unilatéral de la communication de l'intimée, mais cela n'est nouveau pour personne.

PC Soft n'a pas l'habitude de communiquer publiquement sur les multiples correctifs apportés à chaque release, ni même sur les nouveautés.
Je vous renvoie par exemple à la Liste des améliorations et des corrections de dysfonctionnements de cette mise à jour (par rapport à la version 180056f) :
Vous y lirez à propos de l'Editeur d'états qu'il y a de "nombreuses améliorations" apportées au champ HTML. Quant à savoir lesquelles ...

L'argument chaîne vide est pratique ? Suggérons à PC Soft de le supporter, ce qui ne les exonérera pas de vérifier la cohérence de l'ensemble.

Mais ne nous empoignons pas pour autant (ou pour si peu).

[Hibernatus34]

Je ne sais pas pourquoi vous le prenez comme ça. Il n'y pas lieu de se vexer. Jusque là je pensais qu'on parlait de technique et non de politique.
Quand je parle de cohérence, par exemple, c'est au niveau technique : il doit y avoir cohérence entre l'opération d'affectation et la valeur par défaut.

Quand je dis que c'est une régression c'est parce que du code correct ne fonctionnera plus.
Et c'est grave, car au lieu d'avoir un simple plantage, on peut avoir des données erronées et mettre un certain temps avant de s'en rendre compte.

Le code était correct parce qu'il définissait une valeur par défaut avec une valeur admise par le type date. Elle est toujours admise à ce jour.

[Hemgé]

Détrompez-vous : je ne suis ni vexé, ni énervé, ni rien de tout cela.
Il ne s'agit pas non plus de défendre PC Soft à tout prix.

J'essayais simplement d'être rationnel et pragmatique, de sérier les problèmes, même en face de PC Soft.

PC Soft a conçu une fonction et l'a documentée.
Son obligation de fournisseur, telle que nous le lui rappelons régulièrement, est de coller à ses spécifications, donc aussi de corriger les erreurs / insuffisances constatées, en sus de livrer les nouveautés promises.

Certains ont découvert une faille pratique et l'ont exploitée, consciemment (en faisant un pari sur l'avenir) ou inconsciemment (sans avoir bien lu la doc).

PC Soft corrige (du moins c'est l'hypothèse) cette faille.
Il s'avère que c''est ennuyant pour certains.
C'est même irritant dans l'absolu où, un fois encore, le job n'est pas complet d'emblée.
C'est d'autant plus ennuyant pour ceux qui exploitaient cette faille qu'elle apportait un plus.

Mais, dans l'absolu, on ne peut pas reprocher cette intervention à PC Soft (si elle est volontaire).
Et d'autant plus que de manière régulière, on leur reproche de laisser traîner un tas de problèmes, dont ils refusent d'ailleurs qu'on établisse un relevé public.

On leur reproche aussi à juste titre de ne pas signaler la résolution de ces problèmes, sauf interrogation spécifique.
Nous avons tous connaissance de problèmes et avons développé des contournements pour pouvoir avancer.
Certains de ceux-ci sont devenus inutiles mais nous continuons à les utiliser parce que nous ne sommes pas informés de la résolution des problèmes qui sont à leur origine.



Dans l'immédiat, il ne doit pas être très compliqué de surcharger la fonction.
A moyen terme, il faut entreprendre PC Soft.

Il y a quelques mois, on a signalé dans une discussion que PC Soft avait complété la documentation d'une fonction en y ajoutant une spécification non documentée, mais connue de certains, et il a été conclu que cette mention était un gage de pérennité de cet usage.
Peut-être sera-t-il plus simple pour eux de rencontrer nos souhaits et d'officialiser cette option supplémentaire (en prenant soin de la cadrer).

[mail.spam]

Bonjour,

Merci à Arnaud B. de nous avoir prévenue.
Pour le reste ce débat est-il vraiment utile?

[Hibernatus34]

Un débat est toujours utile, c'est en soi la preuve que 2 personnes n'ont pas compris la même chose et qu'elles pourraient gagner à en discuter.
Vous êtes bien délicats sur ce forum...

Le bug est enregistré chez PC Soft sous la référence 83 012/395491.

Et merci beaucoup à Arnaud B.

[Hemgé]

Pour le reste ce débat est-il vraiment utile?

Même s'il n'y avait pas péril en la demeure, rendons de bonne grâce au modérateur ce qui lui revient :

"Ave mail.spam, tacituri te salutant"

[Hibernatus34]

Suite à notre échange rappelé ci-dessous, concernant l'initialisation des dates par défaut avec la fonction DateHeureParDéfaut :

Un correctif a été réalisé par notre équipe Développement et notre équipe Qualité. Voici un lien vous permettant de télécharger une mise à jour pour la version interne 01F180062F de WinDev 18 :

http://stg.webdev.info/Telechargemen..._18&REF=395491

Cette mise à jour regroupée dans une archive zip est composée de :

- \wd180vm.dll (3078,00 Ko) - version : 18.0.150.4
- \framework\win64x86\wd180vm64.dll (3468,50 Ko) - version : 18.0.150.4

Elle doit être décompressée en conservant l'arborescence dans le dossier \Programmes\ de WinDev 18, vous devez lors de la décompression confirmer le remplacement des fichiers de mêmes noms déjà présents. Recréez ensuite l'exécutable de l'application, afin de le déployer à nouveau avec cette mise à jour du framework.

Veuillez nous excuser pour le contretemps occasionné par cet incident, et me confirmer vos résultats.

Référence à rappeler pour tout contact à ce sujet : 83 012/395491.

PC Soft est très réactif sur les problèmes de régressions.
La version 19 aura donc l'ancien comportement, mais c'est peut-être trop tard pour la 18. (sauf avec ce correctif)

[Arnaud B.]

Merci beaucoup Hibernatus34

Pour le coup, je n'avais pas soumis le pb au ST, pensant perdre mon temps puisque n'étant pas tout à fait dans les clous de la doc. de la dite fonction.

J'ai eu tort... Je pense qu'ils ont eu peur des effets de bord (et ils ont raison !).

Cdlt.

[R&B]

En effet, notez que ledit correctif corrige aussi un autre effet similaire qui était la non distinction entre une variable globale et un champ de même nom.

Et en effet donc, ils sont réactifs avec ce genre de problèmes.
Ensuite l'agilité ne leur permet de proposer une mise à jour avant les délais prévus... ce qui explique le correctif.

[Arnaud B.]

En effet, notez que ledit correctif corrige aussi un autre effet similaire qui était la non distinction entre une variable globale et un champ de même nom.

Et en effet donc, ils sont réactifs avec ce genre de problèmes.
Ensuite l'agilité ne leur permet de proposer une mise à jour avant les délais prévus... ce qui explique le correctif.

C'est pas le 2ème correctif qu'ils ont mis en ligne plutôt qui corrige ce point ?

Sinon, effectivement, bonne réactivité sur ce coup.

[kunnskap]

Je déterre ce topic qui colle pas mal au problème que je rencontre...et qui remets en cause ce qui a été dit.
J'ai utilisé la syntaxe vide, qui fonctionne encore en WD25, quand bien même la doc n'en parle pas. J'étais prêt à la changer pour les raisons expliquées car en effet la doc ne le prend pas en charge, donc rien à dire sur ce point.
Mais d'après mes tests, sur mon poste j'obtiens bien des dateheure vide, par contre sur mon serveur Webdev par appel d'un webservice REST, elles sont encore initialisées à la dateheure à l'instant t. Je n'ai pas le même comportement sur les cibles alors que l'instruction est la première ligne du code d'init du projet.
Si je précise une dateheure au format voulu par la doc, même problème. On dirait que le webservice ignore la fonction, c'est peut être normal mais je n'en ai pas trouvé trace dans la doc.
Je le signales en passant, si quelqu'un tombe dessus....je vais régler ça autrement de toute façon, c'est gênant mais pas crucial dans mon cas.