Discussion :

[Hemgé]

Bonjour,

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
sMsg1, sMsg2, sMsg3 sont des chaînes 
sTxt  est une chaîne 
sTest est une chaîne 
dTestDate est une Date 
hTestHeure est une Heure 
dhTestDateHeure est une DateHeure 
sChaineDeTests est une chaîne = "20" + RC + "2014" + RC +"2064" + RC + "201406" + RC + "20140613"+ RC + "201406136"
i est un entier 
 
POUR TOUTE CHAÎNE sTxt DE sChaineDeTests SEPAREE PAR RC 
	sTest = sTxt
	dTestDate = sTxt 
	//dTestDate = ChaîneVersDate(sTxt) 
	hTestHeure = sTxt 
	dhTestDateHeure = sTxt 
 
	Trace(sTxt)
		POUR i = 1 A 4 
		SELON i
			CAS 1 
				sMsg1 = "Type Chaîne" 
				sMsg2 = DateValide(sTest) ? "D - Ok" SINON "D - Ko" 
				sMsg3 = HeureValide(sTest) ? "H - Ok" SINON "H - Ko" 
			CAS 2
				sMsg1 = "Type Date" 
				sMsg2 = DateValide(dTestDate) ? "D - Ok" SINON "D - Ko" 
				sMsg3 = HeureValide(dTestDate) ? "H - Ok" SINON "H - Ko" 
			CAS 3
				sMsg1 = "Type Heure"
				sMsg2 = DateValide(hTestHeure) ?"D - Ok" SINON "D - Ko" 
				sMsg3 = HeureValide(hTestHeure) ? "H - Ok" SINON "H - Ko" 
			CAS 4
				sMsg1 = "Type DateHeure"
				sMsg2 = DateValide(dhTestDateHeure) ? "D - Ok" SINON "D - Ko"  
				sMsg3 = HeureValide(dhTestDateHeure) ? "H - Ok" SINON "H - Ko" 
		FIN
		Trace(sMsg1 + " : " + sMsg2 + " - " + sMsg3) 
	FIN 
FIN
STOP

Donc,

On peut tester un type Date ou un type DateHeure comme étant une heure
et passer le test : HeureValide(dTestDate), HeureValide(dhTestDateHeure)

Les contrôles de validité sur la date et sur l’heure ne respectent pas les mêmes critères :
20 correspond à AA et est rejeté
20 correspond à HH et est accepté
2014 correspond à AAAA et est rejeté
2014 correspond à HHMM et est accepté
201406 correspond à AAAAMM et est rejeté
201406 correspond à HHMMSS et est accepté
20140613 correspond à AAAAMMJJ : la Chaîne et la Date sont validés comme Date, rejetés comme Heure et DateHeure
20140613 correspond à HHMMSSMM et est rejeté comme Heure et DateHeure (millisecondes incomplètes ?)
201406136 est rejeté comme Date sauf quand il est affecté à un type Date : DateValide(dTestDate)
ChaineVersDate renvoie une chaîne vide.
20140613 correspond à HHMMSSMMM et est validé comme heure dans tous les cas.

Les dates tronquées sont refusées, tandis que les heures tronquées sont validées, tant que le segment H, M, S ou M est complet
Si une variable DateHeure peut être validée comme Heure, elle est validée, alors que le format attendu n’est pas respecté : longueur et position de la sous-chaîne compatible avec l’heure.

En sus, une fonction DateHeureValide() serait bienvenue et aurait dû accompagner l'introduction de ce type ...!

Testé en V18.
Si l'un de vous veut bien tester en V19 et faire remonter à PC soft, qu'il en soit remercié.

Hemgé

[hpascal]

Bonjour

En sus, une fonction DateHeureValide() serait bienvenue et aurait dû accompagner l'introduction de ce type ...!

Et bien ça existe ... en v19 : DateHeureValide

[Hemgé]

Bonjour

Et bien ça existe ... en v19 : DateHeureValide

Magnifique, a priori.
Mais alors, à tester à la lumière de mes tests !

[Tober]

Je suis pas sur que tes tests soient vraiment "acceptable".
Déjà en lisant la doc de DateValide ou HeureValide, c'est bien précisé les formats acceptés et rejetés.

DateValide prend en paramètre une date :

