bonjour à tous
depuis plusieurs jours je vous sollicite pour un formulaire or,je viens de
me rendre compte que je me suis (comme d'habitude)mal exprimé
en effet ce que je cherche a faire c'est une grille de saisie qui remplirait
directement un tableau Excel a chaque enregistrement d'un adhérent.
Encore merci à tous ceux qui m'ont aidés
fréro
... C'est aussi dans la perspective que Frero doive lui même adapter à son cas(quitte à reposer d'autres questions) que je ne l'ai pas traité directement mais en partant d'un autre exemple.
;-) -- lSteph
On 6 mar, 10:32, wrote:
L'objectif est surtout pédagogique ... j'aurais pu aussi
...
C'est aussi dans la perspective que Frero doive lui même adapter à son
cas(quitte à reposer d'autres questions)
que je ne l'ai pas traité directement mais en partant d'un autre
exemple.
;-)
--
lSteph
On 6 mar, 10:32, gmlst...@gmail.com wrote:
L'objectif est surtout pédagogique
... j'aurais pu aussi
... C'est aussi dans la perspective que Frero doive lui même adapter à son cas(quitte à reposer d'autres questions) que je ne l'ai pas traité directement mais en partant d'un autre exemple.
;-) -- lSteph
On 6 mar, 10:32, wrote:
L'objectif est surtout pédagogique ... j'aurais pu aussi
fréro
bonjour pas de problème pour toutes les suggestions comme l'indique LSteph la méthode par étape permet de s'initier au VBA et surtout de ne pas s'affoler bonne journée à toutes et a tous fréro encore merci pour votre patience a écrit dans le message de news: ... C'est aussi dans la perspective que Frero doive lui même adapter à son cas(quitte à reposer d'autres questions) que je ne l'ai pas traité directement mais en partant d'un autre exemple.
;-) -- lSteph
On 6 mar, 10:32, wrote:
L'objectif est surtout pédagogique ... j'aurais pu aussi
bonjour
pas de problème pour toutes les suggestions
comme l'indique LSteph la méthode par étape permet de s'initier au VBA et
surtout de ne pas s'affoler
bonne journée à toutes et a tous
fréro
encore merci pour votre patience
<gmlsteph@gmail.com> a écrit dans le message de
news:44e2c43d-dc68-40a1-9de1-b6d01429981e@c11g2000yqj.googlegroups.com...
...
C'est aussi dans la perspective que Frero doive lui même adapter à son
cas(quitte à reposer d'autres questions)
que je ne l'ai pas traité directement mais en partant d'un autre
exemple.
;-)
--
lSteph
On 6 mar, 10:32, gmlst...@gmail.com wrote:
L'objectif est surtout pédagogique
... j'aurais pu aussi
bonjour pas de problème pour toutes les suggestions comme l'indique LSteph la méthode par étape permet de s'initier au VBA et surtout de ne pas s'affoler bonne journée à toutes et a tous fréro encore merci pour votre patience a écrit dans le message de news: ... C'est aussi dans la perspective que Frero doive lui même adapter à son cas(quitte à reposer d'autres questions) que je ne l'ai pas traité directement mais en partant d'un autre exemple.
;-) -- lSteph
On 6 mar, 10:32, wrote:
L'objectif est surtout pédagogique ... j'aurais pu aussi
isabelle
salut lSteph ,
a écrit :
.. . je trouve cela bien quand on peut se mettre à plusieurs pour donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
salut lSteph ,
gmlsteph@gmail.com a écrit :
.. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en
passant j'aime mieux cette methode
Me.Controls("Label" & i) = ...
c'est mieux ciblé,
.. . je trouve cela bien quand on peut se mettre à plusieurs pour donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
gmlsteph
... oui, je la préfère aussi, et cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof ou autre est nécessaire C'est ainsi que pour ma part , autant je renommerais un module ou un Userform et obligatoirement quand il s'agit d'un Module de classe autant pour les contrôles je laisse toujours les noms (même si je les renomme) selon la forme générique (quitte à préciser un caption et une indication en commentaire dans le code) et leur numérotation dans l'ordre où on les trouve de haut en bas et/ou de gauche à droite, mais c'est une affaire de goût.
On 6 mar, 11:28, isabelle wrote:
salut lSteph ,
a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour > donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
... oui, je la préfère aussi, et cela ouvre un autre débat
pour que cela aille il ne faut pas que l'on ait renommé les contrôles
sinon le typeof ou autre est nécessaire
C'est ainsi que pour ma part , autant je renommerais un module ou un
Userform
et obligatoirement quand il s'agit d'un Module de classe autant
pour les contrôles je laisse toujours les noms (même si je les
renomme)
selon la forme générique (quitte à préciser un caption et une
indication en commentaire dans le code)
et leur numérotation dans l'ordre où on les trouve
de haut en bas et/ou de gauche à droite, mais c'est une affaire de
goût.
On 6 mar, 11:28, isabelle <i@v> wrote:
salut lSteph ,
gmlst...@gmail.com a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
> donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en
passant j'aime mieux cette methode
Me.Controls("Label" & i) = ...
c'est mieux ciblé,
... oui, je la préfère aussi, et cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof ou autre est nécessaire C'est ainsi que pour ma part , autant je renommerais un module ou un Userform et obligatoirement quand il s'agit d'un Module de classe autant pour les contrôles je laisse toujours les noms (même si je les renomme) selon la forme générique (quitte à préciser un caption et une indication en commentaire dans le code) et leur numérotation dans l'ordre où on les trouve de haut en bas et/ou de gauche à droite, mais c'est une affaire de goût.
On 6 mar, 11:28, isabelle wrote:
salut lSteph ,
a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour > donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
isabelle
mais y'a des occasions ou ce n'est pas possible par exemple si un jour on a à modifier le userform soit ajouter un contrôl à un groupe il vaut peut être mieux mettre ces contrôls dans un frame et utiliser la méthode "For Each" mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
isabelle
a écrit :
... oui, je la préfère aussi, et cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof ou autre est nécessaire C'est ainsi que pour ma part , autant je renommerais un module ou un Userform et obligatoirement quand il s'agit d'un Module de classe autant pour les contrôles je laisse toujours les noms (même si je les renomme) selon la forme générique (quitte à préciser un caption et une indication en commentaire dans le code) et leur numérotation dans l'ordre où on les trouve de haut en bas et/ou de gauche à droite, mais c'est une affaire de goût.
On 6 mar, 11:28, isabelle wrote:
salut lSteph ,
a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
mais y'a des occasions ou ce n'est pas possible par exemple si un jour
on a à modifier le userform
soit ajouter un contrôl à un groupe il vaut peut être mieux mettre ces
contrôls dans un frame et utiliser la méthode "For Each"
mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
isabelle
gmlsteph@gmail.com a écrit :
... oui, je la préfère aussi, et cela ouvre un autre débat
pour que cela aille il ne faut pas que l'on ait renommé les contrôles
sinon le typeof ou autre est nécessaire
C'est ainsi que pour ma part , autant je renommerais un module ou un
Userform
et obligatoirement quand il s'agit d'un Module de classe autant
pour les contrôles je laisse toujours les noms (même si je les
renomme)
selon la forme générique (quitte à préciser un caption et une
indication en commentaire dans le code)
et leur numérotation dans l'ordre où on les trouve
de haut en bas et/ou de gauche à droite, mais c'est une affaire de
goût.
On 6 mar, 11:28, isabelle <i@v> wrote:
salut lSteph ,
gmlst...@gmail.com a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en
passant j'aime mieux cette methode
Me.Controls("Label" & i) = ...
c'est mieux ciblé,
mais y'a des occasions ou ce n'est pas possible par exemple si un jour on a à modifier le userform soit ajouter un contrôl à un groupe il vaut peut être mieux mettre ces contrôls dans un frame et utiliser la méthode "For Each" mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
isabelle
a écrit :
... oui, je la préfère aussi, et cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof ou autre est nécessaire C'est ainsi que pour ma part , autant je renommerais un module ou un Userform et obligatoirement quand il s'agit d'un Module de classe autant pour les contrôles je laisse toujours les noms (même si je les renomme) selon la forme générique (quitte à préciser un caption et une indication en commentaire dans le code) et leur numérotation dans l'ordre où on les trouve de haut en bas et/ou de gauche à droite, mais c'est une affaire de goût.
On 6 mar, 11:28, isabelle wrote:
salut lSteph ,
a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
milloche
Un merci aussi de ma part. Je guettais dans l'ombre sans rien dire, mais suivais les explications. C'est aussi mon premier UserForm. Et j'ai compris au moins la base. Ne le dites pas à la police ! mais j'ai aussi téléchargé le ci-joint. <(:o))
"isabelle" a écrit dans le message de news:
mais y'a des occasions ou ce n'est pas possible par exemple si un jour on a à modifier le userform soit ajouter un contrôl à un groupe il vaut peut être mieux mettre ces contrôls dans un frame et utiliser la méthode "For Each" mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
isabelle
a écrit :
... oui, je la préfère aussi, et cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof ou autre est nécessaire C'est ainsi que pour ma part , autant je renommerais un module ou un Userform et obligatoirement quand il s'agit d'un Module de classe autant pour les contrôles je laisse toujours les noms (même si je les renomme) selon la forme générique (quitte à préciser un caption et une indication en commentaire dans le code) et leur numérotation dans l'ordre où on les trouve de haut en bas et/ou de gauche à droite, mais c'est une affaire de goût.
On 6 mar, 11:28, isabelle wrote:
salut lSteph ,
a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
Un merci aussi de ma part.
Je guettais dans l'ombre sans rien dire, mais suivais les explications.
C'est aussi mon premier UserForm. Et j'ai compris au moins la base.
Ne le dites pas à la police ! mais j'ai aussi téléchargé le ci-joint.
<(:o))
"isabelle" <i@v> a écrit dans le message de news: O0qwIFlnJHA.1292@TK2MSFTNGP02.phx.gbl...
mais y'a des occasions ou ce n'est pas possible par exemple si un jour on a à modifier le userform
soit ajouter un contrôl à un groupe il vaut peut être mieux mettre ces contrôls dans un frame et
utiliser la méthode "For Each"
mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
isabelle
gmlsteph@gmail.com a écrit :
... oui, je la préfère aussi, et cela ouvre un autre débat
pour que cela aille il ne faut pas que l'on ait renommé les contrôles
sinon le typeof ou autre est nécessaire
C'est ainsi que pour ma part , autant je renommerais un module ou un
Userform
et obligatoirement quand il s'agit d'un Module de classe autant
pour les contrôles je laisse toujours les noms (même si je les
renomme)
selon la forme générique (quitte à préciser un caption et une
indication en commentaire dans le code)
et leur numérotation dans l'ordre où on les trouve
de haut en bas et/ou de gauche à droite, mais c'est une affaire de
goût.
On 6 mar, 11:28, isabelle <i@v> wrote:
salut lSteph ,
gmlst...@gmail.com a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en
passant j'aime mieux cette methode
Me.Controls("Label" & i) = ...
c'est mieux ciblé,
Un merci aussi de ma part. Je guettais dans l'ombre sans rien dire, mais suivais les explications. C'est aussi mon premier UserForm. Et j'ai compris au moins la base. Ne le dites pas à la police ! mais j'ai aussi téléchargé le ci-joint. <(:o))
"isabelle" a écrit dans le message de news:
mais y'a des occasions ou ce n'est pas possible par exemple si un jour on a à modifier le userform soit ajouter un contrôl à un groupe il vaut peut être mieux mettre ces contrôls dans un frame et utiliser la méthode "For Each" mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
isabelle
a écrit :
... oui, je la préfère aussi, et cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof ou autre est nécessaire C'est ainsi que pour ma part , autant je renommerais un module ou un Userform et obligatoirement quand il s'agit d'un Module de classe autant pour les contrôles je laisse toujours les noms (même si je les renomme) selon la forme générique (quitte à préciser un caption et une indication en commentaire dans le code) et leur numérotation dans l'ordre où on les trouve de haut en bas et/ou de gauche à droite, mais c'est une affaire de goût.
On 6 mar, 11:28, isabelle wrote:
salut lSteph ,
a écrit :> .. . je trouve cela bien quand on peut se mettre à plusieurs pour
donner différentes méthodes.
moi aussi j'apprécie ce partarge ça permet d'avancer plus vite, et en passant j'aime mieux cette methode Me.Controls("Label" & i) = ... c'est mieux ciblé,
isabelle
Modeste
Bonsour® isabelle
[Lsteph]
cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof
*ou autre* est nécessaire ;o)))
[Isabelle]
mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
Ordre, rigueur, convention, formalisme Cela permet en effet de faciliter la maintenance... Ce sont des impératifs dans tout les grands centres de développement
Encore faut-il que ces conventions soient diffusées, partagées, acceptées et utilisées ... ??? sans pour cela parler d'intégrisme, je me rappelle mes débuts (*) ou le responsable d'exploitation accordait plus d'importance au formalisme plutot qu'a concision et performance En informatique comme dans d'autres domaines les groupes font parties de ce que l'on nomme des "chapelles"... ce qui fait qu'il y ait aussi des "guerres de religions" ;o)))
Concernant le document ci-dessus référencé, ces conventions n'ont jamais été acceptées dans mon entreprise au détriment des conventions "maisons" ;o)))
Concernant une utilisation personnelle, c'est une contrainte mais c'est aussi une façon de se rapprocher de l'esprit des "gurus" ;o))) Cependant cela necessite de la part du béotien de bien connaitre l'anglais technique et la façon de contracter les mots en anglais qui n'est pas toujours évidente à un esprit latin
cela ouvre un autre débat
pour que cela aille il ne faut pas que l'on ait renommé les contrôles
sinon le typeof
*ou autre* est nécessaire ;o)))
[Isabelle]
mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
Ordre, rigueur, convention, formalisme
Cela permet en effet de faciliter la maintenance...
Ce sont des impératifs dans tout les grands centres de développement
Encore faut-il que ces conventions soient diffusées, partagées, acceptées et utilisées ... ???
sans pour cela parler d'intégrisme, je me rappelle mes débuts (*) ou le responsable d'exploitation accordait plus d'importance au formalisme plutot qu'a concision et performance
En informatique comme dans d'autres domaines les groupes font parties de ce que l'on nomme des "chapelles"...
ce qui fait qu'il y ait aussi des "guerres de religions" ;o)))
Concernant le document ci-dessus référencé, ces conventions n'ont jamais été acceptées dans mon entreprise au détriment des conventions "maisons" ;o)))
Concernant une utilisation personnelle, c'est une contrainte mais c'est aussi une façon de se rapprocher de l'esprit des "gurus" ;o)))
Cependant cela necessite de la part du béotien de bien connaitre l'anglais technique
et la façon de contracter les mots en anglais qui n'est pas toujours évidente à un esprit latin
cela ouvre un autre débat pour que cela aille il ne faut pas que l'on ait renommé les contrôles sinon le typeof
*ou autre* est nécessaire ;o)))
[Isabelle]
mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre,
Ordre, rigueur, convention, formalisme Cela permet en effet de faciliter la maintenance... Ce sont des impératifs dans tout les grands centres de développement
Encore faut-il que ces conventions soient diffusées, partagées, acceptées et utilisées ... ??? sans pour cela parler d'intégrisme, je me rappelle mes débuts (*) ou le responsable d'exploitation accordait plus d'importance au formalisme plutot qu'a concision et performance En informatique comme dans d'autres domaines les groupes font parties de ce que l'on nomme des "chapelles"... ce qui fait qu'il y ait aussi des "guerres de religions" ;o)))
Concernant le document ci-dessus référencé, ces conventions n'ont jamais été acceptées dans mon entreprise au détriment des conventions "maisons" ;o)))
Concernant une utilisation personnelle, c'est une contrainte mais c'est aussi une façon de se rapprocher de l'esprit des "gurus" ;o))) Cependant cela necessite de la part du béotien de bien connaitre l'anglais technique et la façon de contracter les mots en anglais qui n'est pas toujours évidente à un esprit latin
Merci Gd pour ce document utile et qui pourrait d'ailleurs être mis plus en évidence qu''ainsi erdu dans un fil. J'utilise souvent ce genre de conventions glanées ca et là mais surtout lorsqu'il s'agit des noms donnés à des variables. Pour les controles des userform j'aurais tendance à garder la forme générique au .Name de ces obj et j'indiquais plus haut pourquoi mais pour le cas précité effectivement voila qui regroupe un ensemble auquel se référer. Tout en gardant sa liberté et dans le respect de toute chapelle, comme tu l'évoquais, étant tous amenés à écrire lire, relire réécri re quelques conventions ne sont pas négligeable pour se faciliter la tache.
Cordialement.
-- lSteph
On 8 mar, 20:19, "Modeste" wrote:
Bonsour® isabelle
[Lsteph]
> cela ouvre un autre débat > pour que cela aille il ne faut pas que l'on ait renommé les contrôl es > sinon le typeof
*ou autre* est nécessaire ;o)))
[Isabelle]
> mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre ,
Ordre, rigueur, convention, formalisme Cela permet en effet de faciliter la maintenance... Ce sont des impératifs dans tout les grands centres de développement
Encore faut-il que ces conventions soient diffusées, partagées, accep tées et utilisées ... ??? sans pour cela parler d'intégrisme, je me rappelle mes débuts (*) ou le responsable d'exploitation accordait plus d'importance au formalisme plu tot qu'a concision et performance En informatique comme dans d'autres domaines les groupes font parties de ce que l'on nomme des "chapelles"... ce qui fait qu'il y ait aussi des "guerres de religions" ;o)))
Concernant le document ci-dessus référencé, ces conventions n'ont j amais été acceptées dans mon entreprise au détriment des convention s "maisons" ;o)))
Concernant une utilisation personnelle, c'est une contrainte mais c'est a ussi une façon de se rapprocher de l'esprit des "gurus" ;o))) Cependant cela necessite de la part du béotien de bien connaitre l'angl ais technique et la façon de contracter les mots en anglais qui n'est pas toujours évidente à un esprit latin
Merci Gd pour ce document utile et qui pourrait d'ailleurs être mis
plus en évidence qu''ainsi erdu dans un fil.
J'utilise souvent ce genre de conventions glanées ca et là mais
surtout lorsqu'il s'agit des noms donnés à des variables. Pour les
controles des userform j'aurais tendance à garder la forme générique
au .Name de ces obj
et j'indiquais plus haut pourquoi
mais pour le cas précité effectivement voila qui regroupe un ensemble
auquel se référer.
Tout en gardant sa liberté et dans le respect de toute chapelle, comme
tu l'évoquais, étant tous amenés à écrire lire, relire réécri re
quelques conventions ne sont pas négligeable pour se faciliter la
tache.
Cordialement.
--
lSteph
On 8 mar, 20:19, "Modeste" <G...@libre.fr> wrote:
Bonsour® isabelle
[Lsteph]
> cela ouvre un autre débat
> pour que cela aille il ne faut pas que l'on ait renommé les contrôl es
> sinon le typeof
*ou autre* est nécessaire ;o)))
[Isabelle]
> mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre ,
Ordre, rigueur, convention, formalisme
Cela permet en effet de faciliter la maintenance...
Ce sont des impératifs dans tout les grands centres de développement
Encore faut-il que ces conventions soient diffusées, partagées, accep tées et utilisées ... ???
sans pour cela parler d'intégrisme, je me rappelle mes débuts (*) ou le responsable d'exploitation accordait plus d'importance au formalisme plu tot qu'a concision et performance
En informatique comme dans d'autres domaines les groupes font parties de ce que l'on nomme des "chapelles"...
ce qui fait qu'il y ait aussi des "guerres de religions" ;o)))
Concernant le document ci-dessus référencé, ces conventions n'ont j amais été acceptées dans mon entreprise au détriment des convention s "maisons" ;o)))
Concernant une utilisation personnelle, c'est une contrainte mais c'est a ussi une façon de se rapprocher de l'esprit des "gurus" ;o)))
Cependant cela necessite de la part du béotien de bien connaitre l'angl ais technique
et la façon de contracter les mots en anglais qui n'est pas toujours évidente à un esprit latin
Merci Gd pour ce document utile et qui pourrait d'ailleurs être mis plus en évidence qu''ainsi erdu dans un fil. J'utilise souvent ce genre de conventions glanées ca et là mais surtout lorsqu'il s'agit des noms donnés à des variables. Pour les controles des userform j'aurais tendance à garder la forme générique au .Name de ces obj et j'indiquais plus haut pourquoi mais pour le cas précité effectivement voila qui regroupe un ensemble auquel se référer. Tout en gardant sa liberté et dans le respect de toute chapelle, comme tu l'évoquais, étant tous amenés à écrire lire, relire réécri re quelques conventions ne sont pas négligeable pour se faciliter la tache.
Cordialement.
-- lSteph
On 8 mar, 20:19, "Modeste" wrote:
Bonsour® isabelle
[Lsteph]
> cela ouvre un autre débat > pour que cela aille il ne faut pas que l'on ait renommé les contrôl es > sinon le typeof
*ou autre* est nécessaire ;o)))
[Isabelle]
> mais l'idée général elle comme tu dis vaut mieux avoir de l'ordre ,
Ordre, rigueur, convention, formalisme Cela permet en effet de faciliter la maintenance... Ce sont des impératifs dans tout les grands centres de développement
Encore faut-il que ces conventions soient diffusées, partagées, accep tées et utilisées ... ??? sans pour cela parler d'intégrisme, je me rappelle mes débuts (*) ou le responsable d'exploitation accordait plus d'importance au formalisme plu tot qu'a concision et performance En informatique comme dans d'autres domaines les groupes font parties de ce que l'on nomme des "chapelles"... ce qui fait qu'il y ait aussi des "guerres de religions" ;o)))
Concernant le document ci-dessus référencé, ces conventions n'ont j amais été acceptées dans mon entreprise au détriment des convention s "maisons" ;o)))
Concernant une utilisation personnelle, c'est une contrainte mais c'est a ussi une façon de se rapprocher de l'esprit des "gurus" ;o))) Cependant cela necessite de la part du béotien de bien connaitre l'angl ais technique et la façon de contracter les mots en anglais qui n'est pas toujours évidente à un esprit latin
