En ouvrant une source de donn=E9es (Excel) comme suit sous Word 2003 pour=
=20
cr=E9er une fusion (pour pr=E9senter automatiquement chaque enregistremen=
t=20
sur une page), je me ramasse une erreur 5121 lors de l'ouverture de=20
fichier sur l'instruction Merge, on me propose de v=E9rifier les=20
autorisations du fichier/lecteur, v=E9rifier que la m=E9moire et l'espace=
=20
disque sont suffisants, ou ouvrir le fichier avec le convertisseur=20
R=E9cup=E9ration de texte.
Si je fais la m=EAme chose =E0 la main la fusion se fait bien.
J'imagine que j'ai commis une bourde ?
Pour la s=E9lection du fichier par l'utilisateur, serait-ce une meilleure=
=20
id=E9e de passer par l'API ? =E7a a priori =E7a marche, mais si Microsoft=
=20
s'est donn=E9 le mal de fournir des bo=EEtes de dialogue dans Word,=20
j'imagine que la moindre des choses avant de faire appel aux API est de=20
v=E9rifier que =E7a apporte vraiment un plus. C'est gentil wdDialogFileOp=
en,=20
mais =E7a ouvre le fichier, plut=F4t que de le s=E9lectionner. Ou j'ai ou=
bli=E9=20
une astuce ?
Public Sub CreationFusion()
Dim strCheminFichier As String
strCheminFichier =3D SelFichier()
ActiveDocument.Merge FileName:=3DstrCheminFichier
End Sub
Public Function SelFichier()
Dialogs(wdDialogFileOpen).Show
SelFichier =3D Application.ActiveDocument.Path
ActiveDocument.Close
End Function
Hum, sécuriser en incluant un fichier texte qui peut être piraté plus facilement, j'sais pas, j'ai l'impression que c'est une question à approfondir ...
Ce que je voulais dire, c'est qu'en conservant une source unique, on risquait moins de faire des erreurs de recopie ou de retranscription. En particulier, on s'évite la tentation d'aller modifier en dur dans la séquence qu'on peut être amené à recopier pour une autre utilisation. Surtout quand on recopie sans trop comprendre, ce qui est le lot d'un certain nombre de vba-sistes. La sécurité dont je parlais, s'arrêtait là. Ceci dit, quand une fonction est prévue dans Office, je préfère m'en servir surtout que la présentation des boites de dialogue évolue, mais pas les API sans doute.
Merci pour le lien.
-- A+
Re
Hum, sécuriser en incluant un fichier texte qui peut être piraté plus facilement,
j'sais pas, j'ai l'impression que c'est une question à approfondir ...
Ce que je voulais dire, c'est qu'en conservant une source unique, on
risquait moins de faire des erreurs de recopie ou de retranscription.
En particulier, on s'évite la tentation d'aller modifier en dur dans la
séquence qu'on peut être amené à recopier pour une autre utilisation.
Surtout quand on recopie sans trop comprendre, ce qui est le lot d'un
certain nombre de vba-sistes.
La sécurité dont je parlais, s'arrêtait là.
Ceci dit, quand une fonction est prévue dans Office, je préfère m'en
servir surtout que la présentation des boites de dialogue évolue, mais
pas les API sans doute.
Hum, sécuriser en incluant un fichier texte qui peut être piraté plus facilement, j'sais pas, j'ai l'impression que c'est une question à approfondir ...
Ce que je voulais dire, c'est qu'en conservant une source unique, on risquait moins de faire des erreurs de recopie ou de retranscription. En particulier, on s'évite la tentation d'aller modifier en dur dans la séquence qu'on peut être amené à recopier pour une autre utilisation. Surtout quand on recopie sans trop comprendre, ce qui est le lot d'un certain nombre de vba-sistes. La sécurité dont je parlais, s'arrêtait là. Ceci dit, quand une fonction est prévue dans Office, je préfère m'en servir surtout que la présentation des boites de dialogue évolue, mais pas les API sans doute.
Merci pour le lien.
-- A+
Gloops
Geo a écrit, le 20/11/2010 13:59 :
Re
Hum, sécuriser en incluant un fichier texte qui peut être piraté plus facilement, j'sais pas, j'ai l'impression que c'est une question à approfondir ...
Ce que je voulais dire, c'est qu'en conservant une source unique, on risquait moins de faire des erreurs de recopie ou de retranscription. En particulier, on s'évite la tentation d'aller modifier en dur dans la séquence qu'on peut être amené à recopier pour une autre utilis ation. Surtout quand on recopie sans trop comprendre, ce qui est le lot d'un certain nombre de vba-sistes.
Il est certain que c'est toujours préférable de réutiliser un code, que de le recopier, ne serait-ce que pour les mises à jour / corrections.
La bonne démarche me semble consister à bien mettre au point son code (des exemples sont fournis tout prêts pour faciliter les choses, mais après on peut mettre des paramètres Optional pour préciser le titre de la boîte de dialogue, le type de fichiers, le répertoire, et prévoi r les cas où chacun des paramètres est fourni ou pas, et une fois que tout ça fonctionne, on peut récupérer le module dans une autre base (si je pe nse à Access par exemple).
Pour que le code soit vraiment réutilisable sans copie, il me semble qu'il faut pousser le bouchon jusqu'à l'add-on, et que c'est à la por tée de moins de monde. L'avantage, c'est que moins de monde est susceptible de coder des bêtises dedans, il est assez rare qu'un add-on soit véro lé.
La sécurité dont je parlais, s'arrêtait là. Ceci dit, quand une fonction est prévue dans Office, je préfère m 'en servir surtout que la présentation des boites de dialogue évolue, m ais pas les API sans doute.
On aurait pu concevoir d'écrire un add-on pour les dialogues standard, mais finalement Microsoft a choisi une intégration encore meilleure en créant des boîtes de dialogue reconnues par VB. Il est vrai que là, comme on n'a pas à se taper l'initialisation de tous les paramètres, ça gagne quand même un sacré bout de temps.
Merci pour le lien.
Pas de quoi.
Geo a écrit, le 20/11/2010 13:59 :
Re
Hum, sécuriser en incluant un fichier texte qui peut être piraté plus
facilement, j'sais pas, j'ai l'impression que c'est une question à
approfondir ...
Ce que je voulais dire, c'est qu'en conservant une source unique, on
risquait moins de faire des erreurs de recopie ou de retranscription.
En particulier, on s'évite la tentation d'aller modifier en dur dans la
séquence qu'on peut être amené à recopier pour une autre utilis ation.
Surtout quand on recopie sans trop comprendre, ce qui est le lot d'un
certain nombre de vba-sistes.
Il est certain que c'est toujours préférable de réutiliser un code, que
de le recopier, ne serait-ce que pour les mises à jour / corrections.
La bonne démarche me semble consister à bien mettre au point son code
(des exemples sont fournis tout prêts pour faciliter les choses, mais
après on peut mettre des paramètres Optional pour préciser le titre de
la boîte de dialogue, le type de fichiers, le répertoire, et prévoi r les
cas où chacun des paramètres est fourni ou pas, et une fois que tout ça
fonctionne, on peut récupérer le module dans une autre base (si je pe nse
à Access par exemple).
Pour que le code soit vraiment réutilisable sans copie, il me semble
qu'il faut pousser le bouchon jusqu'à l'add-on, et que c'est à la por tée
de moins de monde. L'avantage, c'est que moins de monde est susceptible
de coder des bêtises dedans, il est assez rare qu'un add-on soit véro lé.
La sécurité dont je parlais, s'arrêtait là.
Ceci dit, quand une fonction est prévue dans Office, je préfère m 'en
servir surtout que la présentation des boites de dialogue évolue, m ais
pas les API sans doute.
On aurait pu concevoir d'écrire un add-on pour les dialogues standard,
mais finalement Microsoft a choisi une intégration encore meilleure en
créant des boîtes de dialogue reconnues par VB. Il est vrai que là,
comme on n'a pas à se taper l'initialisation de tous les paramètres, ça
gagne quand même un sacré bout de temps.
Hum, sécuriser en incluant un fichier texte qui peut être piraté plus facilement, j'sais pas, j'ai l'impression que c'est une question à approfondir ...
Ce que je voulais dire, c'est qu'en conservant une source unique, on risquait moins de faire des erreurs de recopie ou de retranscription. En particulier, on s'évite la tentation d'aller modifier en dur dans la séquence qu'on peut être amené à recopier pour une autre utilis ation. Surtout quand on recopie sans trop comprendre, ce qui est le lot d'un certain nombre de vba-sistes.
Il est certain que c'est toujours préférable de réutiliser un code, que de le recopier, ne serait-ce que pour les mises à jour / corrections.
La bonne démarche me semble consister à bien mettre au point son code (des exemples sont fournis tout prêts pour faciliter les choses, mais après on peut mettre des paramètres Optional pour préciser le titre de la boîte de dialogue, le type de fichiers, le répertoire, et prévoi r les cas où chacun des paramètres est fourni ou pas, et une fois que tout ça fonctionne, on peut récupérer le module dans une autre base (si je pe nse à Access par exemple).
Pour que le code soit vraiment réutilisable sans copie, il me semble qu'il faut pousser le bouchon jusqu'à l'add-on, et que c'est à la por tée de moins de monde. L'avantage, c'est que moins de monde est susceptible de coder des bêtises dedans, il est assez rare qu'un add-on soit véro lé.
La sécurité dont je parlais, s'arrêtait là. Ceci dit, quand une fonction est prévue dans Office, je préfère m 'en servir surtout que la présentation des boites de dialogue évolue, m ais pas les API sans doute.
On aurait pu concevoir d'écrire un add-on pour les dialogues standard, mais finalement Microsoft a choisi une intégration encore meilleure en créant des boîtes de dialogue reconnues par VB. Il est vrai que là, comme on n'a pas à se taper l'initialisation de tous les paramètres, ça gagne quand même un sacré bout de temps.
