AppleWorks 6 concat ne fonctionne pas

furiet

Membre actif
23 Mai 2005
701
8
84
Bonjour à tous
J'ai beau essayer de copier la syntaxe de l'exemple de l'Aide, ou celle affichée quand on choisit la fonction concat à l'intérieur d'une fonction de transformation de texte, cela ne marche jamais, j'ai toujours l'indication comme quoi la syntaxe est incorrecte.
N'ayant rien trouvé sur Internet concernant ce problème, je mets tus mes espoirs dans ce forum.
 
Disons que si tu donnais un minimum d'indications, ça pourrait aider à comprendre le contexte.

Pour le moment, tout ce que je peux en dire c'est que la fonction =CONCAT(A1;" ";B1) donne bien la concaténation du contenu des cellules A1 et B1, séparé par une espace. Ce qui revient, rappelons-le, exactement au même que la saisie de =A1&" "&B1.

Si chez toi les choses sont différentes, c'est probablement que le contexte n'est pas le même… d'où le besoin de précisions (si possible illustrées d'un exemple simple).
 
… la fonction =CONCAT(A1;" ";B1) … Ce qui revient, rappelons-le, exactement au même que la saisie de =A1&" "&B1.

"Exactement" … Pas vraiment, fais donc l'expérience de mettre à jour une feuille avec 5000 ou 10 000 formules "concat", puis une autre avec la même quantité d'additions textuelles, je pense que le chronomètre te montrera la différence qu'il y a entre les deux :siffle:

:D
 
Bonjour à vous deux
C'est pour une base AW, pas pour un tableau, que j'ai besoin de la concaténation.
Je veux convertir une base AW en fichier FMP.
Pour cela, la (ou une) méthode consiste à :
- sous AWW enregistrer la base en format ASCII, suffice txt
- sous Excel importer ce fichier, in indiquant comme séparateur celui de AW, la tabulation
- sous Excel exporter le fichier importé en format csv
- ouvrir le fichier csv sous FMP
Le format csv utilise comme séparateur la "," et non la tabulation.
Dans la base à convertir, il y a des rubriques textuelles dans lesquelles j'ai utilisé des ",".
Je me suis donc demandé comment encapsuler ces rubriques, sachant que leur contenu devait dans ce cas être entouré de doubles guillemets "
Dans la formule de concaténation de AW, on peut inclure des noms de rubriques, entourés de guillemets simples, ', et des constantes littérales, entourées de doubles guillemets ".
Avec n'importe quel caractère cette possibilité semble fonctionner, sauf pour le caractère double guillemet "
C'est à propos de cette seule anomalie que je voulais savoir si d'autres l'avaient rencontré.
Autre anomalie : dans certaines rubriques textuelles, l'ai utilisé des Return : ceux-ci sont bien affichés sous AW, avec la préférence "afficher les caractères invisibles", mais une fois la base exportée en type "txt", on ne les voit plus, par exemple sous Bean, avec l'option "afficher les caractères invisibles".
Enfin, mais ceci concerne Excel 2004, celui-ci très curieusement lors d'une exportation en csv, ne convertit pas les tabulations en ",", mais en ";", et du même coup FMP ne voit qu'une seule rubrique.
 
Bonjour à vous deux
C'est pour une base AW, pas pour un tableau, que j'ai besoin de la concaténation.
Je veux convertir une base AW en fichier FMP.
Pour cela, la (ou une) méthode consiste à :
- sous AWW enregistrer la base en format ASCII, suffice txt
- sous Excel importer ce fichier, in indiquant comme séparateur celui de AW, la tabulation
- sous Excel exporter le fichier importé en format csv
- ouvrir le fichier csv sous FMP
Le format csv utilise comme séparateur la "," et non la tabulation.
Dans la base à convertir, il y a des rubriques textuelles dans lesquelles j'ai utilisé des ",".
Je me suis donc demandé comment encapsuler ces rubriques, sachant que leur contenu devait dans ce cas être entouré de doubles guillemets "
Dans la formule de concaténation de AW, on peut inclure des noms de rubriques, entourés de guillemets simples, ', et des constantes littérales, entourées de doubles guillemets ".
Avec n'importe quel caractère cette possibilité semble fonctionner, sauf pour le caractère double guillemet "
C'est à propos de cette seule anomalie que je voulais savoir si d'autres l'avaient rencontré.
Autre anomalie : dans certaines rubriques textuelles, l'ai utilisé des Return : ceux-ci sont bien affichés sous AW, avec la préférence "afficher les caractères invisibles", mais une fois la base exportée en type "txt", on ne les voit plus, par exemple sous Bean, avec l'option "afficher les caractères invisibles".
Enfin, mais ceci concerne Excel 2004, celui-ci très curieusement lors d'une exportation en csv, ne convertit pas les tabulations en ",", mais en ";", et du même coup FMP ne voit qu'une seule rubrique.