<Date> : Chaîne de caractères ou variable de type Date
Chaîne de caractères au format AAAAMMJJ (AAAA correspond à l'année, MM au mois et JJ au jour).

HeureValide prend en paramètre une heure :

<Heure> : Chaîne de caractères ou variable de type Heure
Chaîne de caractères au format :

• HHMMSSCC
• HHMMSS
• HHMM
• HH

Donc du coup, la moitié de tes tests sont justifiés.

Ensuite, il y a un cas qui peut paraitre bisarre :

201406136 est rejeté comme Date sauf quand il est affecté à un type Date : DateValide(dTestDate)

Mais vu que tu affectes au départ une chaine "201406136" dans une date, il faut regarder du côté du transtypage automatique de WinDev...
Si tu regardes la valeur de ta variable Date, elle est égale à "20140613".

Je ne pense pas qu'il y ait de problème avec ces deux fonctions.

Bref, attention avant de donner des résultats en sorti de fonction sans savoir ce qu'il y a en entrée de ces mêmes fonctions

[Hemgé]

Bonjour Tober.

Tout d'abord, l'intitulé du message est "DateValide, HeureValide - quelques incohérences"

Est-il cohérent que :

• on puisse fournir une heure partielle et non une date ?
• "201406136" soit accepté et transtypé en "20140613" donc corrigé, donc altéré, par DateValide, alors qu'il est - à mon sens plus correctement - rejeté par ChaïneVersDate (qui renvoie une chaîne vide) ?
  Accessoirement, je ne recours jamais au transtypage que je considère comme une 'facilité malheureuse', dans l'esprit du RAD, et piège potentiel.
• transtyper ne veut pas dire corriger. Quand on demande un arrondi, on s'y attend, mais pas dans le cas présent.
• que le type DateHeure accepte de ne recevoir qu'une date, mettant ainsi l'heure à zéro, alors qu'on pourrait souhaiter n'y stocker, pourquoi pas, qu'une année ?
  A ce niveau, il faudrait essayer de suivre la norme ISO 8601 comme SQL.

Et il y a aussi quelques erreurs : reprenez les tests avec la chaîne qui suit et vous constaterez non seulement les incohérences, mais aussi les erreurs de conception, notamment du fait du "trantypage".

Code :

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

sChaineDeTests est une chaîne =  "201406166" + RC + "00000000201486413" + RC+ "20141313235959999" + RC+ "20141313236059999"

Je remets tout le test parce que j'ai ajouté la visualisation des variables dans le trace.

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
sMsg1, sMsg2, sMsg3 sont des chaînes 
sTxt  est une chaîne 
sTest est une chaîne 
dTestDate est une Date 
hTestHeure est une Heure 
dhTestDateHeure est une DateHeure 
//sChaineDeTests est une chaîne = "20" + RC + "2014" + RC +"2064" + RC + "201406" + RC + "20140613"+ RC + "201406136" 
sChaineDeTests est une chaîne =  "201406166" + RC + "00000000201486413" + RC + "20141313235959999" + RC + "20141313236059999"
i est un entier 
 
POUR TOUTE CHAÎNE sTxt DE sChaineDeTests SEPAREE PAR RC 
	sTest = sTxt
	dTestDate = sTxt 
	//dTestDate = ChaîneVersDate(sTxt) 
	hTestHeure = sTxt 
	dhTestDateHeure = sTxt 
 
	Trace(sTxt)
	POUR i = 1 A 4 
		SELON i
			CAS 1 
				sMsg1 = "Chaîne - " + sTest
				sMsg2 = DateValide(sTest) ? "D - Ok" SINON "D - Ko" 
				sMsg3 = HeureValide(sTest) ? "H - Ok" SINON "H - Ko" 
			CAS 2
				sMsg1 = "Date - "  + dTestDate 
				sMsg2 = DateValide(dTestDate) ? "D - Ok" SINON "D - Ko" 
				sMsg3 = HeureValide(dTestDate) ? "H - Ok" SINON "H - Ko" 
			CAS 3
				sMsg1 = "Heure - " + hTestHeure 
				sMsg2 = DateValide(hTestHeure) ?"D - Ok" SINON "D - Ko" 
				sMsg3 = HeureValide(hTestHeure) ? "H - Ok" SINON "H - Ko" 
			CAS 4
				sMsg1 = "DateHeure - " + dhTestDateHeure 
				sMsg2 = DateValide(dhTestDateHeure) ? "D - Ok" SINON "D - Ko"  
				sMsg3 = HeureValide(dhTestDateHeure) ? "H - Ok" SINON "H - Ko" 
		FIN
		Trace(sMsg1 + " : " + sMsg2 + " - " + sMsg3) 
	FIN 
FIN
STOP

"201406166"
Vous constatez que le 9e caractère est tronqué aussi bien dans dTestDate que dans dhTestDateHeure - soit "20140616" -, mais que si DataValide accepte dTestDate, dhTestDateHeure est invalidé.

"00000000201486413"
La chaîne est validée telle que comme heure, alors qu'il y a 86 minutes, tandis que dhTestDateHeure est validée et "transtypée" les heures passent à 15 et les minutes retombent à 26.
Mais, 'minute', vous verrez plus loin qu'il y a transtypage et transtypage !

"20141313235959999" : test du "transtypage" sur la date
Les mois sont passés à 13.
La date est refusée, alors qu'on aurait pu attendre un passage des années à 2015 et des mois à 01, si le traitement des dates et des heures était cohérent (voir infra)

"20141213236059999" : test du "transtypage" sur l'heure
L'heure est poussée à l'extrême de chacune des tranches.
Ben, le voilà, le 'minute'.
Chaîne : la date est rejetée, malgré un format correct. L'heure est acceptée, malgré qu'il y ait 60 minute et encore des secondes.
Date : la date ET l'heure sont validées, alors qu'il manque le 9e chiffre pour avoir le format horaire complet
DateHeure : la date est à nouveau rejetée (!?) et l'heure est "transtypée", puis validée

Donc, en l'absence de contrôle en amont (dans votre application ou dans la source que vous importez), Windev va arrondir les angles, "transtyper" et propager une erreur au lieu de vous signaler / sanctionner cette anomalie dans le nombre de minutes (80) ou de jour (supra : 166 jours), ce que je qualifie d'erreur de conception. On pourrait accepter de saisir des minutes dépassant le chiffre de 60, mais pas dans un format horaire.

Bonne journée

Hemgé

[Tober]

J'ai fais un effort pour retester ton nouveau code et lire chaque commentaire que tu nous fais et il y a toujours des problèmes selon moi que tu ne prends pas en compte :

"201406166"
Vous constatez que le 9e caractère est tronqué aussi bien dans dTestDate que dans dhTestDateHeure - soit "20140616" -, mais que si DataValide accepte dTestDate, dhTestDateHeure est invalidé.

Normal, déjà expliqué dans mon premier message... Pour rappel, DateValide ne prend pas le type DateHeure en paramètre...

"201406136" soit accepté et transtypé en "20140613" donc corrigé, donc altéré, par DateValide, alors qu'il est - à mon sens plus correctement - rejeté par ChaïneVersDate (qui renvoie une chaîne vide) ?
Accessoirement, je ne recours jamais au transtypage que je considère comme une 'facilité malheureuse', dans l'esprit du RAD, et piège potentiel.

C'est faux, tu n'as pas compris mon premier message on dirait...
Ce n'est pas DateValide qui fait un transtypage, c'est ça :

Code :

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

dDate est une date = "201406136"

que le type DateHeure accepte de ne recevoir qu'une date, mettant ainsi l'heure à zéro, alors qu'on pourrait souhaiter n'y stocker, pourquoi pas, qu'une année ?

Je trouve ça assez logique de pouvoir mettre une date... SQL Server fait comme ça aussi par défaut par exemple. Par contre, ne mettre qu'une année ne fait pas vraiment de sens.. sinon pourquoi pas aussi un mois ou une minute...

Pour tes tests avec des chaines d'une longueur supérieur à ce qui est attendu, tu ne respectes même pas l'entrée des fonctions encore une fois...
Une date ou une heure, c'est maximum 8 caractères, donc toutes chaines supérieurs sera traiter "à la WinDev", j'en sais rien...

Ce que je voulais dire c'est que tu utilises ta procédure de test en mettant un peu tout et n'importe quoi dans des variables date, dateheure et chaine et ensuite tu les mets dans des fonctions de validation de format.

Pour moi si tu veux valider le faite qu'une variable soit une date ou une heure, c'est que tu ne sais pas vraiment ce que c'est, donc avant de les affecter directement dans des variables typés, vérifie d'abord ce que c'est...

Bref en reprenant ton code :

Code :

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

1
2
3
4
5
6
POUR TOUTE CHAÎNE sTxt DE sChaineDeTests SEPAREE PAR RC 
	sTest = sTxt
	dTestDate = sTxt  // A supprimer
	//dTestDate = ChaîneVersDate(sTxt) 
	hTestHeure = sTxt   // A supprimer
	dhTestDateHeure = sTxt // A supprimer

Ne fait les tests qu'avec la variable chaine (a la limite Date pour DateValide et Heure pour HeureValide)
Mais faire un mixe de tout et ensuite critiquer, c'est facile...

Pour résumé tout ça, les erreurs de conception comme tu les appelles sont au niveau des type Date, DateHeure qui essaye de faciliter la vie du développeur lambda. Moi je gère des données de ce type tout le temps, même avec DateValide et HeureValide et je n'ai jamais eu un seul problème... Mais j'ai respecté la documentation de ces fonctions à la base.

[Hemgé]

Bonsoir

Je ne suis pas du tout d'accord : si on respecte tout, alors plus besoin que même le programme fasse des contrôles.

Vous contrôlez l'utilisateur de vos applis, PC soft doit contrôler les utilisateurs de ses applis et il le fait assez souvent, mais pas toujours.

Evidemment, que je mets n'importe quoi et que je cherche même la "petite bête" pour tester, comme vous, je le suppose, lorsque vous êtes en phase de test de vos applis.
Où est le problème, sauf si le test a les mailles trop larges.

Une fonction HeureValide ne peut pas valider "201486413", quelles que soient mes intentions vicieuses ou les lacunes d'une saisie, compte tenu d'ailleurs que ce DateValide pourrait être utilisé en contrôle de saisie. S'il me "transtype" alors la date et stocke "201526413" au lieu des "201458413" (5 et 8 sont des touches voisines), qu'est-ce que je fais ? La grosse tête à l'utilisateur ?

Bon, chaque lecteur prendra le parti qu'il voudra.
J'ai lancé l'avertissement que je voulais lancer.
Si cela vous convient aussi, considérons que le sujet est clos.

Hemgé

[Hemgé]

Finalement, en reconsultant la doc (V18 et V19) :

Quant à l'erreur sur l'heure :
Les heures comportant des secondes (minutes aussi je suppose) supérieures à 59 doivent être rejetées.

HeureValide (Fonction)

Teste la validité d'une heure.

Exemple
...
HeureValide("23137099") // Retourne Faux

DateHeureValide (Fonction)

Teste la validité d'une date/heure comprise entre le 01 janvier 0001 à 0 heure 0 minute 0 seconde 0 centième de seconde et le 31 décembre 9999 à 23 heures 59 minutes 59 secondes 99 centièmes de seconde.
Exemple
...
Res = DateHeureValide("1482122524") // Res retourne Faux

Quant aux incohérences :

DateHeure (Type de variable)
...
Déclaration et initialisation

Une variable de type DateHeure peut être initialisée avec une valeur de type :
Date : les heures et les minutes seront initialisées à 0.
DateHeure
Chaîne de caractères, au format

AAAAMMJJHHMMSSLLL

DateHeureValide (Fonction)

<Date/Heure> : Chaîne de caractères ou variable de type DateHeure

Chaîne de caractères au format AAAAMMJJHHMMSSCC (AAAA correspond à l'année, MM au mois, JJ au jour, HH à l'heure, MM aux minutes, SS aux secondes et CC aux centièmes de seconde).
Où sont passés les millièmes de secondes "LLL" ? Une DateHeure comportant des millièmes est-elle invalide ?

[Tober]

Je ne suis pas du tout d'accord : si on respecte tout, alors plus besoin que même le programme fasse des contrôles.

Vous contrôlez l'utilisateur de vos applis, PC soft doit contrôler les utilisateurs de ses applis et il le fait assez souvent, mais pas toujours.

Evidemment, que je mets n'importe quoi et que je cherche même la "petite bête" pour tester, comme vous, je le suppose, lorsque vous êtes en phase de test de vos applis.
Où est le problème, sauf si le test a les mailles trop larges.

Une fonction HeureValide ne peut pas valider "201486413", quelles que soient mes intentions vicieuses ou les lacunes d'une saisie, compte tenu d'ailleurs que ce DateValide pourrait être utilisé en contrôle de saisie. S'il me "transtype" alors la date et stocke "201526413" au lieu des "201458413" (5 et 8 sont des touches voisines), qu'est-ce que je fais ? La grosse tête à l'utilisateur ?

Le problème ici, c'est que tu confonds utilisateur et développeur...
Tester est indispensable, tout le monde le dira volontier...
Ce que j'essaye de te faire comprendre, c'est que le développeur doit utiliser les fonctions qui lui sont fournit correctement sinon c'est sûr que tu auras des problèmes dans tes tests...
C'est pas à l'utilisateur de savoir comment utiliser DateValide ou HeureValide mais à toi développeur de transformer les entrées avant de les envoyer à ces fonctions...

Tu t'acharnes a répéter tes incohérences de DateValide sur une variable à la taille supérieure à ce qui est attendu par la fonction... Ca ne peut pas marché ! Si ca marche, c'est de la chance, si tu veux faire une appli en te basant sur la chance, alors bon courage pour tes tests, moi je respecterai le langage que j'utilise...

[Hemgé]

Tober, Tober,

J'ai déjà répondu que le développeur Windev est l’utilisateur de PC soft.
J'ai déjà répondu que quiconque émet des spécifications doit les respecter.
Les développeurs parfaits n'existent pas.

Je vous ai trouvé des exemples dans la doc et cela ne suffit pas.
Je pourrais vous proposer des exemples parfaitement crédibles, mais le but du jeu n'est pas d'avoir raison, seulement d'attirer l'attention, ce que nos échanges ont certainement favorisé.

Je conviens que j'ai repris le sujet, mais c'est l'impasse et nous n'allons pas polluer le forum.

Bonne semaine

Hemgé