Le caractère & me pose un sérieux problème dû au fait que selon le type de
champ ou il est affiché il apparait soit comme &, soit comme _, si je veux
remplacer le _ par &, il suffit d'entrer &&.
Le problème est que si je fais cela dans les champs ou & s'affiche
correctement &, je me retrouve alors avec && affiché
Quelqu'un aurait t'il une solution pour que & s'affiche toujours & et jamais
_ ni && ?
--
Sincères salutations
Jean-Claude FLAJOULOT
Email : sp_nospamm_etb@tiscali.fr
(otez _nospamm_ pour me contacter)
Sécurité Pointage & Biométrie
http://sp-et-b.chez-alice.fr/
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
paratge
Sécurité Pointage & Biométrie a écrit :
Bonjour,
Le caractère & me pose un sérieux problème dû au fait que selon le type de champ ou il est affiché il apparait soit comme &, soit comme _, si je veux remplacer le _ par &, il suffit d'entrer &&. Le problème est que si je fais cela dans les champs ou & s'affiche correctement &, je me retrouve alors avec && affiché Quelqu'un aurait t'il une solution pour que & s'affiche toujours & et jamais _ ni && ?
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Sécurité Pointage & Biométrie a écrit :
Bonjour,
Le caractère & me pose un sérieux problème dû au fait que selon le type
de champ ou il est affiché il apparait soit comme &, soit comme _, si je
veux remplacer le _ par &, il suffit d'entrer &&.
Le problème est que si je fais cela dans les champs ou & s'affiche
correctement &, je me retrouve alors avec && affiché
Quelqu'un aurait t'il une solution pour que & s'affiche toujours & et
jamais _ ni && ?
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le
problème en utilisant caract(38)
Le caractère & me pose un sérieux problème dû au fait que selon le type de champ ou il est affiché il apparait soit comme &, soit comme _, si je veux remplacer le _ par &, il suffit d'entrer &&. Le problème est que si je fais cela dans les champs ou & s'affiche correctement &, je me retrouve alors avec && affiché Quelqu'un aurait t'il une solution pour que & s'affiche toujours & et jamais _ ni && ?
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Sécurité Pointage & Biométrie
"paratge" a écrit dans le message de news:
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie". Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré "Sécurité Pointage && Biométrie". Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas OK. Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
-- Sincères salutations
Jean-Claude FLAJOULOT Email : (otez _nospamm_ pour me contacter) Sécurité Pointage & Biométrie http://sp-et-b.chez-alice.fr/
"paratge" <jjb@2jbconcepts.fr> a écrit dans le message de news:
43C3C961.2000603@2jbconcepts.fr...
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le
problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à
un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie".
Si je veux ensuite afficher le contenu du champ du fichier dans un libellé
ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie"
affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de
saise en ayant en registré "Sécurité Pointage && Biométrie".
Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de
tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans
son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur
l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas
OK.
Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
--
Sincères salutations
Jean-Claude FLAJOULOT
Email : sp_nospamm_etb@tiscali.fr
(otez _nospamm_ pour me contacter)
Sécurité Pointage & Biométrie
http://sp-et-b.chez-alice.fr/
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie". Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré "Sécurité Pointage && Biométrie". Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas OK. Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
-- Sincères salutations
Jean-Claude FLAJOULOT Email : (otez _nospamm_ pour me contacter) Sécurité Pointage & Biométrie http://sp-et-b.chez-alice.fr/
Pascal F
Sécurité Pointage & Biométrie a couché sur son écran :
"paratge" a écrit dans le message de news:
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie". Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré "Sécurité Pointage && Biométrie". Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas OK. Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
Si j'ai bonne mémoire, le problème est (était) identique avec VB6 .
-- Pascal
Ne garder que le prénom pour me joindre
Sécurité Pointage & Biométrie a couché sur son écran :
"paratge" <jjb@2jbconcepts.fr> a écrit dans le message de news: 43C3C961.2000603@2jbconcepts.fr...
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité
Pointage caract(38) Biométrie".
Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité
Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré
"Sécurité Pointage && Biométrie".
Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait
saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ
de fichier) texte pas OK.
Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
Si j'ai bonne mémoire, le problème est (était) identique avec VB6 .
--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre
Sécurité Pointage & Biométrie a couché sur son écran :
"paratge" a écrit dans le message de news:
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie". Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré "Sécurité Pointage && Biométrie". Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas OK. Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
Si j'ai bonne mémoire, le problème est (était) identique avec VB6 .
-- Pascal
Ne garder que le prénom pour me joindre
Bruno A
Sécurité Pointage & Biométrie a écrit :
"paratge" a écrit dans le message de news:
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie". Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré "Sécurité Pointage && Biométrie". Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas OK. Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
effectivement j'ai ce pb en 5.5 à l'affichage dans une combo graphique et pour couper court à tout j'ai interdit le caractère & dans la saisie de la table correspondante mais j'en conviens ce n'est pas la meilleur solution...
-- Bruno A
suivre ce lien pour répondre : http://cerbermail.com/?TF4s3h4ejs ;)
Sécurité Pointage & Biométrie a écrit :
"paratge" <jjb@2jbconcepts.fr> a écrit dans le message de news:
43C3C961.2000603@2jbconcepts.fr...
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le
problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie
associé à un fichier, je ne vais pas saisir "Sécurité Pointage
caract(38) Biométrie".
Si je veux ensuite afficher le contenu du champ du fichier dans un
libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage
_Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche
dans un champ de saise en ayant en registré "Sécurité Pointage &&
Biométrie".
Je ne veux pas non plus avoir à gérer le contenu de tous les champs
texte de tous mes fichiers au cas ou un utilisateur aurait saisi le
caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur
l'affichage du contenu d'une variable (ou d'un champ de fichier) texte
pas OK.
Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
effectivement j'ai ce pb en 5.5 à l'affichage dans une combo graphique
et pour couper court à tout j'ai interdit le caractère & dans la saisie
de la table correspondante mais j'en conviens ce n'est pas la meilleur
solution...
--
Bruno A
suivre ce lien pour répondre :
http://cerbermail.com/?TF4s3h4ejs
;)
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Bonjour,
Si je met "Sécurité Pointage & Biométrie" dans un champ de saisie associé à un fichier, je ne vais pas saisir "Sécurité Pointage caract(38) Biométrie". Si je veux ensuite afficher le contenu du champ du fichier dans un libellé ou dans un message, je ne veux pas avoir "Sécurité Pointage _Biométrie" affiché ou "Sécurité Pointage && Biométrie" si j'affiche dans un champ de saise en ayant en registré "Sécurité Pointage && Biométrie". Je ne veux pas non plus avoir à gérer le contenu de tous les champs texte de tous mes fichiers au cas ou un utilisateur aurait saisi le caractère & dans son texte.
Que & soit un opérateur d'adresse dans le code OK, mais qu'il influe sur l'affichage du contenu d'une variable (ou d'un champ de fichier) texte pas OK. Le problème existait déjà en 5.5 et se trouve toujours sous WD10 !!!
effectivement j'ai ce pb en 5.5 à l'affichage dans une combo graphique et pour couper court à tout j'ai interdit le caractère & dans la saisie de la table correspondante mais j'en conviens ce n'est pas la meilleur solution...
-- Bruno A
suivre ce lien pour répondre : http://cerbermail.com/?TF4s3h4ejs ;)
Michel
Bruno A a écrit :
Sécurité Pointage & Biométrie a écrit :
"paratge" a écrit dans le message de news:
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Le comportement du caractère & peut- être étonnant, dans le cas d'unc chaine XML il peut interférer de manière très bizarre Ex dans la procedure ci-dessous: le parsing de SourceXML donne seulement Savoirs -> Le savoir se mesure et se transmet Le parsing de SourceXML1 donne body-> competence -> savoirs ->le savoir se mesure & se transmet
Dans le cas présent la chaine de caractère provenait d'un service Web (non Windev) avec un encodage correct en UTF8 mais ignoré par Windev donc le & n'est pas conservé lors du parsing. Ce qui est consternant c'est que la casse du nom des balises et des attributs ne soient pas respectées dans le second cas.
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
PROCEDURE Bug()
Res est un booléen SourceXML est une chaîne SourceXML1 est une chaîne
SourceXML = [ <Competence Savoirs = " Le savoir se mesure et se transmet"></Competence>
] SourceXML1 = [ <Competence Savoirs = " Le savoir se mesure & se transmet"></Competence>
]
//Création du document XML Res = XMLDocument("DocXML", SourceXML1) //Pour l'autre cas permuter SourceXML1 et SourceXML
//Le document est créé ? SI Res = Faux ALORS erreur("Le problème suivant a été détecté : "+ ErreurInfo()) FIN
XMLRacine("DocXML")
XMLRecherche("DocXML", Null ,XMLContinue+XMLSousElément) TANTQUE XMLTrouve("DocXML") Info(XMLNomElément("DocXML")+"->"+XMLDonnée("DocXML")) //Elément suivant dans la recherche XMLSuivant("DocXML") FIN
XMLAnnuleRecherche("DocXML")
XMLTermine("DocXML")
Bruno A a écrit :
Sécurité Pointage & Biométrie a écrit :
"paratge" <jjb@2jbconcepts.fr> a écrit dans le message de news:
43C3C961.2000603@2jbconcepts.fr...
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le
problème en utilisant caract(38)
Le comportement du caractère & peut- être étonnant,
dans le cas d'unc chaine XML il peut interférer de manière très bizarre
Ex dans la procedure ci-dessous:
le parsing de SourceXML donne seulement Savoirs -> Le savoir se mesure
et se transmet
Le parsing de SourceXML1 donne
body->
competence ->
savoirs ->le savoir se mesure & se transmet
Dans le cas présent la chaine de caractère provenait d'un service Web
(non Windev) avec un encodage correct en UTF8 mais ignoré par Windev
donc le & n'est pas conservé lors du parsing.
Ce qui est consternant c'est que la casse du nom des balises et des
attributs ne soient pas respectées dans le second cas.
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
PROCEDURE Bug()
Res est un booléen
SourceXML est une chaîne
SourceXML1 est une chaîne
SourceXML = [
<Competence Savoirs = " Le savoir se mesure et se transmet"></Competence>
]
SourceXML1 = [
<Competence Savoirs = " Le savoir se mesure & se transmet"></Competence>
]
//Création du document XML
Res = XMLDocument("DocXML", SourceXML1) //Pour l'autre cas permuter
SourceXML1 et SourceXML
//Le document est créé ?
SI Res = Faux ALORS
erreur("Le problème suivant a été détecté : "+ ErreurInfo())
FIN
XMLRacine("DocXML")
XMLRecherche("DocXML", Null ,XMLContinue+XMLSousElément)
TANTQUE XMLTrouve("DocXML")
Info(XMLNomElément("DocXML")+"->"+XMLDonnée("DocXML"))
//Elément suivant dans la recherche
XMLSuivant("DocXML")
FIN
Le caractère "&" est un opérateur d'adresse Windev, j'avais résolu le problème en utilisant caract(38)
Le comportement du caractère & peut- être étonnant, dans le cas d'unc chaine XML il peut interférer de manière très bizarre Ex dans la procedure ci-dessous: le parsing de SourceXML donne seulement Savoirs -> Le savoir se mesure et se transmet Le parsing de SourceXML1 donne body-> competence -> savoirs ->le savoir se mesure & se transmet
Dans le cas présent la chaine de caractère provenait d'un service Web (non Windev) avec un encodage correct en UTF8 mais ignoré par Windev donc le & n'est pas conservé lors du parsing. Ce qui est consternant c'est que la casse du nom des balises et des attributs ne soient pas respectées dans le second cas.
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
PROCEDURE Bug()
Res est un booléen SourceXML est une chaîne SourceXML1 est une chaîne
SourceXML = [ <Competence Savoirs = " Le savoir se mesure et se transmet"></Competence>
] SourceXML1 = [ <Competence Savoirs = " Le savoir se mesure & se transmet"></Competence>
]
//Création du document XML Res = XMLDocument("DocXML", SourceXML1) //Pour l'autre cas permuter SourceXML1 et SourceXML
//Le document est créé ? SI Res = Faux ALORS erreur("Le problème suivant a été détecté : "+ ErreurInfo()) FIN
XMLRacine("DocXML")
XMLRecherche("DocXML", Null ,XMLContinue+XMLSousElément) TANTQUE XMLTrouve("DocXML") Info(XMLNomElément("DocXML")+"->"+XMLDonnée("DocXML")) //Elément suivant dans la recherche XMLSuivant("DocXML") FIN
XMLAnnuleRecherche("DocXML")
XMLTermine("DocXML")
Emmanuel Haefele
"Michel" a écrit :
Bonjour Michhel,
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
Le voici :
Avec SourceXML, tout est ok.
Avec SourceXML1, ErreurInfo() indique que le document n'est pas au format xml :-(
Amicalement,
Emmanuel Haefelé.
"Michel" <michel.roger@items-si.fr> a écrit :
Bonjour Michhel,
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
Le voici :
Avec SourceXML, tout est ok.
Avec SourceXML1, ErreurInfo() indique que le document n'est pas au format
xml :-(
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
Le voici :
Avec SourceXML, tout est ok.
Avec SourceXML1, ErreurInfo() indique que le document n'est pas au format xml :-(
Amicalement,
Emmanuel Haefelé.
Michel
Emmanuel Haefele a écrit :
"Michel" a écrit :
Bonjour Michhel,
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
Le voici :
Avec SourceXML, tout est ok.
Avec SourceXML1, ErreurInfo() indique que le document n'est pas au format xml :-(
Amicalement,
Emmanuel Haefelé.
Merci Emmanuel
Cela me rassure, c'est plus logique.
On peu supposer (réver)que les autres fonctions on été réecrites et que l'encodage est cohérent d'un bout à l'autre. Je me pencherai sur cet aspect une autre fois.
Amitiés
Michel
Emmanuel Haefele a écrit :
"Michel" <michel.roger@items-si.fr> a écrit :
Bonjour Michhel,
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
Le voici :
Avec SourceXML, tout est ok.
Avec SourceXML1, ErreurInfo() indique que le document n'est pas au format
xml :-(
Amicalement,
Emmanuel Haefelé.
Merci Emmanuel
Cela me rassure, c'est plus logique.
On peu supposer (réver)que les autres fonctions on été réecrites et que
l'encodage est cohérent d'un bout à l'autre.
Je me pencherai sur cet aspect une autre fois.
si qq'un veut s'amuser à tester en 10, je serai curieux du résultat ?
Le voici :
Avec SourceXML, tout est ok.
Avec SourceXML1, ErreurInfo() indique que le document n'est pas au format xml :-(
Amicalement,
Emmanuel Haefelé.
Merci Emmanuel
Cela me rassure, c'est plus logique.
On peu supposer (réver)que les autres fonctions on été réecrites et que l'encodage est cohérent d'un bout à l'autre. Je me pencherai sur cet aspect une autre fois.
