Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ]
Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne
bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de placer
dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS
Date_Louée=""
FIN
Personne n'a de problème avec les champs DateHeure?? Curieux.
Autre problème. Si on valide avec une rubrique dans une colonne DateHeure on ne peut pas non plus coder Si DateHeure="" ALORS parce que cela ne fonctionne pas.
L'autre façon que j'ai trouvé pour valider (rechercher une date vide) est la suivante; Sous "Affichage d'une ligne"
SI DateValide(Date_Sortie)úux ALORS Statut="Libre" FIN
Est-ce que vous faites aussi la même chose?
Réal Phil
-------------------------------- "Real Phil" a écrit dans le message de news:U9sSd.14119$
Bonjour,
Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ] Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de
placer
dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS Date_Louée="" FIN
Existe-t-il une autre façon?
La version 9 a-t-elle réglée ce problème?
Réal Phil
Bonjour,
Personne n'a de problème avec les champs DateHeure?? Curieux.
Autre problème. Si on valide avec une rubrique dans une colonne DateHeure on
ne peut pas non plus coder Si DateHeure="" ALORS parce que cela ne
fonctionne pas.
L'autre façon que j'ai trouvé pour valider (rechercher une date vide) est la
suivante;
Sous "Affichage d'une ligne"
SI DateValide(Date_Sortie)úux ALORS
Statut="Libre"
FIN
Est-ce que vous faites aussi la même chose?
Réal Phil
--------------------------------
"Real Phil" <_pasde_Spam_realp@ultra.ca> a écrit dans le message de
news:U9sSd.14119$K45.853500@wagner.videotron.net...
Bonjour,
Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ]
Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne
bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de
placer
dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS
Date_Louée=""
FIN
Personne n'a de problème avec les champs DateHeure?? Curieux.
Autre problème. Si on valide avec une rubrique dans une colonne DateHeure on ne peut pas non plus coder Si DateHeure="" ALORS parce que cela ne fonctionne pas.
L'autre façon que j'ai trouvé pour valider (rechercher une date vide) est la suivante; Sous "Affichage d'une ligne"
SI DateValide(Date_Sortie)úux ALORS Statut="Libre" FIN
Est-ce que vous faites aussi la même chose?
Réal Phil
-------------------------------- "Real Phil" a écrit dans le message de news:U9sSd.14119$
Bonjour,
Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ] Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de
placer
dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS Date_Louée="" FIN
Existe-t-il une autre façon?
La version 9 a-t-elle réglée ce problème?
Réal Phil
Romain PETIT
Après mure réflexion, Real Phil a écrit :
Bonjour,
Personne n'a de problème avec les champs DateHeure?? Curieux.
Il est possible que ce soit le cas mais que le problème a été contourné. Par exemple en WD7.5 (mais je ne pense pas qu'ils aient changé avec la 8 ou la 9), HeureValide("") renvoie vrai. Pour eux, c'est normal (c'est ce que renvoyait également la 5.5) alors que DateValide("") renvoie faux.
A mon avis, c'est la composante heure de la variable DateHeure qui provoque ce genre de désagréments. (je crois me souvenir que les tris sur les variables dateheure étaient également bogués, mais cela a peut-être été corrigé depuis).
Est-ce que vous faites aussi la même chose?
Essaye de regarder dans l'analyse si la "valeur par défaut" ne résoud pas le problème...
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Après mure réflexion, Real Phil a écrit :
Bonjour,
Personne n'a de problème avec les champs DateHeure?? Curieux.
Il est possible que ce soit le cas mais que le problème a été
contourné.
Par exemple en WD7.5 (mais je ne pense pas qu'ils aient changé avec la
8 ou la 9), HeureValide("") renvoie vrai.
Pour eux, c'est normal (c'est ce que renvoyait également la 5.5) alors
que DateValide("") renvoie faux.
A mon avis, c'est la composante heure de la variable DateHeure qui
provoque ce genre de désagréments.
(je crois me souvenir que les tris sur les variables dateheure étaient
également bogués, mais cela a peut-être été corrigé depuis).
Est-ce que vous faites aussi la même chose?
Essaye de regarder dans l'analyse si la "valeur par défaut" ne résoud
pas le problème...
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
Personne n'a de problème avec les champs DateHeure?? Curieux.
Il est possible que ce soit le cas mais que le problème a été contourné. Par exemple en WD7.5 (mais je ne pense pas qu'ils aient changé avec la 8 ou la 9), HeureValide("") renvoie vrai. Pour eux, c'est normal (c'est ce que renvoyait également la 5.5) alors que DateValide("") renvoie faux.
A mon avis, c'est la composante heure de la variable DateHeure qui provoque ce genre de désagréments. (je crois me souvenir que les tris sur les variables dateheure étaient également bogués, mais cela a peut-être été corrigé depuis).
Est-ce que vous faites aussi la même chose?
Essaye de regarder dans l'analyse si la "valeur par défaut" ne résoud pas le problème...
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
mat
Real Phil wrote:
Bonjour,
Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ] Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de placer dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS Date_Louée="" FIN
Salut Réal, La même problème existe des fois avec des tables alimentés par des requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne (outer join), la table affiche n'importe quoi. Alors, je fais une chose comme toi: si table.col1 = 0 alors table.col2 = ""
Le bout de code ci-dessus, pourqoi passer par position dans ce cas? si date_louee..valeurAffichée = "00:00" alors date_louee = ""
Salutations Mat
Real Phil wrote:
Bonjour,
Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ]
Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne
bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de placer
dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS
Date_Louée=""
FIN
Salut Réal,
La même problème existe des fois avec des tables alimentés par des
requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne
(outer join), la table affiche n'importe quoi. Alors, je fais une chose
comme toi:
si table.col1 = 0 alors table.col2 = ""
Le bout de code ci-dessus, pourqoi passer par position dans ce cas?
si date_louee..valeurAffichée = "00:00" alors date_louee = ""
Depuis la description d'une champ table (fichier) d'une fenêtre, si "[ ] Mise à blanc si zéro" est coché pour une rubrique Date, cela fonctionne bien. Mais si la Date est un champ DateHeure ça ne fonctionne pas.
Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de placer dans le Code sous Affichage d'une ligne;
SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS Date_Louée="" FIN
Salut Réal, La même problème existe des fois avec des tables alimentés par des requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne (outer join), la table affiche n'importe quoi. Alors, je fais une chose comme toi: si table.col1 = 0 alors table.col2 = ""
Le bout de code ci-dessus, pourqoi passer par position dans ce cas? si date_louee..valeurAffichée = "00:00" alors date_louee = ""
Salutations Mat
Real Phil
> > Bonjour, > > Personne n'a de problème avec les champs DateHeure?? Curieux.
Il est possible que ce soit le cas mais que le problème a été contourné. Par exemple en WD7.5 (mais je ne pense pas qu'ils aient changé avec la 8 ou la 9), HeureValide("") renvoie vrai. Pour eux, c'est normal (c'est ce que renvoyait également la 5.5) alors que DateValide("") renvoie faux.
A mon avis, c'est la composante heure de la variable DateHeure qui provoque ce genre de désagréments. (je crois me souvenir que les tris sur les variables dateheure étaient également bogués, mais cela a peut-être été corrigé depuis).
> Est-ce que vous faites aussi la même chose?
Essaye de regarder dans l'analyse si la "valeur par défaut" ne résoud pas le problème...
=================== Salut Romain,
Finalement il faut seulement s'habituer avec le champs DateHeure mais je pense que ce serait tellement simple pour eux de fournir une propriété « SI MaDateHeure..Vide ALORS » quoique ce serait aussi très simple pour nous de faire une fonction pour ça.
C'est certain que HeureValide() sera toujours à vrai puisque 00:00:00 existe et est effectivement valide.
Finalement, après de nombreux tests (n'étant pas habitué avec ce genre de champ) j'en conclus que le plus simple est de tester la validité sur la date dans le style « SI Valide(MaDateHeure..PartieDate)úux ALORS »
Cordialement,
Réal Phil
> > Bonjour,
>
> Personne n'a de problème avec les champs DateHeure?? Curieux.
Il est possible que ce soit le cas mais que le problème a été
contourné.
Par exemple en WD7.5 (mais je ne pense pas qu'ils aient changé avec la
8 ou la 9), HeureValide("") renvoie vrai.
Pour eux, c'est normal (c'est ce que renvoyait également la 5.5) alors
que DateValide("") renvoie faux.
A mon avis, c'est la composante heure de la variable DateHeure qui
provoque ce genre de désagréments.
(je crois me souvenir que les tris sur les variables dateheure étaient
également bogués, mais cela a peut-être été corrigé depuis).
> Est-ce que vous faites aussi la même chose?
Essaye de regarder dans l'analyse si la "valeur par défaut" ne résoud
pas le problème...
===================
Salut Romain,
Finalement il faut seulement s'habituer avec le champs DateHeure mais je
pense que ce serait tellement simple pour eux de fournir une propriété « SI
MaDateHeure..Vide ALORS » quoique ce serait aussi très simple pour nous de
faire une fonction pour ça.
C'est certain que HeureValide() sera toujours à vrai puisque 00:00:00 existe
et est effectivement valide.
Finalement, après de nombreux tests (n'étant pas habitué avec ce genre de
champ) j'en conclus que le plus simple est de tester la validité sur la date
dans le style « SI Valide(MaDateHeure..PartieDate)úux ALORS »
> > Bonjour, > > Personne n'a de problème avec les champs DateHeure?? Curieux.
Il est possible que ce soit le cas mais que le problème a été contourné. Par exemple en WD7.5 (mais je ne pense pas qu'ils aient changé avec la 8 ou la 9), HeureValide("") renvoie vrai. Pour eux, c'est normal (c'est ce que renvoyait également la 5.5) alors que DateValide("") renvoie faux.
A mon avis, c'est la composante heure de la variable DateHeure qui provoque ce genre de désagréments. (je crois me souvenir que les tris sur les variables dateheure étaient également bogués, mais cela a peut-être été corrigé depuis).
> Est-ce que vous faites aussi la même chose?
Essaye de regarder dans l'analyse si la "valeur par défaut" ne résoud pas le problème...
=================== Salut Romain,
Finalement il faut seulement s'habituer avec le champs DateHeure mais je pense que ce serait tellement simple pour eux de fournir une propriété « SI MaDateHeure..Vide ALORS » quoique ce serait aussi très simple pour nous de faire une fonction pour ça.
C'est certain que HeureValide() sera toujours à vrai puisque 00:00:00 existe et est effectivement valide.
Finalement, après de nombreux tests (n'étant pas habitué avec ce genre de champ) j'en conclus que le plus simple est de tester la validité sur la date dans le style « SI Valide(MaDateHeure..PartieDate)úux ALORS »
Cordialement,
Réal Phil
Real Phil
> > Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de
placer
> dans le Code sous Affichage d'une ligne; > > SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS > Date_Louée="" > FIN >
Salut Réal, La même problème existe des fois avec des tables alimentés par des requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne (outer join), la table affiche n'importe quoi. Alors, je fais une chose comme toi: si table.col1 = 0 alors table.col2 = ""
Le bout de code ci-dessus, pourqoi passer par position dans ce cas? si date_louee..valeurAffichée = "00:00" alors date_louee = ""
La même problème existe des fois avec des tables alimentés par des requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne (outer join), la table affiche n'importe quoi. Alors, je fais une chose comme toi: si table.col1 = 0 alors table.col2 = ""
Ha ça c'est bon à savoir, je vais me méfier.
Comme je viens de répondre à Romain, c'est une question de s'habituer avec ces champs DateHeure. Je n'avais jamais joué avec ça avant.
Finalement, je crois que la meilleure façon de vérifier si une DateHeure contient quelque chose, c'est avec SI DateValide(MaDateHeure..PartieDate)úux ALORS...
Le bout de code ci-dessus, pourqoi passer par position dans ce cas? si date_louee..valeurAffichée = "00:00" alors date_louee = ""
Parce que la valeur affichée est sous le format "__/__/____ 00:00:00" et que si on valide avec ="00:00" ce sera toujours faux.
Réal Phil
> > Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de
placer
> dans le Code sous Affichage d'une ligne;
>
> SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS
> Date_Louée=""
> FIN
>
Salut Réal,
La même problème existe des fois avec des tables alimentés par des
requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne
(outer join), la table affiche n'importe quoi. Alors, je fais une chose
comme toi:
si table.col1 = 0 alors table.col2 = ""
Le bout de code ci-dessus, pourqoi passer par position dans ce cas?
si date_louee..valeurAffichée = "00:00" alors date_louee = ""
La même problème existe des fois avec des tables alimentés par des
requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne
(outer join), la table affiche n'importe quoi. Alors, je fais une chose
comme toi:
si table.col1 = 0 alors table.col2 = ""
Ha ça c'est bon à savoir, je vais me méfier.
Comme je viens de répondre à Romain, c'est une question de s'habituer avec
ces champs DateHeure. Je n'avais jamais joué avec ça avant.
Finalement, je crois que la meilleure façon de vérifier si une
DateHeure contient quelque chose, c'est avec
SI DateValide(MaDateHeure..PartieDate)úux ALORS...
Le bout de code ci-dessus, pourqoi passer par position dans ce cas?
si date_louee..valeurAffichée = "00:00" alors date_louee = ""
Parce que la valeur affichée est sous le format "__/__/____ 00:00:00" et que
si on valide avec ="00:00" ce sera toujours faux.
> > Le seul truc que j'ai trouvé pour obtenir le résultat souhaité est de
placer
> dans le Code sous Affichage d'une ligne; > > SI Position(Date_Louée..ValeurAffichée,"00:00")>0 ALORS > Date_Louée="" > FIN >
Salut Réal, La même problème existe des fois avec des tables alimentés par des requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne (outer join), la table affiche n'importe quoi. Alors, je fais une chose comme toi: si table.col1 = 0 alors table.col2 = ""
Le bout de code ci-dessus, pourqoi passer par position dans ce cas? si date_louee..valeurAffichée = "00:00" alors date_louee = ""
La même problème existe des fois avec des tables alimentés par des requêtes multi-fichiers : lorsqu'il n'y a pas de valeur dans une colonne (outer join), la table affiche n'importe quoi. Alors, je fais une chose comme toi: si table.col1 = 0 alors table.col2 = ""
Ha ça c'est bon à savoir, je vais me méfier.
Comme je viens de répondre à Romain, c'est une question de s'habituer avec ces champs DateHeure. Je n'avais jamais joué avec ça avant.
Finalement, je crois que la meilleure façon de vérifier si une DateHeure contient quelque chose, c'est avec SI DateValide(MaDateHeure..PartieDate)úux ALORS...
Le bout de code ci-dessus, pourqoi passer par position dans ce cas? si date_louee..valeurAffichée = "00:00" alors date_louee = ""
Parce que la valeur affichée est sous le format "__/__/____ 00:00:00" et que si on valide avec ="00:00" ce sera toujours faux.
Réal Phil
Real Phil
Romain,
Heu... bien sûr, quand je disais dans mon email précédent
...tester la validité sur la date dans le style « SI Valide(MaDateHeure..PartieDate)úux ALORS »
...je voulais dire « SI DateValide(MaDateHeure..PartieDate)úux ALORS »
Réal Phil
Romain,
Heu... bien sûr, quand je disais dans mon email précédent
...tester la validité sur la date
dans le style « SI Valide(MaDateHeure..PartieDate)úux ALORS »
...je voulais dire
« SI DateValide(MaDateHeure..PartieDate)úux ALORS »
Heu... bien sûr, quand je disais dans mon email précédent
...tester la validité sur la date dans le style « SI Valide(MaDateHeure..PartieDate)úux ALORS »
...je voulais dire « SI DateValide(MaDateHeure..PartieDate)úux ALORS »
Réal Phil
Romain PETIT
Real Phil avait énoncé :
C'est certain que HeureValide() sera toujours à vrai puisque 00:00:00 existe et est effectivement valide.
Oui, mais pour moi ce n'est pas logique : Que HeureValide("0") renvoie vrai, OK, mais pas HeureValide("").
C'est bien une des choses qui m'agace avec WD, il y a souvent confusion de genre. Pour moi, la valeur vide (ou "nulle") n'est pas équivalente à la valeur 0.
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Real Phil avait énoncé :
C'est certain que HeureValide() sera toujours à vrai puisque 00:00:00 existe
et est effectivement valide.
Oui, mais pour moi ce n'est pas logique :
Que HeureValide("0") renvoie vrai, OK, mais pas HeureValide("").
C'est bien une des choses qui m'agace avec WD, il y a souvent confusion
de genre.
Pour moi, la valeur vide (ou "nulle") n'est pas équivalente à la valeur
0.
A+
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
C'est certain que HeureValide() sera toujours à vrai puisque 00:00:00 existe et est effectivement valide.
Oui, mais pour moi ce n'est pas logique : Que HeureValide("0") renvoie vrai, OK, mais pas HeureValide("").
C'est bien une des choses qui m'agace avec WD, il y a souvent confusion de genre. Pour moi, la valeur vide (ou "nulle") n'est pas équivalente à la valeur 0.
A+
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Romain PETIT
Dans son message précédent, Real Phil a écrit :
SI DateValide(MaDateHeure..PartieDate)úux ALORS...
Tiens, en parlant de validité de date, je viens de lire en face que le 29/02/2005 est une date valide pour WD9 ! C'est confirmé ? Que donne Info(DateValide("20050229")) en WD9, et en WD8 ?
En WD7.5, c'est bien faux...
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Dans son message précédent, Real Phil a écrit :
SI DateValide(MaDateHeure..PartieDate)úux ALORS...
Tiens, en parlant de validité de date, je viens de lire en face que le
29/02/2005 est une date valide pour WD9 !
C'est confirmé ?
Que donne Info(DateValide("20050229")) en WD9, et en WD8 ?
En WD7.5, c'est bien faux...
--
Romain PETIT
http://cerbermail.com/?O16kfXOFcq
(cliquez sur le lien ci-dessus pour me contacter en privé)
SI DateValide(MaDateHeure..PartieDate)úux ALORS...
Tiens, en parlant de validité de date, je viens de lire en face que le 29/02/2005 est une date valide pour WD9 ! C'est confirmé ? Que donne Info(DateValide("20050229")) en WD9, et en WD8 ?
En WD7.5, c'est bien faux...
-- Romain PETIT http://cerbermail.com/?O16kfXOFcq (cliquez sur le lien ci-dessus pour me contacter en privé)
Pascal F
Romain PETIT a formulé la demande :
Info(DateValide("20050229"))
renvoi 0 ^^
-- Pascal
Ne garder que le prénom pour me joindre
Romain PETIT a formulé la demande :
Info(DateValide("20050229"))
renvoi 0 ^^
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
