OVH Cloud OVH Cloud

probleme de code

13 réponses
Avatar
domi
bonjour a tous

ce code me serts pour copier le contenu d'un champ ole
dans un repertoire en format WORD
tout se passe bien j'ai bien mon fichier WORD
mais apres avoir exécute l'action
Dand le gestionnaire des taches dans onglet Applications
Microsoft Word ne s'y trouve pas
mais dans l'onglet Processus WINWORD.EXE
lui est encore présent
que faire avec ce code pour empecher cela?


---------------------------------code a modifier
Private Sub Commande67_Click()
aa.Object.Application.Options.BackgroundSave = True
aa.Object.Application.Options.AllowFastSave = True
aa.Object.SaveAs "C:\PDF\TEMP.doc"
end sub
----------------------------------------------------

3 réponses

1 2
Avatar
YannX
Excuse moi d'avoir dériver (et fait dériver)


"domi" a écrit dans le message de
news:41a9fa1f$0$25067$
c'est bien beau tout ça

mais la solution au probleme c'est quoi??????



dans le bout de code que tu fournis,
tu utilise un objet "aa."

Où l'as-tu créé, cet objet ?
dans un Form_Load ?
alors je pense qu'en ecrivant les
aa.Quit
Set aa = nothing
dans le Form_Close ou Form_...
cela devrait le faire !

Et je ne sais meme plus dans quel fil ce problème a été abordé recement.

YannX

PS Le hic, c'est que les "titres-objets" des messages sont souvent
mal complétés, -oserai-je dire par les répondeurs/par l'emetteur c'est
normal-
et donc qu'il est bcp plus difficile de retrouver un Post associé...

"Jean-Marc" a écrit dans le message de


news:
41a9d2dc$0$5387$
> "YannX" a écrit dans le message de
> news:%
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
> une erreur, ce qui est possible, le programme doit dans tous les cas
> récupérer l'erreur proprement, et remonter les appels. Même une erreur
> non prévue doit être récupérée, faire l'objet d'un message adéquat,
> genre: Erreur inattendue (err N°: X) rencontrée dans le Module
> "Nom_du_module", Fonction "Nom_de_la_fonction".
>
> Si la nature de l'erreur est telle qu'elle nécessite un arrêt du
> programme, cet arrêt doit toujours se faire de manière contrôlée,
> justement pour gérer ce genre de cas. On prévoit alors une procédure
> dite "Disaster recovery" qui se charge de ce genre de choses.
>
> Ca suppose évidemment d'avoir fait les choses proprement, c'est à dire
> de garder quelque part en mémoire ou sur disque l'état des choses qu'on
> a lancé/ouvert/alloué pour permettre le cas échéant de retrouver ses
> petits et de faire le ménage le plus proprement possible. Ca ne résoud
> peut être pas tout (genre une panne hardware) mais ça évite quand même
> plein d'ennuis.
>
> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. Ceci expliquant
> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
> erreurs.
>
> --
> Jean-marc
> "There are only 10 kind of people
> those who understand binary and those who don't."
>
>




Avatar
Jean-Marc
Re,

il y a plein de façons de faire, ça dépend du code. En pratique:
- des On error Goto dans TOUTES les fonctions, procédures
- des variables globales uniquement dans les modules
- une gestion d'erreur qui ne laisse rien passer

Dans le cas présent, quelque chose comme ça:
Volontairement *****très***** simplifié, mais qui fonctionne:

Option Explicit

Const P_MODULE_NAME = "FORM1"

Private Sub Command1_Click()
Dim aa As Word.Application
Dim n As Integer
Dim s As String

On Error GoTo abnormal_end

Set aa = New Word.Application
aa.Documents.Open ("c:truc.doc")
'
' ici je fais un truc qui crashe l'IDE
'
n = n / 0

aa.Documents.Close
aa.Quit
Set aa = Nothing
normal_end:
MsgBox "stop ok"
Exit Sub
abnormal_end:
MsgBox "nous avons une erreur."
Select Case Err.Number
Case 1
' code pour cette erreur
Case 2
' code pour celle ci

Case Else
' DISASTER
' l'erreur est si grave qu'il faut quitter
' mais pas comme un goret
s = "Unexpected error in module " & P_MODULE_NAME & "." & vbCrLf
s = s & "in function Command1_click" & vbCrLf
s = s & "Error code: " & Err.Number & " (" & Err.Description &
")" & vbCrLf
aa.Documents.Close
aa.Quit
Set aa = Nothing
MsgBox s
MsgBox "Je quitte"
Unload Me
End Select
End Sub


--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"YannX" a écrit dans le message de
news:ugoG%
Merci pour le rappel,
mais de facon opérationnelle ?

(voir ci-dessous)
Y
"Jean-Marc" a écrit dans le message de
news:41a9d2dc$0$5387$
> "YannX" a écrit dans le message de
> news:%
> > Bnjr,
> >
> > [HS = idée dérivée de ce fil ]
> > Y a-t-il une solution efficace pour fermer
> > automatiquement une application dérivée
> > (typiquement Excel ou Word), lancée
> > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> >
> > Evidement le programme utilisateur s'était planté........
> > Donc pour revenir a une situation propre....
>
> Hello,
>
> Le programme utilisateur ne **doit** PAS se planter. Si il rencontre
..........Vrai, mais nous savons que c'est faux .... ;-)

