Discussion :

[ZZZzzz2]

Bonjour,


Pour résumer rapidement j'ai implémenté une méthode qui se charge de faire un publipostage sous Word, d'enregistrer le fichier et de rendre la main à l'utilisateur...

Seulement voilà avec certains documents WORD sous Windows 2000, avec un compte utilisateur à droit restreint (pas admin) et sous Word 2000 je me tape une erreur "Serveur RPC Indisponible" lorsque j'appelle la méthode 'Document.SaveAs(...'
L'appel échoue immédiatement (pas de timeout comme je le pensais deprime abord), pour une raison que j'ignore l'objet '_Document' semble être devenu indisponible.

Seulement cela ne se produit pas tout le temps, j'aurai même tendance à dire que lorsque pas mal de conditions sont réunis (celles que je vous ai indiqué plus haut).

Si quelqu'un a une idée de ce qui peut me causer cette erreur car j'ai tenté plusieurs implémentations, j'ai fait pas mal de recherche, en vain...

éventuellement je posterai les détails de l'implémentation si personne ne peut m'aider dans un premier temps.

Merci d'avance.

[cmen76]

Serveur RPC Indisponible

Cela signifie que la liaison COM a été rompue entre le programme et le serveur COM (Word).
Je te conseille de te pencher sur les pistes suivantes : antivirus, protection contre les vers, firewall, etc.
Peut-être trouveras-tu des éléments de réponses en consultant le journal de l'observateur d'événements...
Bon courage.

[ZZZzzz2]

Cela signifie que la liaison COM a été rompue entre le programme et le serveur COM (Word).
Je te conseille de te pencher sur les pistes suivantes : antivirus, protection contre les vers, firewall, etc.
Peut-être trouveras-tu des éléments de réponses en consultant le journal de l'observateur d'événements...
Bon courage.

Merci beaucoup pour ta réponse, d'après toi lors de l'appel à la méthode 'SaveAs' (et donc lors de la sauvegarde du fichier) quelquechose vient entraver la tache et casse la liaison entre objet et serveur COM ?

Ce que je ne comprend pas c'est pourquoi cela arrive-t-il uniquement avec certains document qui en apparence n'ont rien de particulier par rapport aux autres (si ce n'est d'après l'utilisateur une plus grande complexité dans les scripts peut-être), enfin en y réfléchissant un peu cela aurait tendance à aller dans le sens c'un antivirus qui pourrait foutre la merde. Je vais peut-être essayer d'inspecter un peu de ce côté...

Sinon juste pour infos quelle est la différence l'objet '_Application' et 'TWordApplication' ? Je sais que j'ai rencontré des problèmes de "synchronisation" avec en manipulant le "TWordApplication" : messages d'erreurs de type 'un appel asynchrone a été effectué...".
car j'ai l'impression que "TWordApplication" effectue des appels asynchrones (ce qui peut poser pas mal de problèmes) contrairement à '_Application' .

J'avoue que je ne comprend pas toujours le mécanisme qui déclenche l'erreur "Serveur RPC indisponible"...

[cmen76]

TWordApplication est un objet qui encapsule les appels au serveur COM _Application. En fait, il est censé permettre une manipulation de l'objet COM plus intuitive (façon Delphi) qu'en s'y attaquant directement (que des OLEVariant...). En plus, il ajoute des "event sinks" c'est-à-dire qu'il est notifié de quelques actions effectuées par l'utilisateur sur l'objet OLE (nouveau docuement, quitter, etc).
En ce qui concerne COM, c'est un peu une boîte noire...
Un serveur COM est invoqué (par la création d'une co-classe) ; s'il est déjà chargé, il incrémente son compteur d'instance. Quand ce dernier revient à 0, il se libère de la mémoire.
Pour avoir travaillé sur des objets DCOM (Distributed COM, soit un client COM et un serveur COM sur 2 postes différents d'un réseau), si une panne réseau intervient pendant une transaction, on obtient le même message 'Serveur RPC indisponible'...
Fais quelques recherches sur OLE, COM, DCOM pour plus de précision. MSDN par exemple.

[ZZZzzz2]

TWordApplication est un objet qui encapsule les appels au serveur COM _Application. En fait, il est censé permettre une manipulation de l'objet COM plus intuitive (façon Delphi) qu'en s'y attaquant directement (que des OLEVariant...). En plus, il ajoute des "event sinks" c'est-à-dire qu'il est notifié de quelques actions effectuées par l'utilisateur sur l'objet OLE (nouveau docuement, quitter, etc).
En ce qui concerne COM, c'est un peu une boîte noire...
Un serveur COM est invoqué (par la création d'une co-classe) ; s'il est déjà chargé, il incrémente son compteur d'instance. Quand ce dernier revient à 0, il se libère de la mémoire.
Pour avoir travaillé sur des objets DCOM (Distributed COM, soit un client COM et un serveur COM sur 2 postes différents d'un réseau), si une panne réseau intervient pendant une transaction, on obtient le même message 'Serveur RPC indisponible'...
Fais quelques recherches sur OLE, COM, DCOM pour plus de précision. MSDN par exemple.

Merci, je le voyais ainsi mais pourquoi TWordApplication ferai des appels asynchrones ?? Peut-être justement pour sa gestion d'événements...

En fait j'ai déjà pas mal regardé mais quelques "trucs" me semlbent un peu flous. moi j'utilise COM uniquement en local (sur le même poste), uniquement pour une communication inter-application. Je passe souvent par des controles activeX car c'est simple d'usage par parfois j'ai des erreurs "serveur RPC indisponibles" pour des raisons que j'ai un peu de mal à cerner. Mais souvent cela arrive conjointement à l'utilisation de composant asynchrone...

[cmen76]

Je ne sais pas à quel niveau pourrait se déclencher une transaction asynchrone. Par contre une chose est certaine c'est que RPC signifie Remote Procedure Call. Donc même si l'appel reste local, il est identifié comme pouvant être distant (probablement un CreateRemote sur la coclasse).
Et si le serveur est de type COM+, il y a fort à parier que MSDTC (Microsoft Distributed Transaction Coordinator) soit invoqué, et là, on nage en plein asynchrone...
Il faudrait contacter un gourou de l'administration Windows pour savoir quels sont les droits à paramétrer et sur quels objets, mais là franchement ça dépasse largement mes connaissances.