Bonjour,
 
dans une application VB6, je crée une instance visible de WordBasic (un sous-objet de Word.Application, présentant à l'écran une instance de Word) via la fonction CreateObject de VB.  Cette manière de faire me rend compatible avec toutes les versions de Word depuis la version 95.
 
Je précise que l'objet, pour plusieurs raisons, est déclaré de type Object et que je suis obligé de faire comme cela (par le client), donc je ne peux trapper les events émis par cet objet.  Comme l'utilisateur a tout loisir de manipuler l'instance visible de Word, il a aussi le loisir de fermer Word.
 
Mon but est de déterminer si l'instance que j'ai créée est toujours disponible, et de la réutiliser si tel est le cas; autrement, je détruirai les restes de mon instance en cours, et j'en créerai une nouvelle.
 
Mon problème est, comment faire pour détecter si l'utilisateur ferme cette instance de Word?  Car l'utilisateur a toute liberté de s'en servir.  Malheureusement, mon "objet" est toujours présent et je n'ai pas vraiment de moyen de tester que l'objet créé est bien présent (donc différent de Nothing), je dirais même "disponible".
 
En fait, il y en a bien un: si je tente d'y accéder, j'aurai l'erreur 462 "The remote server machine does not exist or is unavailable", mais je me demandais s'il n'existait pas un moyen plus propre que de déclencher cette erreur.  OLE étant ce qu'il est, je doute que ce soit le seul cas où je pourrais avoir cette erreur, donc ce n'est pas assez précis et je ne veux pas risquer d'effets de bord indésirables.
 
 
Tout avis bienvenu, merci d'avance.

Mon expérience personnelle (mais non exhaustive) sur le sujet me laisse à penser que seule la gestion de l'erreur permettra de faire ce que tu veux.
 
a+

Je pense pareil (mais suis pas spécialiste ).
 
Quand on accède à une disquette (ça existe encore) ou a un disque dur qui peut être plein (ça existe moins car ils sont tellement gros), un bon réflexe est d'utiliser le On Error Goto xxx puis On Error goto 0 en quittant le module. On ajuste le traitement local à ce qui peut survenir.  
Ca permet de traîter de façon élégante un problème (disquette HS, absente, disque(tte) plein(e)).
 
Pour ce genre de chose, s'il n'y a pas de fonction "serveur OLE dispo ?", y a pas d'autre moyen (??). Idem s'il disparaît, ça évite pb ou plantage.
 
Up !

carbon_14 a écrit a écrit : Je pense pareil (mais suis pas spécialiste ).   Quand on accède à une disquette (ça existe encore) ou a un disque dur qui peut être plein (ça existe moins car ils sont tellement gros), un bon réflexe est d'utiliser le On Error Goto xxx puis On Error goto 0 en quittant le module. On ajuste le traitement local à ce qui peut survenir.   Ca permet de traîter de façon élégante un problème (disquette HS, absente, disque(tte) plein(e)).   Pour ce genre de chose, s'il n'y a pas de fonction "serveur OLE dispo ?", y a pas d'autre moyen (??). Idem s'il disparaît, ça évite pb ou plantage.   Up !

élégante le On Error Goto ?  

En VB, y a de mémoire, on Error goto, on error resume et ss dte une que j'oublie (je ne pratique plus VB !). J'ai un trou avec on error gosub ??? Je pense pas que ça existe ??
 
Les GOTO, ça fait beurk, mais en VB ou QB, c'est "normal". On peut faire des modules, fonctions, se débrouiller pour écrire des choses claires (ce que je m'efforçais de faire) mais pour dérouter les erreurs, ça galère. On ne peut même pas (en VB3)(à moins de ruser un max sous Quick Basic) sauter à une étiquette en dehors du module pour gérer globalement les erreurs. Ca ne se fait que localement (sous VB3). Null, mais faut faire avec.
 
Si on oublie de redérouter les erreurs, bug en puissance : le prog sait où sauter (goto ..) mais cette adresse est inaccessible => problème.
 
Suis passé à BC3/BC5. C'est (++) mieux...

Moi le VB C juste par obligation

J'avais mal lu .
Ce qui est élégant est de dérouter les erreurs...  
 
J'avais poussé un peu les choses en QuickBasic dans le temps : pour adapter le programme de tracé de spectres à la résolution réelle du PC (à l'"époque", on avait CGA, EGA, et qq VGA), je lançais le SCREEN le plus résolutif, en déroutant l'erreur, on passait au niveau inférieur, jusqu'à trouver le bon. A la fin, il restait Hercules, ou y a pas d'écran sur le PC .
 
Le VB, c'est rapide au niveau design, codage, test du résultat, etc.. Je m'y suis replongé y a peu pr faire modifs d'un des mes progs. Ca met du temps à revenir .

pour ce qui est de la gestion d'erreur, on fait un On Error Goto <label>, et si on a besoin de revenir là où on en était, on fait au choix Resume (pour relancer la ligne qui a planté) ou Resume Next (reprendre l'exécution de la ligne d'après).
 
c'est clair que le coup du Goto, ça n'est pas élégant du tout, mais c'est VB, et tant qu'à faire, je préfère exploiter à fond les spécificités du langage puisque le client veut pas qu'on code en autre chose (sauf ptet Cobol mais jcrois qu'ils vont dire non   )  Attention j'ai pas dit que je foutais des Goto partout  Uniquement dans l'error handling

Quand on fait du VB et qu'on veut éviter les "défauts", on met des Goto, mais juste où il faut.  
 
Ceux qui critiquent ont qu'à dire comment remplacer ces "sacs de noeuds".

hehe
 
note que je connais d'autres genres de programmation qu'on pourrait appliquer dans d'autres langages, genre la programmation dite spaghetti ou la programmation sapin de noël