L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à 160),
étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte sus-cité
comporte lui même des saut de ligne, il vont être pris en compte dans le
fichier.txt, et ça va aussi faire des saut de lignes.
Exemple:
saisie = un <rc> deux
fichier.txt =
un
deux
Le second problème est que j'exploite le fichier en comptant les lignes,
j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais
bon, c'est ainsi désormais.
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par
enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le
nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la
saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Question :
Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte qui
contient des <rc> ceux-ci ne soient pas pris en compte lors de cet
enregistrement dans le fichier, mais qu'en restituant le texte on retrouve
les <rc> (en conservant ma construction évidemment, sinon je sais faire,
l'erreur et de ne pas y avoir pensé) ???
Merci beaucoup, au revoir et à bientôt :o)
------
Site logiciels
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
Site perso
http://irolog.free.fr/joe/index.htm
Principe d'utilisation des news Groups
http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm
------------------------------------------------------------------------------------
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
Fred
X a écrit :
Bonjour,
L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à 160), étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte sus-cité comporte lui même des saut de ligne, il vont être pris en compte dans le fichier.txt, et ça va aussi faire des saut de lignes.
Le second problème est que j'exploite le fichier en comptant les lignes, j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais bon, c'est ainsi désormais.
Pourquoi faire simple !
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Un «replace» de CR avec un caractère qui n'est pas susceptible d'apparaître : par exemple vbTab Et l'inverse à la restitution. Je ne vois pas bien quel est le problème ?
Question : Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte qui contient des <rc> ceux-ci ne soient pas pris en compte lors de cet enregistrement dans le fichier, mais qu'en restituant le texte on retrouve les <rc> (en conservant ma construction évidemment, sinon je sais faire, l'erreur et de ne pas y avoir pensé) ???
Cela relèverait de la magie.
X a écrit :
Bonjour,
L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à 160),
étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte sus-cité
comporte lui même des saut de ligne, il vont être pris en compte dans le
fichier.txt, et ça va aussi faire des saut de lignes.
Le second problème est que j'exploite le fichier en comptant les lignes,
j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais
bon, c'est ainsi désormais.
Pourquoi faire simple !
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par
enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le
nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la
saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Un «replace» de CR avec un caractère qui n'est pas susceptible
d'apparaître : par exemple vbTab
Et l'inverse à la restitution.
Je ne vois pas bien quel est le problème ?
Question :
Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte qui
contient des <rc> ceux-ci ne soient pas pris en compte lors de cet
enregistrement dans le fichier, mais qu'en restituant le texte on retrouve
les <rc> (en conservant ma construction évidemment, sinon je sais faire,
l'erreur et de ne pas y avoir pensé) ???
L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à 160), étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte sus-cité comporte lui même des saut de ligne, il vont être pris en compte dans le fichier.txt, et ça va aussi faire des saut de lignes.
Le second problème est que j'exploite le fichier en comptant les lignes, j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais bon, c'est ainsi désormais.
Pourquoi faire simple !
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Un «replace» de CR avec un caractère qui n'est pas susceptible d'apparaître : par exemple vbTab Et l'inverse à la restitution. Je ne vois pas bien quel est le problème ?
Question : Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte qui contient des <rc> ceux-ci ne soient pas pris en compte lors de cet enregistrement dans le fichier, mais qu'en restituant le texte on retrouve les <rc> (en conservant ma construction évidemment, sinon je sais faire, l'erreur et de ne pas y avoir pensé) ???
Cela relèverait de la magie.
X
Je voulais juste savoir à tout hasard s'il y avait un truc ???
------ Site logiciels http://irolog.free.fr Mail http://irolog.free.fr/ecrire/index.htm Site perso http://irolog.free.fr/joe/index.htm Principe d'utilisation des news Groups http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm ------------------------------------------------------------------------------------ "Fred" a écrit dans le message de news: %
X a écrit :
Bonjour,
L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à 160), étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte sus-cité comporte lui même des saut de ligne, il vont être pris en compte dans le fichier.txt, et ça va aussi faire des saut de lignes.
Le second problème est que j'exploite le fichier en comptant les lignes, j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais bon, c'est ainsi désormais.
Pourquoi faire simple !
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Un «replace» de CR avec un caractère qui n'est pas susceptible d'apparaître : par exemple vbTab Et l'inverse à la restitution. Je ne vois pas bien quel est le problème ?
Question : Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte qui contient des <rc> ceux-ci ne soient pas pris en compte lors de cet enregistrement dans le fichier, mais qu'en restituant le texte on retrouve les <rc> (en conservant ma construction évidemment, sinon je sais faire, l'erreur et de ne pas y avoir pensé) ???
Cela relèverait de la magie.
Je voulais juste savoir à tout hasard s'il y avait un truc ???
------
Site logiciels
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
Site perso
http://irolog.free.fr/joe/index.htm
Principe d'utilisation des news Groups
http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm
------------------------------------------------------------------------------------
"Fred" <foleide@libre.france> a écrit dans le message de news:
%23hI3lFoTGHA.1688@TK2MSFTNGP11.phx.gbl...
X a écrit :
Bonjour,
L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à
160), étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte
sus-cité comporte lui même des saut de ligne, il vont être pris en compte
dans le fichier.txt, et ça va aussi faire des saut de lignes.
Le second problème est que j'exploite le fichier en comptant les lignes,
j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais
bon, c'est ainsi désormais.
Pourquoi faire simple !
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par
enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le
nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la
saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Un «replace» de CR avec un caractère qui n'est pas susceptible
d'apparaître : par exemple vbTab
Et l'inverse à la restitution.
Je ne vois pas bien quel est le problème ?
Question :
Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte
qui contient des <rc> ceux-ci ne soient pas pris en compte lors de cet
enregistrement dans le fichier, mais qu'en restituant le texte on
retrouve les <rc> (en conservant ma construction évidemment, sinon je
sais faire, l'erreur et de ne pas y avoir pensé) ???
Je voulais juste savoir à tout hasard s'il y avait un truc ???
------ Site logiciels http://irolog.free.fr Mail http://irolog.free.fr/ecrire/index.htm Site perso http://irolog.free.fr/joe/index.htm Principe d'utilisation des news Groups http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm ------------------------------------------------------------------------------------ "Fred" a écrit dans le message de news: %
X a écrit :
Bonjour,
L'utilisateur peut saisir en mutilignes, un texte libre (tronqué à 160), étant entendu que le texte peut comporter des <rc>...
Le problème est qu'un fois rangé dans le fichier txt, si le texte sus-cité comporte lui même des saut de ligne, il vont être pris en compte dans le fichier.txt, et ça va aussi faire des saut de lignes.
Le second problème est que j'exploite le fichier en comptant les lignes, j'aurais dû plutôt mettre des bornes avec mot réservé, genre "$£§", mais bon, c'est ainsi désormais.
Pourquoi faire simple !
Alors évidemment ça fausse tout, si je compte par exemple 18 lignes par enregistrement, et qu'à cause des <rc> dans la zone de saisie texte, le nombre de lignes augmente, ça plante tout !
Je me suis contenté de rafistoler en remplaçant tout <rc> venant de la saisie, par 2 espaces dans le fichier, qui restituera le texte ainsi...
Un «replace» de CR avec un caractère qui n'est pas susceptible d'apparaître : par exemple vbTab Et l'inverse à la restitution. Je ne vois pas bien quel est le problème ?
Question : Est-ce qu'il y aurait une méthode pour qu'en enregistrant une zone texte qui contient des <rc> ceux-ci ne soient pas pris en compte lors de cet enregistrement dans le fichier, mais qu'en restituant le texte on retrouve les <rc> (en conservant ma construction évidemment, sinon je sais faire, l'erreur et de ne pas y avoir pensé) ???
Cela relèverait de la magie.
Gloops
X a écrit :
Je voulais juste savoir à tout hasard s'il y avait un truc ???
Bonjour,
Si il y avait un "truc", comme tu dis, on ne nous aurait pas parlé de "virus" sur les RFID, les successeurs des codes-barres.
Le seul principe est d'avoir un séparateur qui ne puisse pas se trouver dans le texte à traiter.
Par exemple : strSep = "SixCentSixSousCesSixCentSixSaucisonsCi?MaisC'estCarrementAnticonstitutionnel!"
txtEntree = Replace(txtEntree, strSep, "")
et on pourra avoir à traiter : strSep + txtEntree + strSep
Après il faut se débrouiller pour savoir quoi en faire, car pour une requête SQL le séparateur habituel est le guillemet. Mais là si je continue ça suppose des digressions sur le développement SQL, on n'est pas au bout. ça pourrait être intéressant de continuer sur un newsgroup consacré à SQL d'ailleurs. Si ça se trouve ça a déjà été fait.
Si c'est trop casse-tête on recourt à des jeux d'enregistrements.
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte, celui-ci passera à la trappe, on peut concevoir un message qui alerte l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _ "ne doit pas figurer dans la zone de texte. " + _ "Veuillez rectifier SVP."
Cancel = True End If
en faisant attention d'utiliser ça dans une procédure événementielle qui comporte un paramètre Cancel permettant d'inhiber la fermeture du formulaire.
Si on ne fait pas le contrôle de la présence du séparateur dans la zone de texte, on diffuse à des milliers d'exemplaires un système d'exploitation qui devra faire l'objet chaque mois d'une ribambelle de mises à jour pour "faille de sécurité" car un pirate aura trouvé le séparateur et aura su quoi mettre derrière pour faire des blagues à sa sauce, pas toujours de bon goût. Heureusement au bout d'un moment on comprend l'ampleur du problème, et on décide enfin de retarder la sortie de la version suivante pour resserrer les boulons. Il y aura des méchantes langues pour dire qu'économiquement c'est une mauvaise nouvelle, car les méchantes langues aiment bien raisonner à courte vue.
J'ai *un peu* élargi le sujet, non ? Bon allez je reviens. Bien entendu on peut mettre un séparateur plus court. C'est rare qu'un utilisateur lambda tape "@#@" dans une zone de texte, pour faire joli. D'ailleurs, pour une requête SQL, c'est mieux que le séparateur soit plus court, sauf si on réussit à éviter qu'il passe dans la requête.
Si tu prends le retour curseur comme séparateur, ça oblige à retirer les retours curseur du contenu de la zone de texte. Ne serait-ce pas un chouïa plus simple de prendre le problème dans l'autre sens ?
Enfin bon, c'est juste une suggestion comme ça sans avoir creusé ...
X a écrit :
Je voulais juste savoir à tout hasard s'il y avait un truc ???
Bonjour,
Si il y avait un "truc", comme tu dis, on ne nous aurait pas parlé de
"virus" sur les RFID, les successeurs des codes-barres.
Le seul principe est d'avoir un séparateur qui ne puisse pas se trouver
dans le texte à traiter.
Par exemple :
strSep =
"SixCentSixSousCesSixCentSixSaucisonsCi?MaisC'estCarrementAnticonstitutionnel!"
txtEntree = Replace(txtEntree, strSep, "")
et on pourra avoir à traiter :
strSep + txtEntree + strSep
Après il faut se débrouiller pour savoir quoi en faire, car pour une
requête SQL le séparateur habituel est le guillemet. Mais là si je
continue ça suppose des digressions sur le développement SQL, on n'est
pas au bout. ça pourrait être intéressant de continuer sur un newsgroup
consacré à SQL d'ailleurs. Si ça se trouve ça a déjà été fait.
Si c'est trop casse-tête on recourt à des jeux d'enregistrements.
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte,
celui-ci passera à la trappe, on peut concevoir un message qui alerte
l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then
MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _
"ne doit pas figurer dans la zone de texte. " + _
"Veuillez rectifier SVP."
Cancel = True
End If
en faisant attention d'utiliser ça dans une procédure événementielle qui
comporte un paramètre Cancel permettant d'inhiber la fermeture du
formulaire.
Si on ne fait pas le contrôle de la présence du séparateur dans la zone
de texte, on diffuse à des milliers d'exemplaires un système
d'exploitation qui devra faire l'objet chaque mois d'une ribambelle de
mises à jour pour "faille de sécurité" car un pirate aura trouvé le
séparateur et aura su quoi mettre derrière pour faire des blagues à sa
sauce, pas toujours de bon goût. Heureusement au bout d'un moment on
comprend l'ampleur du problème, et on décide enfin de retarder la sortie
de la version suivante pour resserrer les boulons. Il y aura des
méchantes langues pour dire qu'économiquement c'est une mauvaise
nouvelle, car les méchantes langues aiment bien raisonner à courte vue.
J'ai *un peu* élargi le sujet, non ?
Bon allez je reviens. Bien entendu on peut mettre un séparateur plus
court. C'est rare qu'un utilisateur lambda tape "@#@" dans une zone de
texte, pour faire joli. D'ailleurs, pour une requête SQL, c'est mieux
que le séparateur soit plus court, sauf si on réussit à éviter qu'il
passe dans la requête.
Si tu prends le retour curseur comme séparateur, ça oblige à retirer les
retours curseur du contenu de la zone de texte. Ne serait-ce pas un
chouïa plus simple de prendre le problème dans l'autre sens ?
Enfin bon, c'est juste une suggestion comme ça sans avoir creusé ...
Je voulais juste savoir à tout hasard s'il y avait un truc ???
Bonjour,
Si il y avait un "truc", comme tu dis, on ne nous aurait pas parlé de "virus" sur les RFID, les successeurs des codes-barres.
Le seul principe est d'avoir un séparateur qui ne puisse pas se trouver dans le texte à traiter.
Par exemple : strSep = "SixCentSixSousCesSixCentSixSaucisonsCi?MaisC'estCarrementAnticonstitutionnel!"
txtEntree = Replace(txtEntree, strSep, "")
et on pourra avoir à traiter : strSep + txtEntree + strSep
Après il faut se débrouiller pour savoir quoi en faire, car pour une requête SQL le séparateur habituel est le guillemet. Mais là si je continue ça suppose des digressions sur le développement SQL, on n'est pas au bout. ça pourrait être intéressant de continuer sur un newsgroup consacré à SQL d'ailleurs. Si ça se trouve ça a déjà été fait.
Si c'est trop casse-tête on recourt à des jeux d'enregistrements.
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte, celui-ci passera à la trappe, on peut concevoir un message qui alerte l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _ "ne doit pas figurer dans la zone de texte. " + _ "Veuillez rectifier SVP."
Cancel = True End If
en faisant attention d'utiliser ça dans une procédure événementielle qui comporte un paramètre Cancel permettant d'inhiber la fermeture du formulaire.
Si on ne fait pas le contrôle de la présence du séparateur dans la zone de texte, on diffuse à des milliers d'exemplaires un système d'exploitation qui devra faire l'objet chaque mois d'une ribambelle de mises à jour pour "faille de sécurité" car un pirate aura trouvé le séparateur et aura su quoi mettre derrière pour faire des blagues à sa sauce, pas toujours de bon goût. Heureusement au bout d'un moment on comprend l'ampleur du problème, et on décide enfin de retarder la sortie de la version suivante pour resserrer les boulons. Il y aura des méchantes langues pour dire qu'économiquement c'est une mauvaise nouvelle, car les méchantes langues aiment bien raisonner à courte vue.
J'ai *un peu* élargi le sujet, non ? Bon allez je reviens. Bien entendu on peut mettre un séparateur plus court. C'est rare qu'un utilisateur lambda tape "@#@" dans une zone de texte, pour faire joli. D'ailleurs, pour une requête SQL, c'est mieux que le séparateur soit plus court, sauf si on réussit à éviter qu'il passe dans la requête.
Si tu prends le retour curseur comme séparateur, ça oblige à retirer les retours curseur du contenu de la zone de texte. Ne serait-ce pas un chouïa plus simple de prendre le problème dans l'autre sens ?
Enfin bon, c'est juste une suggestion comme ça sans avoir creusé ...
Gloops
Gloops a écrit :
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte, celui-ci passera à la trappe, on peut concevoir un message qui alerte l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _ "ne doit pas figurer dans la zone de texte. " + _ "Veuillez rectifier SVP."
Cancel = True End If
On peut imaginer une version plus élaborée, qui va introduire des caractères modificateurs si le séparateur est présent dans le texte.
posSep = InStr(txtEntree, strSep) strTemp = Left$(txtEntree, pos - 1) For N = posSep To posSep + Len(strSep) strTemp = strTemp + "" + Mid$(txtEntree, N, 1) Next strTemp = strTemp + Right$(txtEntree, _ Len(txtEntree - posSep - Len(strSep)
J'indique ça pour le principe, comme je n'ai pas testé il peut y avoir besoin d'ajouter ou de retirer 1 par-ci par-là.
Si on fait ça, ça suppose d'avoir en sortie une routine qui va chercher le caractère "" dans le texte pour insérer le caractère suivant sans l'interpréter.
Gloops a écrit :
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte,
celui-ci passera à la trappe, on peut concevoir un message qui alerte
l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then
MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _
"ne doit pas figurer dans la zone de texte. " + _
"Veuillez rectifier SVP."
Cancel = True
End If
On peut imaginer une version plus élaborée, qui va introduire des
caractères modificateurs si le séparateur est présent dans le texte.
posSep = InStr(txtEntree, strSep)
strTemp = Left$(txtEntree, pos - 1)
For N = posSep To posSep + Len(strSep)
strTemp = strTemp + "" + Mid$(txtEntree, N, 1)
Next
strTemp = strTemp + Right$(txtEntree, _
Len(txtEntree - posSep - Len(strSep)
J'indique ça pour le principe, comme je n'ai pas testé il peut y avoir
besoin d'ajouter ou de retirer 1 par-ci par-là.
Si on fait ça, ça suppose d'avoir en sortie une routine qui va chercher
le caractère "" dans le texte pour insérer le caractère suivant sans
l'interpréter.
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte, celui-ci passera à la trappe, on peut concevoir un message qui alerte l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _ "ne doit pas figurer dans la zone de texte. " + _ "Veuillez rectifier SVP."
Cancel = True End If
On peut imaginer une version plus élaborée, qui va introduire des caractères modificateurs si le séparateur est présent dans le texte.
posSep = InStr(txtEntree, strSep) strTemp = Left$(txtEntree, pos - 1) For N = posSep To posSep + Len(strSep) strTemp = strTemp + "" + Mid$(txtEntree, N, 1) Next strTemp = strTemp + Right$(txtEntree, _ Len(txtEntree - posSep - Len(strSep)
J'indique ça pour le principe, comme je n'ai pas testé il peut y avoir besoin d'ajouter ou de retirer 1 par-ci par-là.
Si on fait ça, ça suppose d'avoir en sortie une routine qui va chercher le caractère "" dans le texte pour insérer le caractère suivant sans l'interpréter.
X
Tu te réponds à toit-même Gloops, je sais comment faire, je voulais simplement savoir s'il y avait une méthode particulière, mais je te remercie beaucoup :o)
------ Site logiciels http://irolog.free.fr Mail http://irolog.free.fr/ecrire/index.htm Site perso http://irolog.free.fr/joe/index.htm Principe d'utilisation des news Groups http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm ------------------------------------------------------------------------------------ "Gloops" a écrit dans le message de news: %
Gloops a écrit :
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte, celui-ci passera à la trappe, on peut concevoir un message qui alerte l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _ "ne doit pas figurer dans la zone de texte. " + _ "Veuillez rectifier SVP." Cancel = True End If
On peut imaginer une version plus élaborée, qui va introduire des caractères modificateurs si le séparateur est présent dans le texte.
posSep = InStr(txtEntree, strSep) strTemp = Left$(txtEntree, pos - 1) For N = posSep To posSep + Len(strSep) strTemp = strTemp + "" + Mid$(txtEntree, N, 1) Next strTemp = strTemp + Right$(txtEntree, _ Len(txtEntree - posSep - Len(strSep)
J'indique ça pour le principe, comme je n'ai pas testé il peut y avoir besoin d'ajouter ou de retirer 1 par-ci par-là.
Si on fait ça, ça suppose d'avoir en sortie une routine qui va chercher le caractère "" dans le texte pour insérer le caractère suivant sans l'interpréter.
Tu te réponds à toit-même Gloops, je sais comment faire, je voulais
simplement savoir s'il y avait une méthode particulière, mais je te remercie
beaucoup :o)
------
Site logiciels
http://irolog.free.fr
Mail
http://irolog.free.fr/ecrire/index.htm
Site perso
http://irolog.free.fr/joe/index.htm
Principe d'utilisation des news Groups
http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm
------------------------------------------------------------------------------------
"Gloops" <gloops@niark.invalid> a écrit dans le message de news:
%23cEGMN1TGHA.4520@TK2MSFTNGP10.phx.gbl...
Gloops a écrit :
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte,
celui-ci passera à la trappe, on peut concevoir un message qui alerte
l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then
MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _
"ne doit pas figurer dans la zone de texte. " + _
"Veuillez rectifier SVP."
Cancel = True
End If
On peut imaginer une version plus élaborée, qui va introduire des
caractères modificateurs si le séparateur est présent dans le texte.
posSep = InStr(txtEntree, strSep)
strTemp = Left$(txtEntree, pos - 1)
For N = posSep To posSep + Len(strSep)
strTemp = strTemp + "" + Mid$(txtEntree, N, 1)
Next
strTemp = strTemp + Right$(txtEntree, _
Len(txtEntree - posSep - Len(strSep)
J'indique ça pour le principe, comme je n'ai pas testé il peut y avoir
besoin d'ajouter ou de retirer 1 par-ci par-là.
Si on fait ça, ça suppose d'avoir en sortie une routine qui va chercher le
caractère "" dans le texte pour insérer le caractère suivant sans
l'interpréter.
Tu te réponds à toit-même Gloops, je sais comment faire, je voulais simplement savoir s'il y avait une méthode particulière, mais je te remercie beaucoup :o)
------ Site logiciels http://irolog.free.fr Mail http://irolog.free.fr/ecrire/index.htm Site perso http://irolog.free.fr/joe/index.htm Principe d'utilisation des news Groups http://support.microsoft.com/directory/worldwide/fr/newsgroup/regles.htm ------------------------------------------------------------------------------------ "Gloops" a écrit dans le message de news: %
Gloops a écrit :
Bien entendu, si l'utilisateur tape le séparateur dans la zone de texte, celui-ci passera à la trappe, on peut concevoir un message qui alerte l'utilisateur.
If InStr(txtEntree, strSep) > 0 Then MsgBox "Le texte " + vbCrLf + strSep + vbCrLf + _ "ne doit pas figurer dans la zone de texte. " + _ "Veuillez rectifier SVP." Cancel = True End If
On peut imaginer une version plus élaborée, qui va introduire des caractères modificateurs si le séparateur est présent dans le texte.
posSep = InStr(txtEntree, strSep) strTemp = Left$(txtEntree, pos - 1) For N = posSep To posSep + Len(strSep) strTemp = strTemp + "" + Mid$(txtEntree, N, 1) Next strTemp = strTemp + Right$(txtEntree, _ Len(txtEntree - posSep - Len(strSep)
J'indique ça pour le principe, comme je n'ai pas testé il peut y avoir besoin d'ajouter ou de retirer 1 par-ci par-là.
Si on fait ça, ça suppose d'avoir en sortie une routine qui va chercher le caractère "" dans le texte pour insérer le caractère suivant sans l'interpréter.
Fred
Dans : news:%23c$, Gloops disait :
Après il faut se débrouiller pour savoir quoi en faire, car pour une requête SQL le séparateur habituel est le guillemet.
Salut Gloops,
Le séparateur n'est pas le guillemet mais l'apostrophe. C'est un détail. En fait, ce que je voulais te signaler c'est que la solution existe et est très vivement encouragée par Microsoft pour éviter les attaques de type SQL Injection (mais aussi tout simplement les bugs). C'est l'utilisation d'objets parameters plutôt que de faire de la concaténation de chaînes de caractères.
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Dans : news:%23c$OF40TGHA.4132@TK2MSFTNGP11.phx.gbl,
Gloops disait :
Après il faut se débrouiller pour savoir quoi en faire, car pour une
requête SQL le séparateur habituel est le guillemet.
Salut Gloops,
Le séparateur n'est pas le guillemet mais l'apostrophe. C'est un détail.
En fait, ce que je voulais te signaler c'est que la solution existe et
est très vivement encouragée par Microsoft pour éviter les attaques de
type SQL Injection (mais aussi tout simplement les bugs). C'est
l'utilisation d'objets parameters plutôt que de faire de la
concaténation de chaînes de caractères.
Après il faut se débrouiller pour savoir quoi en faire, car pour une requête SQL le séparateur habituel est le guillemet.
Salut Gloops,
Le séparateur n'est pas le guillemet mais l'apostrophe. C'est un détail. En fait, ce que je voulais te signaler c'est que la solution existe et est très vivement encouragée par Microsoft pour éviter les attaques de type SQL Injection (mais aussi tout simplement les bugs). C'est l'utilisation d'objets parameters plutôt que de faire de la concaténation de chaînes de caractères.
-- Fred http://www.cerbermail.com/?3kA6ftaCvT
Gloops
Fred a écrit :
En fait, ce que je voulais te signaler c'est que la solution existe et est très vivement encouragée par Microsoft pour éviter les attaques de type SQL Injection (mais aussi tout simplement les bugs). C'est l'utilisation d'objets parameters plutôt que de faire de la concaténation de chaînes de caractères.
Ah, ça valait le coup de le dire, ça.
Fred a écrit :
En fait, ce que je voulais te signaler c'est que la solution existe et
est très vivement encouragée par Microsoft pour éviter les attaques de
type SQL Injection (mais aussi tout simplement les bugs). C'est
l'utilisation d'objets parameters plutôt que de faire de la
concaténation de chaînes de caractères.
En fait, ce que je voulais te signaler c'est que la solution existe et est très vivement encouragée par Microsoft pour éviter les attaques de type SQL Injection (mais aussi tout simplement les bugs). C'est l'utilisation d'objets parameters plutôt que de faire de la concaténation de chaînes de caractères.
Ah, ça valait le coup de le dire, ça.
Gloops
X a écrit :
Tu te réponds à toit-même Gloops, je sais comment faire, je voulais simplement savoir s'il y avait une méthode particulière, mais je te remercie beaucoup :o)
Bon, OK, j'avoue que je ne me rendais pas bien compte si ma méthode était particulière ou pas.
Ma foi, du moment qu'il n'y a pas de casse ...
X a écrit :
Tu te réponds à toit-même Gloops, je sais comment faire, je voulais
simplement savoir s'il y avait une méthode particulière, mais je te remercie
beaucoup :o)
Bon, OK, j'avoue que je ne me rendais pas bien compte si ma méthode
était particulière ou pas.
Tu te réponds à toit-même Gloops, je sais comment faire, je voulais simplement savoir s'il y avait une méthode particulière, mais je te remercie beaucoup :o)
Bon, OK, j'avoue que je ne me rendais pas bien compte si ma méthode était particulière ou pas.