> récupérer l'erreur proprement, et remonter les appels. Même une erreur
C++ propose depuis longtemps un mécanisme
try .......catch des exceptions typées !
Comment le faire en Basic

> Tout cela s'applique aussi bien pour un programme en cours de
> developpement, donc s'exécutant depuis l'IDE que pour un programme
> terminé, qui s'exécute tout seul, hors de l'IDE. .....
Mais quand je suis en train de tester, et de corriger
(sans réflechir, diraient les anciens de la comilation a cartes
perforées)
J'ai pas envie de perdre mon temps a verifier ma barre de taches..

Voila pourquoi, je ne sais pas, peut-etre qu'un simple
App_X.Quit
Set App_X = Nothing dans le Form_close principal
serait-il exécuté après plantage du programme dans l'IDE
lorsque je referme l'exécution ?

> pourquoi le code doit inclure même dans une phase très précoce tout ce
> qu'il faut pour la gestion propre (et si possible centralisée) des
erreurs.

Des préconisations pour le centraliser (plus que le MsgBox de rigueur...)


?

Y




Avatar
YannX
Bonsoir,

et merci ; je garde dans un coin de ma p'tite tete
Y
"Jean-Marc" a écrit dans le message de
news:41aa33fc$0$25054$
Re,

il y a plein de façons de faire, ça dépend du code. En pratique:
- des On error Goto dans TOUTES les fonctions, procédures
- des variables globales uniquement dans les modules
- une gestion d'erreur qui ne laisse rien passer

Dans le cas présent, quelque chose comme ça:
Volontairement *****très***** simplifié, mais qui fonctionne:

Option Explicit

Const P_MODULE_NAME = "FORM1"

Private Sub Command1_Click()
Dim aa As Word.Application
Dim n As Integer
Dim s As String

On Error GoTo abnormal_end

Set aa = New Word.Application
aa.Documents.Open ("c:truc.doc")
'
' ici je fais un truc qui crashe l'IDE
'
n = n / 0

aa.Documents.Close
aa.Quit
Set aa = Nothing
normal_end:
MsgBox "stop ok"
Exit Sub
abnormal_end:
MsgBox "nous avons une erreur."
Select Case Err.Number
Case 1
' code pour cette erreur
Case 2
' code pour celle ci

Case Else
' DISASTER
' l'erreur est si grave qu'il faut quitter
' mais pas comme un goret
s = "Unexpected error in module " & P_MODULE_NAME & "." &


vbCrLf
s = s & "in function Command1_click" & vbCrLf
s = s & "Error code: " & Err.Number & " (" & Err.Description &
")" & vbCrLf
aa.Documents.Close
aa.Quit
Set aa = Nothing
MsgBox s
MsgBox "Je quitte"
Unload Me
End Select
End Sub


--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"YannX" a écrit dans le message de
news:ugoG%
> Merci pour le rappel,
> mais de facon opérationnelle ?
>
> (voir ci-dessous)
> Y
> "Jean-Marc" a écrit dans le message de
> news:41a9d2dc$0$5387$
> > "YannX" a écrit dans le message de
> > news:%
> > > Bnjr,
> > >
> > > [HS = idée dérivée de ce fil ]
> > > Y a-t-il une solution efficace pour fermer
> > > automatiquement une application dérivée
> > > (typiquement Excel ou Word), lancée
> > > à partir de VB-IDE, qd on ferme l'interpretation du pgm !
> > >
> > > Evidement le programme utilisateur s'était planté........
> > > Donc pour revenir a une situation propre....
> >
> > Hello,
> >
> > Le programme utilisateur ne **doit** PAS se planter. Si il


rencontre
> ..........Vrai, mais nous savons que c'est faux .... ;-)
>
> > récupérer l'erreur proprement, et remonter les appels. Même une


erreur
> C++ propose depuis longtemps un mécanisme
> try .......catch des exceptions typées !
> Comment le faire en Basic
>
> > Tout cela s'applique aussi bien pour un programme en cours


de
> > developpement, donc s'exécutant depuis l'IDE que pour un


programme
> > terminé, qui s'exécute tout seul, hors de l'IDE. .....
> Mais quand je suis en train de tester, et de corriger
> (sans réflechir, diraient les anciens de la comilation a cartes
> perforées)
> J'ai pas envie de perdre mon temps a verifier ma barre de taches..
>
> Voila pourquoi, je ne sais pas, peut-etre qu'un simple
> App_X.Quit
> Set App_X = Nothing dans le Form_close principal
> serait-il exécuté après plantage du programme dans l'IDE
> lorsque je referme l'exécution ?
>
> > pourquoi le code doit inclure même dans une phase très précoce tout


ce
> > qu'il faut pour la gestion propre (et si possible centralisée)


des
> erreurs.
>
> Des préconisations pour le centraliser (plus que le MsgBox de


rigueur...)
?
>
> Y
>
>




1 2