Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

touche ENTER dans un textbox

6 réponses
Avatar
Michel HOLDERITH
Bonjour tout le monde,

2 questions :

* J'ai un textbox dans lequel je veux avoir la possibilite de faire des
enter (pas de probleme)
EnterKeyBehavior = True
multiline = true

Par contre apres modification de ce textbox je voudrais retranscrire le
contenu du textbox dans une cellule
range("a1").value = userform1.textbox1.value
et la il me retranscrit tout bien a l'exception du enter (en caractere
ASSCI)

* Il faut egalement penser par la suite, lors de l'initialisation de mon
textbox :
userform1.textbox1.value = range("a1").value

et la il me met tout le contenu de la cellule sur une seul ligne (dans le
textbox) avec la separation des enter en codes ASSCI...

Merci de votre aide,
@+
Michel.

6 réponses

Avatar
Michel Gaboly
Salut Michel,

Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub
Avatar
Michel Gaboly
Salut Michel,

Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub
Avatar
Michel Gaboly
Salut Michel,
Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub

Dans le TextBox (Windows), le passage à la ligne résulte d la
combinaison des carctères ASCII 13 et 10, tandis que dans une cellule
(Win toujours), c'est seulement le caractère 10.
NB - Sur Mac, c'est le seul caractère 13 dans les 2 cas.

Salut Michel,

Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub



--
Cordialement,

Michel Gaboly
www.gaboly.com

Avatar
Michel Gaboly
Bonsoir,

Ce message peut intéresser ceux qui naviguent entre les environnements
Mac et Win.

Avec un peu de chance, j'ai trouvé l'origine des nombreux messages
tronqués que je subis depuis quelques semaines avec Thunderbird.

