Je viens soulever un problème qui concerne les listes.
Lorsqu'on convertit une plage en liste, les en-têtes format numérique
se transforment en texte, et c'est très ennuyeux.
Exemple dans un cas que je viens de constater :
Une liste, dont un certain nombre d'en-têtes sont des dates.
Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui
font un calcul en fonction de certaines dates, des EQUIV pour trouver
le numéro de la colonne concernée...
Donc, évidemment, une fois la plage convertie en liste, les formules ne
fonctionnent plus.
Dommage car la conversion en liste permet un certain nombre de choses
dont je vais devoir me passer... :(
Je trouve que ça ressemble à un bug.
J'ai pas testé encore avec 2007 ni 2010, mais seulement avec 2003.
Je dois être miraude aujourd'hui mais je ne vois pas le point que tu veux montrer. Tu expliques ?
Par compris non plus ! :D
Dans le cas d'un filtre élaboré, filtre automatique ou d'un "Worksheet Table", la première ligne est considéré comme étant des étiquettes de colonnes. À ce titre, cette ligne d'étiquette n'est pas en soi faisant partie des données du tableau.
Dans le cas précisément d'un "Worksheet table", si l'usager veut avoir des dates comme étiquette du tableau, pourquoi ne pas dédoubler cette première ligne ... la première pour l'étiquette de colonne, et la deuxième comme data faisant partie du tableau.
Je ne comprends pas bien. Mes dates ne sont pas des données... Mes dates sont de vraies étiquettes de colonne, elles n'ont rien à faire dans les données qui sont des montants.
Personnellement, j'abandonne l'idée des listes qui permettaient surtout, dans ce cas, d'avoir des noms dynamiques... Jusqu'à présent j'avais utiliser les formules DECALER, je vais donc y revenir.
Merci pour vos implications.
Circé http://faqword.com
Dans le cas où cette distinction n'est pas faite entre la ligne d'étiquette et la première ligne des données, Si tu utilises dans les formules sur le "worksheet table" , les étiquettes du tableau ( exemple de formule dans le fichier de John Walkenback), comme la première ligne n'est pas considérée comme "des données", elle ne devrait pas être considéré dans le résultat obtenu.
L'usage de dates comme étiquette de colonne, est-ce que cela augmente la lisibilité des formules ...? Cela doit être une question de goût !
michdenis vient de nous annoncer :
Je dois être miraude aujourd'hui mais je ne vois pas le point que tu
veux montrer. Tu expliques ?
Par compris non plus ! :D
Dans le cas d'un filtre élaboré, filtre automatique ou d'un "Worksheet
Table", la première ligne est considéré comme étant des étiquettes de
colonnes. À ce titre, cette ligne d'étiquette n'est pas en soi faisant partie
des données du tableau.
Dans le cas précisément d'un "Worksheet table", si l'usager veut avoir des
dates comme étiquette du tableau, pourquoi ne pas dédoubler cette
première ligne ... la première pour l'étiquette de colonne, et la deuxième
comme data faisant partie du tableau.
Je ne comprends pas bien. Mes dates ne sont pas des données...
Mes dates sont de vraies étiquettes de colonne, elles n'ont rien à
faire dans les données qui sont des montants.
Personnellement, j'abandonne l'idée des listes qui permettaient
surtout, dans ce cas, d'avoir des noms dynamiques... Jusqu'à présent
j'avais utiliser les formules DECALER, je vais donc y revenir.
Merci pour vos implications.
Circé
http://faqword.com
Dans le cas où cette distinction n'est pas faite entre la ligne d'étiquette
et la première ligne des données, Si tu utilises dans les formules sur le
"worksheet table" , les étiquettes du tableau ( exemple de formule dans
le fichier de John Walkenback), comme la première ligne n'est pas considérée
comme "des données", elle ne devrait pas être considéré dans le résultat
obtenu.
L'usage de dates comme étiquette de colonne, est-ce que cela augmente
la lisibilité des formules ...? Cela doit être une question de goût !
Je dois être miraude aujourd'hui mais je ne vois pas le point que tu veux montrer. Tu expliques ?
Par compris non plus ! :D
Dans le cas d'un filtre élaboré, filtre automatique ou d'un "Worksheet Table", la première ligne est considéré comme étant des étiquettes de colonnes. À ce titre, cette ligne d'étiquette n'est pas en soi faisant partie des données du tableau.
Dans le cas précisément d'un "Worksheet table", si l'usager veut avoir des dates comme étiquette du tableau, pourquoi ne pas dédoubler cette première ligne ... la première pour l'étiquette de colonne, et la deuxième comme data faisant partie du tableau.
Je ne comprends pas bien. Mes dates ne sont pas des données... Mes dates sont de vraies étiquettes de colonne, elles n'ont rien à faire dans les données qui sont des montants.
Personnellement, j'abandonne l'idée des listes qui permettaient surtout, dans ce cas, d'avoir des noms dynamiques... Jusqu'à présent j'avais utiliser les formules DECALER, je vais donc y revenir.
Merci pour vos implications.
Circé http://faqword.com
Dans le cas où cette distinction n'est pas faite entre la ligne d'étiquette et la première ligne des données, Si tu utilises dans les formules sur le "worksheet table" , les étiquettes du tableau ( exemple de formule dans le fichier de John Walkenback), comme la première ligne n'est pas considérée comme "des données", elle ne devrait pas être considéré dans le résultat obtenu.
L'usage de dates comme étiquette de colonne, est-ce que cela augmente la lisibilité des formules ...? Cela doit être une question de goût !
michdenis
Ta question originale du fil se lisait comme suit :
| Lorsqu'on convertit une plage en liste, les en-têtes format numérique | se transforment en texte, et c'est très ennuyeux. | Exemple dans un cas que je viens de constater :
|Exemple dans un cas que je viens de constater : | Une liste, dont un certain nombre d'en-têtes sont des dates. | Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui | font un calcul en fonction de certaines dates, des EQUIV pour trouver | le numéro de la colonne concernée... | Donc, évidemment, une fois la plage convertie en liste, les formules ne | fonctionnent plus.
Si tes formules ne contiennent pas l'étiquette de colonne, pourquoi as-tu un problème avec une formule comme "SommeProd"
Peut-être que ma compréhension de ton problème ne correspond pas à ta réalité ! A l'intérieur d'une formule, la suggestion de Misange ( *1 ) sur une colonne de dates s'avèrent utile... mais mon propos se voulait une distinction entre les données et la ligne d'étiquette des colonnes.
Ta question originale du fil se lisait comme suit :
| Lorsqu'on convertit une plage en liste, les en-têtes format numérique
| se transforment en texte, et c'est très ennuyeux.
| Exemple dans un cas que je viens de constater :
|Exemple dans un cas que je viens de constater :
| Une liste, dont un certain nombre d'en-têtes sont des dates.
| Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui
| font un calcul en fonction de certaines dates, des EQUIV pour trouver
| le numéro de la colonne concernée...
| Donc, évidemment, une fois la plage convertie en liste, les formules ne
| fonctionnent plus.
Si tes formules ne contiennent pas l'étiquette de colonne, pourquoi
as-tu un problème avec une formule comme "SommeProd"
Peut-être que ma compréhension de ton problème ne correspond
pas à ta réalité ! A l'intérieur d'une formule, la suggestion de Misange
( *1 ) sur une colonne de dates s'avèrent utile... mais mon propos se
voulait une distinction entre les données et la ligne d'étiquette des colonnes.
Ta question originale du fil se lisait comme suit :
| Lorsqu'on convertit une plage en liste, les en-têtes format numérique | se transforment en texte, et c'est très ennuyeux. | Exemple dans un cas que je viens de constater :
|Exemple dans un cas que je viens de constater : | Une liste, dont un certain nombre d'en-têtes sont des dates. | Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui | font un calcul en fonction de certaines dates, des EQUIV pour trouver | le numéro de la colonne concernée... | Donc, évidemment, une fois la plage convertie en liste, les formules ne | fonctionnent plus.
Si tes formules ne contiennent pas l'étiquette de colonne, pourquoi as-tu un problème avec une formule comme "SommeProd"
Peut-être que ma compréhension de ton problème ne correspond pas à ta réalité ! A l'intérieur d'une formule, la suggestion de Misange ( *1 ) sur une colonne de dates s'avèrent utile... mais mon propos se voulait une distinction entre les données et la ligne d'étiquette des colonnes.
Misange
Pour plus de clarté : disons que tu suis tes comptes bancaires pour différents postes mois par mois. En en tête de colonne, tu mets les mois. Tu peux avoir besoin de formules pour calculer les frais liés à la voiture en mars, en mai... Tes mois ne sont pas des données mais ils sont indispensables pour calculer tes dépenses. Doublonner la première ligne, c'est là pour le coup que ça crée une confusion je trouve ! Pour ma part j'ai résolu ce problème en multipliant par 1 dans les formules et ça roule impec.
Misange
michdenis a écrit :
Ta question originale du fil se lisait comme suit :
| Lorsqu'on convertit une plage en liste, les en-têtes format numérique | se transforment en texte, et c'est très ennuyeux. | Exemple dans un cas que je viens de constater :
|Exemple dans un cas que je viens de constater : | Une liste, dont un certain nombre d'en-têtes sont des dates. | Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui | font un calcul en fonction de certaines dates, des EQUIV pour trouver | le numéro de la colonne concernée... | Donc, évidemment, une fois la plage convertie en liste, les formules ne | fonctionnent plus.
Si tes formules ne contiennent pas l'étiquette de colonne, pourquoi as-tu un problème avec une formule comme "SommeProd"
Peut-être que ma compréhension de ton problème ne correspond pas à ta réalité ! A l'intérieur d'une formule, la suggestion de Misange ( *1 ) sur une colonne de dates s'avèrent utile... mais mon propos se voulait une distinction entre les données et la ligne d'étiquette des colonnes.
Pour plus de clarté :
disons que tu suis tes comptes bancaires pour différents postes mois par
mois. En en tête de colonne, tu mets les mois.
Tu peux avoir besoin de formules pour calculer les frais liés à la
voiture en mars, en mai... Tes mois ne sont pas des données mais ils
sont indispensables pour calculer tes dépenses.
Doublonner la première ligne, c'est là pour le coup que ça crée une
confusion je trouve !
Pour ma part j'ai résolu ce problème en multipliant par 1 dans les
formules et ça roule impec.
Misange
michdenis a écrit :
Ta question originale du fil se lisait comme suit :
| Lorsqu'on convertit une plage en liste, les en-têtes format numérique
| se transforment en texte, et c'est très ennuyeux.
| Exemple dans un cas que je viens de constater :
|Exemple dans un cas que je viens de constater :
| Une liste, dont un certain nombre d'en-têtes sont des dates.
| Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui
| font un calcul en fonction de certaines dates, des EQUIV pour trouver
| le numéro de la colonne concernée...
| Donc, évidemment, une fois la plage convertie en liste, les formules ne
| fonctionnent plus.
Si tes formules ne contiennent pas l'étiquette de colonne, pourquoi
as-tu un problème avec une formule comme "SommeProd"
Peut-être que ma compréhension de ton problème ne correspond
pas à ta réalité ! A l'intérieur d'une formule, la suggestion de Misange
( *1 ) sur une colonne de dates s'avèrent utile... mais mon propos se
voulait une distinction entre les données et la ligne d'étiquette des colonnes.
Pour plus de clarté : disons que tu suis tes comptes bancaires pour différents postes mois par mois. En en tête de colonne, tu mets les mois. Tu peux avoir besoin de formules pour calculer les frais liés à la voiture en mars, en mai... Tes mois ne sont pas des données mais ils sont indispensables pour calculer tes dépenses. Doublonner la première ligne, c'est là pour le coup que ça crée une confusion je trouve ! Pour ma part j'ai résolu ce problème en multipliant par 1 dans les formules et ça roule impec.
Misange
michdenis a écrit :
Ta question originale du fil se lisait comme suit :
| Lorsqu'on convertit une plage en liste, les en-têtes format numérique | se transforment en texte, et c'est très ennuyeux. | Exemple dans un cas que je viens de constater :
|Exemple dans un cas que je viens de constater : | Une liste, dont un certain nombre d'en-têtes sont des dates. | Des formules sont basées sur ces dates. Par exemple des SOMMEPROD qui | font un calcul en fonction de certaines dates, des EQUIV pour trouver | le numéro de la colonne concernée... | Donc, évidemment, une fois la plage convertie en liste, les formules ne | fonctionnent plus.
Si tes formules ne contiennent pas l'étiquette de colonne, pourquoi as-tu un problème avec une formule comme "SommeProd"
Peut-être que ma compréhension de ton problème ne correspond pas à ta réalité ! A l'intérieur d'une formule, la suggestion de Misange ( *1 ) sur une colonne de dates s'avèrent utile... mais mon propos se voulait une distinction entre les données et la ligne d'étiquette des colonnes.
Misange
michdenis a écrit :
Sinon Isabelle va t'envoyer au cachot en XFD1048576 (version Excel 2007) et ce n'est pas demain que quelqu'un va passer par là pour te faire sortir !!! ;-)))
et alors avec xl2010 je te dis pas la hauteur de l'échelle qu'il va falloir ! le temps de descendre t'es déjà mort... :-) Misange
michdenis a écrit :
Sinon Isabelle va t'envoyer au cachot en XFD1048576
(version Excel 2007) et ce n'est pas demain que
quelqu'un va passer par là pour te faire sortir !!!
;-)))
et alors avec xl2010 je te dis pas la hauteur de l'échelle qu'il va
falloir ! le temps de descendre t'es déjà mort...
:-)
Misange
Sinon Isabelle va t'envoyer au cachot en XFD1048576 (version Excel 2007) et ce n'est pas demain que quelqu'un va passer par là pour te faire sortir !!! ;-)))
et alors avec xl2010 je te dis pas la hauteur de l'échelle qu'il va falloir ! le temps de descendre t'es déjà mort... :-) Misange
Misange
Circé a écrit :
Merci Misange pour ta réponse. C'est exactement ça.
je me doutais je dois avoir le même genre à la maison :-)
Je passe sur les détails... Ce tableau fait 120 colonnes !
Raison de plus pour ne pas te fader à la main la définition de tous tes noms de façon dynamique !!!
Tu y gagneras en temps, même si de fait il faudra expliquer un peu plus.
Misange
Circé a écrit :
Merci Misange pour ta réponse. C'est exactement ça.
je me doutais je dois avoir le même genre à la maison :-)
Je passe sur les détails... Ce tableau fait 120 colonnes !
Raison de plus pour ne pas te fader à la main la définition de tous tes
noms de façon dynamique !!!
Tu y gagneras en temps, même si de fait il faudra expliquer un peu plus.
Merci Misange pour ta réponse. C'est exactement ça.
je me doutais je dois avoir le même genre à la maison :-)
Je passe sur les détails... Ce tableau fait 120 colonnes !
Raison de plus pour ne pas te fader à la main la définition de tous tes noms de façon dynamique !!!
Tu y gagneras en temps, même si de fait il faudra expliquer un peu plus.
Misange
Modeste
Bonsour® Misange avec ferveur ;o))) vous nous disiez :
En fait ce n'est pas tant que l'en tête est une donnée. Quand on utilise une date dans l'entête c'est souvent parce que c'est pertinent et pratique !
j'ai beaucoup de tableaux ou je rentre des données au jour le jour. La première ligne de mon tableau ce sont les dates et je ne vois pas en quoi ce serait plus simple d'appeler col1 col2 col3... les entêtes, sachant que ça ne me dit rien alors que 1/9/09, 2/9/09... est très parlant !
je ne te contredirais pas, mais ce n'est pas aux vieux singes .... etc.... ;o))) "ByDesign" ce phénoméne génant est ET a notament toujours été actif également lors de l'utilisation des TCD ainsi que de l'assistant d'importation.
;o))) ne vaut-il pas mieux dans ce cas modifier quelque-peu les entêtes, de façon à empécher l'interprétation automatique de ces pseudo données peut-etre un caractère à ajouter en début de nom de champ exemple : "_" caractère qui pourrait ensuite etre éludé lors des ultilisations ultérieures.
@+
Bonsour® Misange avec ferveur ;o))) vous nous disiez :
En fait ce n'est pas tant que l'en tête est une donnée. Quand on
utilise une date dans l'entête c'est souvent parce que c'est
pertinent et pratique !
j'ai beaucoup de tableaux ou je rentre des données au jour le jour. La
première ligne de mon tableau ce sont les dates et je ne vois pas en
quoi ce serait plus simple d'appeler col1 col2 col3... les entêtes,
sachant que ça ne me dit rien alors que 1/9/09, 2/9/09... est très
parlant !
je ne te contredirais pas, mais ce n'est pas aux vieux singes .... etc....
;o)))
"ByDesign" ce phénoméne génant est ET a notament toujours été actif également lors de l'utilisation des TCD
ainsi que de l'assistant d'importation.
;o)))
ne vaut-il pas mieux dans ce cas modifier quelque-peu les entêtes, de façon à empécher l'interprétation automatique de ces pseudo données
peut-etre un caractère à ajouter en début de nom de champ
exemple : "_"
caractère qui pourrait ensuite etre éludé lors des ultilisations ultérieures.
Bonsour® Misange avec ferveur ;o))) vous nous disiez :
En fait ce n'est pas tant que l'en tête est une donnée. Quand on utilise une date dans l'entête c'est souvent parce que c'est pertinent et pratique !
j'ai beaucoup de tableaux ou je rentre des données au jour le jour. La première ligne de mon tableau ce sont les dates et je ne vois pas en quoi ce serait plus simple d'appeler col1 col2 col3... les entêtes, sachant que ça ne me dit rien alors que 1/9/09, 2/9/09... est très parlant !
je ne te contredirais pas, mais ce n'est pas aux vieux singes .... etc.... ;o))) "ByDesign" ce phénoméne génant est ET a notament toujours été actif également lors de l'utilisation des TCD ainsi que de l'assistant d'importation.
;o))) ne vaut-il pas mieux dans ce cas modifier quelque-peu les entêtes, de façon à empécher l'interprétation automatique de ces pseudo données peut-etre un caractère à ajouter en début de nom de champ exemple : "_" caractère qui pourrait ensuite etre éludé lors des ultilisations ultérieures.
@+
isabelle
> michdenis a écrit :
Sinon Isabelle va t'envoyer au cachot en XFD1048576 (version Excel 2007) et ce n'est pas demain que quelqu'un va passer par là pour te faire sortir !!! ;-)))
et alors avec xl2010 je te dis pas la hauteur de l'échelle qu'il va falloir ! le temps de descendre t'es déjà mort... :-) Misange
va falloir renflouer d'une bonne cuvé pour attirer les passants ;-) isabelle
> michdenis a écrit :
Sinon Isabelle va t'envoyer au cachot en XFD1048576
(version Excel 2007) et ce n'est pas demain que
quelqu'un va passer par là pour te faire sortir !!!
;-)))
et alors avec xl2010 je te dis pas la hauteur de l'échelle qu'il va
falloir ! le temps de descendre t'es déjà mort...
:-)
Misange
va falloir renflouer d'une bonne cuvé pour attirer les passants ;-)
isabelle
Sinon Isabelle va t'envoyer au cachot en XFD1048576 (version Excel 2007) et ce n'est pas demain que quelqu'un va passer par là pour te faire sortir !!! ;-)))
et alors avec xl2010 je te dis pas la hauteur de l'échelle qu'il va falloir ! le temps de descendre t'es déjà mort... :-) Misange
va falloir renflouer d'une bonne cuvé pour attirer les passants ;-) isabelle
Misange
isabelle a écrit :
va falloir renflouer d'une bonne cuvé pour attirer les passants ;-) isabelle
t'as du boulot mon ange, tu peux appeller JPS à la rescousse pour qu'il te trouve des prix de gros :-) Ca sera pire que le tonneau des Danaïdes sur ce coup là
Misange
isabelle a écrit :
va falloir renflouer d'une bonne cuvé pour attirer les passants ;-)
isabelle
t'as du boulot mon ange, tu peux appeller JPS à la rescousse pour qu'il
te trouve des prix de gros :-)
Ca sera pire que le tonneau des Danaïdes sur ce coup là
va falloir renflouer d'une bonne cuvé pour attirer les passants ;-) isabelle
t'as du boulot mon ange, tu peux appeller JPS à la rescousse pour qu'il te trouve des prix de gros :-) Ca sera pire que le tonneau des Danaïdes sur ce coup là
Misange
Misange
Modeste a écrit :
je ne te contredirais pas, mais
c'est juste ce que tu fais :-)
ce n'est pas aux vieux singes .... etc....
;o))) "ByDesign" ce phénoméne génant est ET a notament toujours été actif également lors de l'utilisation des TCD ainsi que de l'assistant d'importation.
;o))) ne vaut-il pas mieux dans ce cas modifier quelque-peu les entêtes, de façon à empécher l'interprétation automatique de ces pseudo données peut-etre un caractère à ajouter en début de nom de champ exemple : "_" caractère qui pourrait ensuite etre éludé lors des ultilisations ultérieures.
relis ma réponse à Denis et tu verras que ce que tu proposes consiste juste à rajouter une couche de complication inutile quand un simple *1 fait l'affaire. Je ne veux SURTOUT pas empêcher l'interprétation automatique du champ. Ce que je voudrais c'est exactement l'inverse : la permettre et aujourd'hui ça n'est pas le cas parce qu'excel transforme les dates en texte. Là où il est agaçant c'est que dès qu'il peut habituellement, il essaie d'interpréter, souvent à contresens, mais là, quand ce serait BIEN qu'il conserve leur typage aux données, il les modifie.
Misange
Modeste a écrit :
je ne te contredirais pas, mais
c'est juste ce que tu fais :-)
ce n'est pas aux vieux singes .... etc....
;o)))
"ByDesign" ce phénoméne génant est ET a notament toujours été actif également lors de l'utilisation des TCD
ainsi que de l'assistant d'importation.
;o)))
ne vaut-il pas mieux dans ce cas modifier quelque-peu les entêtes, de façon à empécher l'interprétation automatique de ces pseudo données
peut-etre un caractère à ajouter en début de nom de champ
exemple : "_"
caractère qui pourrait ensuite etre éludé lors des ultilisations ultérieures.
relis ma réponse à Denis et tu verras que ce que tu proposes consiste
juste à rajouter une couche de complication inutile quand un simple *1
fait l'affaire. Je ne veux SURTOUT pas empêcher l'interprétation
automatique du champ. Ce que je voudrais c'est exactement l'inverse : la
permettre et aujourd'hui ça n'est pas le cas parce qu'excel transforme
les dates en texte. Là où il est agaçant c'est que dès qu'il peut
habituellement, il essaie d'interpréter, souvent à contresens, mais là,
quand ce serait BIEN qu'il conserve leur typage aux données, il les modifie.
;o))) "ByDesign" ce phénoméne génant est ET a notament toujours été actif également lors de l'utilisation des TCD ainsi que de l'assistant d'importation.
;o))) ne vaut-il pas mieux dans ce cas modifier quelque-peu les entêtes, de façon à empécher l'interprétation automatique de ces pseudo données peut-etre un caractère à ajouter en début de nom de champ exemple : "_" caractère qui pourrait ensuite etre éludé lors des ultilisations ultérieures.
relis ma réponse à Denis et tu verras que ce que tu proposes consiste juste à rajouter une couche de complication inutile quand un simple *1 fait l'affaire. Je ne veux SURTOUT pas empêcher l'interprétation automatique du champ. Ce que je voudrais c'est exactement l'inverse : la permettre et aujourd'hui ça n'est pas le cas parce qu'excel transforme les dates en texte. Là où il est agaçant c'est que dès qu'il peut habituellement, il essaie d'interpréter, souvent à contresens, mais là, quand ce serait BIEN qu'il conserve leur typage aux données, il les modifie.
Misange
Modeste
Bonsour® Misange avec ferveur ;o))) vous nous disiez :
Modeste a écrit :
je ne te contredirais pas, mais
c'est juste ce que tu fais :-) ce n'est pas aux vieux singes .... etc....
;o)))
j'essaie donc de me rattraper aux branches... ;o))) je viens de jeter un oeil sur les mises à jours Excelabo en l'occurence : les récents articles consacrés aux tables... que je n'avaient pas parcourus, car ne possédant pas EXCEL 2007. Il y a en effet ambiguité entre les notions de listes (Excel 2002) et les notions de Tables (Excel 2007)
Trompé par le titre de ce fil, j'ai donc en toute innocence mis le pied en terre inconnue et interféré dans la cour "des grands" ... ;o))) je m'en excuse et prie Circé de ne pas considerer le vocable supposé lui avoir été par moi-même appliqué... :-(
@+
Bonsour® Misange avec ferveur ;o))) vous nous disiez :
Modeste a écrit :
je ne te contredirais pas, mais
c'est juste ce que tu fais :-)
ce n'est pas aux vieux singes .... etc....
;o)))
j'essaie donc de me rattraper aux branches... ;o)))
je viens de jeter un oeil sur les mises à jours Excelabo
en l'occurence : les récents articles consacrés aux tables...
que je n'avaient pas parcourus, car ne possédant pas EXCEL 2007.
Il y a en effet ambiguité entre les notions de listes (Excel 2002) et les notions de Tables (Excel 2007)
Trompé par le titre de ce fil, j'ai donc en toute innocence mis le pied en terre inconnue
et interféré dans la cour "des grands" ...
;o)))
je m'en excuse et prie Circé de ne pas considerer le vocable supposé lui avoir été par moi-même appliqué...
:-(
Bonsour® Misange avec ferveur ;o))) vous nous disiez :
Modeste a écrit :
je ne te contredirais pas, mais
c'est juste ce que tu fais :-) ce n'est pas aux vieux singes .... etc....
;o)))
j'essaie donc de me rattraper aux branches... ;o))) je viens de jeter un oeil sur les mises à jours Excelabo en l'occurence : les récents articles consacrés aux tables... que je n'avaient pas parcourus, car ne possédant pas EXCEL 2007. Il y a en effet ambiguité entre les notions de listes (Excel 2002) et les notions de Tables (Excel 2007)
Trompé par le titre de ce fil, j'ai donc en toute innocence mis le pied en terre inconnue et interféré dans la cour "des grands" ... ;o))) je m'en excuse et prie Circé de ne pas considerer le vocable supposé lui avoir été par moi-même appliqué... :-(