Ton excel 2004 ne serait pas en version "US", par hasard ? (le csv n'utilise la virgule qu'en France, ailleurs, c'est le ";" qui est utilisé, et mon Excel 2004 emploie bien la virgule, lui).

Cela dit, si tu as "Excel", tu as certainement "Word", donc il y a plus simple : tu exporte en "séparé tab", tu ouvres ton fichier texte avec Word, tu fais "Edition -> Rechercher/remplacer", tu cherches "^t", et tu remplaces par "," (sans les guillemets, of course) tu cliques sur "remplacer tout", et ça fonctionne !
 
Ton excel 2004 ne serait pas en version "US", par hasard ? (le csv n'utilise la virgule qu'en France, ailleurs, c'est le ";" qui est utilisé, et mon Excel 2004 emploie bien la virgule, lui).
Tu n'aurais pas inversé un peu les choses ? Le séparateur de champs standard US, c'est justement la virgule (et c'est aussi ce qui est employé dans les versions US comme séparateur d'arguments dans les formules). C'est pour nous autres européens qui utilisons déjà la virgule comme séparateur décimal (eux, c'est le point) que le point-virgule est le standard des versions FR (et pour ceux qui sont concernés, rappelons que les macros VBA sont au standard US même pour les versions FR, donc avec le point comme séparateur décimal et la virgule comme séparateur de champs).

Si ça devait avoir un caractère répétitif (j'en doute un peu dans le cas présent), pour exporter facilement le fichier avec la virgule comme séparateur de champ, tu peux passer par une macro, justement. Par exemple en t'inspirant de cette page d'Excelabo... Il faut voir si ça fonctionne avec Excel 2004 (pas ça sous la main pour le moment, il faudra attendre ce soir).

Pour une utilisation unique, le passage par Word me semble aussi la solution la plus simple...

En ce qui concerne les retours chariot, il est possible que ça pose problème (c'est souvent interprété comme un séparateur de champs à un moment ou un autre dans une "poly-conversion"). Il faut que je regarde ça de plus près. Donc ce soir itou. Même chose encore pour les guillemets doubles (nécessaires pour distinguer les virgules "texte" des virgules "séparateur").
 
Bonjour à tous les deux
Mon Excel 2004 a une interface (les menus) en Français.
Donc il serait conforme à ce que dit Aliboron.
Mais de toutes façons mon problème est que mon FMP 11 utilise les "," comme séparateurs.
J'ai donc comme vous me le suggérez fait un rechercher ";" remplacer par "," sous le logiciel de traitement de texte Bean, qui permet d'afficher les caractères invisibles, contrairement à Textedit.
Pour l'histoire des Return qui apparaissent à l'intérieur de rubriques sous AW mais disparaissent dans la version exportée txt, il faudrait que je vous envoie des fichiers joints, ce que je ne sais pas faire sur ce forum.
J'ai bien apprécié sous AW la très grande liberté dont on dispose dans une rubrique texte, mais c'est peut-être pareil avec d'autres bases, dont FMP par exemple.
Y a-t-il quelque part un site traitant du problème de conversion base AW en base FMP 11 ?
Ceci dans le cadre du passage de SL à Mountain Lion et suivants.

---------- Nouveau message ajouté à 14h47 ---------- Le message précédent a été envoyé à 14h37 ----------

Aliboron
"ça n'a rien de "curieux"
J'ai consulté ce site à propos de csv
CSV Files
indiquant des séparateurs ",", d'où mon étonnement.
Je ne savais pas que le format csv était différent en Français et dans les langues anglo-saxonnes.
 
J'ai consulté ce site à propos de csv : CSV Files indiquant des séparateurs ",", d'où mon étonnement.
Je ne savais pas que le format csv était différent en Français et dans les langues anglo-saxonnes.
Ben oui. Les anglo-saxons ont fortement tendance à ignorer que le reste du monde existe et qu'en plus il est peuplé de non-américains. Les normes ont donc au départ été calées sur les habitudes US (voir par ailleurs les débats sur les formats de date). Il se trouve que nous autres Français (entre autres) n'utilisons pas le point comme séparateur décimal mais la virgule ! Ce qui pose rapidement problème lorsqu'il faut "marier" notre séparateur décimal (virgule, donc) avec le séparateur de champs (virgule aussi).

Le choix a donc été fait d'utiliser le point-virgule comme séparateur de champs (chance : il ne sert pas beaucoup, et pas du tout dans les formats numériques) pour nous autres. Ce qui pose, effectivement, d'autres problèmes avec les logiciels non francisés, ou francisés différemment (plus rare).

En sens inverse, on rencontre aussi souvent des problèmes en important des fichiers au standard US (en particulier des nombres qui sont vus comme des chaînes de caractère du fait de la présence du point comme séparateur décimal). Les joies de l'utilisation au quotidien de normes conçues dans un contexte différent (dans les premiers temps de l'informatique, les échanges internationaux en temps réel relevaient de la science-fiction)...