Pas sûr encore ;-((

Et c'est en répondant à Michel Holderith que j'ai eu une piste : j'ai
voulu lui indiquer que les sauts de lignes se faisaient différemment sur
Mac et sous Windows (cf. ci-desous, le message initial ayant été tronqué
;-((

Depuis 2 mois environ, j'ai changé de machine ; j'utilise un iMac G5,
sur lequel j'ai installé un émulateur PC (Virtual PC, car je travaille
en ce moment pour un client sur PC) et Office 2000 qui tourne donc en
émulation.

Je n'ai pas encore installé de version Mac d'Excel (pas encore acheté
Excel 2004, et pas trouvé utile d'installer Excel X, la version précédente).

Quand j'interviens sur le forum, je navigue donc entre un environnement
Win, uniquement pour Office, et l'environnement Mac pour tout le
reste, Internet en particulier.

J'ai l'impression que le dernier message a été tronqué après les 2
extraits de codes, à cause justement de la différence de traitement des
sauts de lignes entre les 2 environnements : par prudence, avant
d'envoyer ma réponse à Michel, j'avais fait un Copier/Coller vers le
traitement de texte basique de MacOS X, TextEdit.

Après avoir constaté que mon message avait été tronqué, j'ai refait un
Copier/Coller vers Excel (environnement Win, donc) pour essayer de voir
à quoi correspondait en ASCII le saut de ligne à l'endroit où le message
avait été tronqué.

Surprise, le Copier/Coller n'a pas fonctionné correctement : la fin du
texte n'a pas été collée dans Excel : j'ai obtenu exactement le même
message tronqué que sur le forum. Par contre, dans l'environnement Mac,
le Copier/Coller fonctionne ; le texte collé est complet.

J'ai repris mon message en supprimant les sauts de lignes après les "End
Sub", et les recréant avec la touche Return. Le nouveau message obtenu
(HS Test précédent) n'a pas été tronqué ;-))

Il reste à poursuivre les tests.

Désolé pour ceux qui espéraient un HS moins technique ;-((((



Salut Michel,
Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub

Dans le TextBox (Windows), le passage à la ligne résulte d la
combinaison des carctères ASCII 13 et 10, tandis que dans une cellule
(Win toujours), c'est seulement le caractère 10.
NB - Sur Mac, c'est le seul caractère 13 dans les 2 cas.



--
Cordialement,

Michel Gaboly
www.gaboly.com

Avatar
twinley
Bonjour Michel,

Ben ! tu vis bien dangereusement et intensemment.
Je comprend mieux les bizarreries qui t'accablent.
L'informatique va bien finir par plier...

à+twinley

Bonsoir,

Ce message peut intéresser ceux qui naviguent entre les environnements
Mac et Win.

Avec un peu de chance, j'ai trouvé l'origine des nombreux messages
tronqués que je subis depuis quelques semaines avec Thunderbird.

Pas sûr encore ;-((

Et c'est en répondant à Michel Holderith que j'ai eu une piste : j'ai
voulu lui indiquer que les sauts de lignes se faisaient différemment sur
Mac et sous Windows (cf. ci-desous, le message initial ayant été tronqué
;-((

Depuis 2 mois environ, j'ai changé de machine ; j'utilise un iMac G5,
sur lequel j'ai installé un émulateur PC (Virtual PC, car je travaille
en ce moment pour un client sur PC) et Office 2000 qui tourne donc en
émulation.

Je n'ai pas encore installé de version Mac d'Excel (pas encore acheté
Excel 2004, et pas trouvé utile d'installer Excel X, la version
précédente).

Quand j'interviens sur le forum, je navigue donc entre un environnement
Win, uniquement pour Office, et l'environnement Mac pour tout le reste,
Internet en particulier.

J'ai l'impression que le dernier message a été tronqué après les 2
extraits de codes, à cause justement de la différence de traitement des
sauts de lignes entre les 2 environnements : par prudence, avant
d'envoyer ma réponse à Michel, j'avais fait un Copier/Coller vers le
traitement de texte basique de MacOS X, TextEdit.

Après avoir constaté que mon message avait été tronqué, j'ai refait un
Copier/Coller vers Excel (environnement Win, donc) pour essayer de voir
à quoi correspondait en ASCII le saut de ligne à l'endroit où le message
avait été tronqué.

Surprise, le Copier/Coller n'a pas fonctionné correctement : la fin du
texte n'a pas été collée dans Excel : j'ai obtenu exactement le même
message tronqué que sur le forum. Par contre, dans l'environnement Mac,
le Copier/Coller fonctionne ; le texte collé est complet.

J'ai repris mon message en supprimant les sauts de lignes après les "End
Sub", et les recréant avec la touche Return. Le nouveau message obtenu
(HS Test précédent) n'a pas été tronqué ;-))

Il reste à poursuivre les tests.

Désolé pour ceux qui espéraient un HS moins technique ;-((((



Salut Michel,
Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub

Dans le TextBox (Windows), le passage à la ligne résulte d la
combinaison des carctères ASCII 13 et 10, tandis que dans une cellule
(Win toujours), c'est seulement le caractère 10.
NB - Sur Mac, c'est le seul caractère 13 dans les 2 cas.






Avatar
Michel Gaboly
Salut twinley,

Merci de tes encouragements ;-))


Bonjour Michel,

Ben ! tu vis bien dangereusement et intensemment.
Je comprend mieux les bizarreries qui t'accablent.
L'informatique va bien finir par plier...

à+twinley


Bonsoir,

Ce message peut intéresser ceux qui naviguent entre les environnements
Mac et Win.

Avec un peu de chance, j'ai trouvé l'origine des nombreux messages
tronqués que je subis depuis quelques semaines avec Thunderbird.

Pas sûr encore ;-((

Et c'est en répondant à Michel Holderith que j'ai eu une piste : j'ai
voulu lui indiquer que les sauts de lignes se faisaient différemment
sur Mac et sous Windows (cf. ci-desous, le message initial ayant été
tronqué ;-((

Depuis 2 mois environ, j'ai changé de machine ; j'utilise un iMac G5,
sur lequel j'ai installé un émulateur PC (Virtual PC, car je travaille
en ce moment pour un client sur PC) et Office 2000 qui tourne donc en
émulation.

Je n'ai pas encore installé de version Mac d'Excel (pas encore acheté
Excel 2004, et pas trouvé utile d'installer Excel X, la version
précédente).

Quand j'interviens sur le forum, je navigue donc entre un
environnement Win, uniquement pour Office, et l'environnement Mac
pour tout le reste, Internet en particulier.

J'ai l'impression que le dernier message a été tronqué après les 2
extraits de codes, à cause justement de la différence de traitement
des sauts de lignes entre les 2 environnements : par prudence, avant
d'envoyer ma réponse à Michel, j'avais fait un Copier/Coller vers le
traitement de texte basique de MacOS X, TextEdit.

Après avoir constaté que mon message avait été tronqué, j'ai refait un
Copier/Coller vers Excel (environnement Win, donc) pour essayer de
voir à quoi correspondait en ASCII le saut de ligne à l'endroit où le
message avait été tronqué.

Surprise, le Copier/Coller n'a pas fonctionné correctement : la fin du
texte n'a pas été collée dans Excel : j'ai obtenu exactement le même
message tronqué que sur le forum. Par contre, dans l'environnement
Mac, le Copier/Coller fonctionne ; le texte collé est complet.

J'ai repris mon message en supprimant les sauts de lignes après les
"End Sub", et les recréant avec la touche Return. Le nouveau message
obtenu (HS Test précédent) n'a pas été tronqué ;-))

Il reste à poursuivre les tests.

Désolé pour ceux qui espéraient un HS moins technique ;-((((



Salut Michel,
Private Sub UserForm_Initialize()
TextBox1 = Replace(Range("A1"), Chr(10), vbNewLine)
End Sub

Private Sub CommandButton1_Click()
Range("A1") = Replace(TextBox1, vbNewLine, Chr(10))
End Sub

Dans le TextBox (Windows), le passage à la ligne résulte d la
combinaison des carctères ASCII 13 et 10, tandis que dans une cellule
(Win toujours), c'est seulement le caractère 10.
NB - Sur Mac, c'est le seul caractère 13 dans les 2 cas.







--
Cordialement,

Michel Gaboly
www.gaboly.com