code partage qui a opere differemment sur un poste

Version imprimable

bonjour , jai un code qui permet de sauvegarder un pdf de document via un bouton.
le probleme est le suivant sur un des postes au lieu d faire un sauvegarde comme les auter il lance une impression de 10 copies du document ... etrange
est ce que quelqu un saurait pourquoi?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
Private Sub CommandButton2_Click()
 
 
 
Dim nom As String
 
nom = InputBox("enter the name of the file:")
 
If nom = "" Then
ThisWorkbook.Close False
 
 Else: ThisWorkbook.SaveAs Filename:="\\smb2lonib\" & nom & ".xls"
 
 
 
Dim i As Integer
    Do
        Err.Clear
        i = i + 1
        On Error Resume Next
        Application.ActivePrinter = "PDFCreator on Ne0" & i & ":"
        ActiveWindow.SelectedSheets.PrintOut Copies:=1
    Loop While Err.Number <> 0 And i < 10
    On Error GoTo 0
 
 
 End If
 
 
End Sub

27/10/2008, 18h24
ucfoutu

Bonjour,

Ah, les joies de On Error Resume Next ....

Au bout d'un moment ===>> imprimante par défaut... 10 fois (puisque 10 fois allons-y même si erreur...)
27/10/2008, 18h34
will Igetit

reponse non comprise

ce code est cense lancer pdf creator pour enregistrer le document . En aucun cas l'imprimer . je n'ai d'ailleurs pas de probleme sur les autres postes..
27/10/2008, 18h40
casavba

PDF Creator est Bien installé dans les autres postes ??
27/10/2008, 18h46
ucfoutu

Citation:

Envoyé par will Igetit

ce code est cense lancer pdf creator pour enregistrer le document . En aucun cas l'imprimer . je n'ai d'ailleurs pas de probleme sur les autres postes..

Ah ...
et que fait ceci :

Code:

ActiveWindow.SelectedSheets.PrintOut Copies:=1

lorsque "ton" imprimante n'étant pas trouvée, le On Error Resume Next ignore cet échec, sinon exécuter sur l'imprimante par défaut ? ;)

Un exemple (je ne veux pas écrire ton code) pour alimenter ta réflexion :

3 boutons de commande.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
Private Sub Command1_Click()
  Dim i As Integer
    Do
        Err.Clear
        i = i + 1
        On Error Resume Next
        toto = 1 / 0 'donc erreur générée ici
        MsgBox "coucou " & i & " fois l'exécutuin en dépit de l'erreur"
    Loop While Err.Number <> 0 And i < 10
    On Error GoTo 0
   MsgBox "j'ai essayé " & i & " fois et ai lancé autant de fois la msgbix indûment"
End Sub
 
Private Sub Command2_Click()
  Dim i As Integer
    Do
        Err.Clear
        i = i + 1
        On Error Resume Next
        toto = 1 / 0 'donc erreur générée ici
        If Err = 0 Then
          MsgBox "coucou " & i & " fois"
          Exit Do
        End If
    Loop While i < 10
   MsgBox "j'ai essayé " & i & " fois mais n'ai pour autant jamais lancé la msgbox"
End Sub
 
Private Sub Command3_Click()
  Dim i As Integer
    Do
        Err.Clear
        i = i + 1
        On Error Resume Next
        toto = 1 / 2 'donc pas d'erreur provoquée
        If Err = 0 Then
          MsgBox "coucou " & i & " fois"
          Exit Do
        End If
    Loop While i < 10
   MsgBox "j'ai essayé " & i & " fois mais n'ai pour autant jamais lancé la msgbox 10 fois !"
End Sub

compare les 3 effets... analyse, comprends et sers-t-en

28/10/2008, 10h07
decondelite

Juste par rapport à ce que tu as écrit ucfoutu: ne serait-il pas plus pertinent de réinitialiser le code d'erreur à l'intérieur du test de code d'erreur avec un else?

Pour ma part je fais systématiquement le err.clear dans cette condition, car il est sémantiquement plus logique de dire au programme qu'il n'y a plus d'erreur puisqu'on vient de la traiter.

Après, chacun sa façon de faire, mais pour ma part je privilégie la sémantique à la simplicité et aux "trucs bricolés".
28/10/2008, 12h11
ucfoutu

Non, decondelite, non... ce n'est pas un "truc bricolé", mais une méthode très fortement recommandée lorsque l'on utilise On Error Resume Next (mettre cette instruction dans une procédure distincte met à l'abri de sérieux aléas possibles...). Err.Clear ou non, en effet, ton On Error Resume Next continuera à s'appliquer dans la procédure dans laquelle il se trouve (jusqu'à la fin de la procédure) et, du coup, ignorera toute nouvelle erreur éventuelle... avec les risques induits pour ton application...
C'est donc, de très loiin, tout sauf un "truc bricolé :lol:

EDIT : j'ajouterais ceci, et ce, sans la mondre hésitation :
1) faire toujours tout son possible pour ne pas utiliser On Error Resume Next. Ne l'utiliser vraiment que très exceptionnellement ...
2) faire encore plus attention au faux-ami qu'est On Error Goto 0 (on ne compte plus les "condoléances" ...
3) dans le cas présent (et puisque l'envoi vers un pdf était prévu) : c'est à l'ouverture même de l'appli, que l'on pouvait vérifier une existence ===>> mettre dans une variable booléenne ===>> se servir de cette variable ensuite et, au passage, dénoncer l'absence dès le lancement de l'appli ...
L'inventaire serait long (trop) ... et je ne compte pas le faire ici ...
(question de philosophie et de réflexion)
28/10/2008, 14h52
decondelite

J'étais déjà au courant de tout ça.

Après, chacun son style, et il s'avère que pour ma part:
-je ne "privilégie" pas On Error Goto ou On Error Resume Next: j'utilise l'un ou l'autre selon la façon dont je souhaite gérer l'erreur. A la base, c'est bien pour ça qu'il existe les deux: pourquoi se priver d'un certain confort et surtout d'une certaine sémantique.
-On Error Goto 0 je ne l'utilise que pour On Error Resume Next, et ce systématiquement juste après le bout de code de gestion. Je ne suis donc pas du genre à laisser traîner une gestion d'erreur qui ne me sert que ponctuellement
-Err.Clear ne devrait être utilisé que s'il y a eu erreur, c'est inutile (et donc non optimisé) de le faire systématiquement
-si le code à exécuter est exempt d'erreurs, il n'y a pas de raison d'utiliser de procédures appelées (ce qui là encore est non optimisé). Donc je ne m'en sers pas. :mrgreen: Et même si mon code bogue, je saurai déboguer en 2 temps 3 mouvements j'ai plus d'un tour dans mon sac.
-je n'adhère pas toujours à tous les préjugés qu'il peut exister (comme c'est le cas ici), et c'est bien pour ça que j'ai ma façon de faire et surtout de voir les choses.
-quand j'ai le choix entre gestion d'erreur et petit script, je privilégie le plus performant et le plus facile à coder: je ne privilégie pas systématiquement l'une ou l'autre méthode, mais seulement celle qui m'arrange.

1) Déjà répondu :P
2) Peux-tu développer stp, car pour ma part je ne me suis jamais fait trahir.
3) Tout dépend de ce qu'il veut faire.

Bref, pour résumer, je dirais que tout le monde ne cherche pas la même chose de son code, et tout le monde ne conseille pas les mêmes choses. ;)

Re,

Je ne veux pas argumenter...
Tu ne t'es pas encore fait trahir ?
Celà viendra un jour ou l'autre (je garde donc ta certitude en mémoire)...
Bye :lol:

Edit :
Illustration d'un exemple (parmi des milliers) , quand même :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 Private Sub Command1_Click() On Error Resume Next toto = 2 / 0 MsgBox toto If Err Then MsgBox "tu as eu une erreur sautée par Inb Error Resume Next" Err.Clear MsgBox "tu as eu beau faire ton Err.clear,tu ne verras pas l'erreur suivante" toto = 3 / 0 MsgBox toto End Sub Private Sub Command2_Click() toto = tutu(2, 0) MsgBox toto If Err Then MsgBox "tu as eu une erreur sautée par on Error Resume Next" Err.Clear MsgBox "tu verras l'erreur suivante" toto = 3 / 0 MsgBox toto End Sub Private Function tutu(nb1 As Integer, nb2 As Integer) As Double On Error Resume Next tutu = nb1 / nb2 End Function
Je te laisse maintenant deviner ce qui arrive fréquemment lorsque tu fais comme en Command1 jusu'à If Err, puis, des mois plus tard (en maintenance) ajoutes (tou opu un autre) ce qui vient après, sans tout reconsidérer.

Mais j'ai mis tout celà en mémoire et te guette ... (le jour viendra, c'est sûr, à moins que tu ne changes ton fusil d'épaule)

Je tiens à signaler que On Error Goto 0 annule la gestion d'erreur et, de plus, provoque un Err.Clear.

Pour ma part, voici comment je traite les erreurs:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Sub test()
  Dim iErr As Long
  Dim a As Integer
  On Error Resume Next
  ' Code risquant de provoquer l'erreur
  a = 1 / 0
  iErr = Err.Number  ' Je sauvegarde le numéro d'erreur
  Debug.Print Err.Number  ' On peut voir, ici, le numéro d'erreur
  On Error GoTo 0
  Debug.Print Err.Number  ' On voit que Err.Number a été remis à zéro
  If Not iErr = 0 Then
    ' Gestion proprement dite
  End If
End Sub

Citation:

Envoyé par ucfoutu

Re,

Je ne veux pas argumenter...
Tu ne t'es pas encore fait trahir ?
Celà viendra un jour ou l'autre (je garde donc ta certitude en mémoire)...
Bye :lol:

Edit :
Illustration d'un exemple (parmi des milliers) , quand même :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Private Sub Command1_Click()
  On Error Resume Next
    toto = 2 / 0
    MsgBox toto
    If Err Then MsgBox "tu as eu une erreur sautée par Inb Error Resume Next"
  Err.Clear
   MsgBox "tu as eu beau faire ton Err.clear,tu ne verras pas l'erreur suivante"
   toto = 3 / 0
   MsgBox toto
End Sub
 
Private Sub Command2_Click()
    toto = tutu(2, 0)
    MsgBox toto
    If Err Then MsgBox "tu as eu une erreur sautée par on Error Resume Next"
    Err.Clear
    MsgBox "tu  verras l'erreur suivante"
    toto = 3 / 0
    MsgBox toto
End Sub
 
Private Function tutu(nb1 As Integer, nb2 As Integer) As Double
  On Error Resume Next
    tutu = nb1 / nb2
End Function

Je te laisse maintenant deviner ce qui arrive fréquemment lorsque tu fais comme en Command1 jusu'à If Err, puis, des mois plus tard (en maintenance) ajoutes (tou opu un autre) ce qui vient après, sans tout reconsidérer.

Mais j'ai mis tout celà en mémoire et te guette ... (le jour viendra, c'est sûr, à moins que tu ne changes ton fusil d'épaule)

Moi je fais systématiquement comme ça:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Private Sub Command1_Click()
    On Error Resume Next
    toto = 2 / 0
    ' Je ne mets JAMAIS de ligne entre la ligne potentiellement génératrice
    ' d'erreur et sa gestion
    If Err Then
        MsgBox "Je n'ai eu aucune erreur sautée par On Error Resume Next :P"
        ' Je ne réinitialise QUE si j'ai eu une erreur, et pas systématiquement
        Err.Clear
    Else
        MsgBox toto
        ' Je traite TOUJOURS le code dépendant seulement en cas de non-erreur
    End If
    ' Je mets TOUJOURS On Error Goto 0 juste après le End If
    On Error Goto 0
    MsgBox "J'ai fait On Error Goto 0, j'aurai bien mon programme qui va _
planter juste après"
    toto = 3 / 0
    MsgBox toto
End Sub
 
Private Sub Command2_Click()
    toto = tutu(2, 0)
    If Err Then
        MsgBox "Faut que je refasse mon speech?"
        Err.Clear
    Else
        MsgBox toto
    End If
    On Error Goto 0
    MsgBox "tu  verras l'erreur suivante"
    toto = 3 / 0
    MsgBox toto
End Sub
 
Private Function tutu(nb1 As Integer, nb2 As Integer) As Double
    On Error Resume Next
    tutu = nb1 / nb2
    ' Ici moi non plus je ne mets rien, car aucun nombre ne peut être réservé
    ' pour une erreur, mais si cela est possible je m'arrange TOUJOURS
    ' à renvoyer une valeur issue d'une routine de gestion d'erreur
    ' avec un On Error Goto erreur
End Function

Donc, explique moi quel est le problème dans ma manière de faire, car là sans tester je suis sûr à 100% du comportement de ce que je viens d'écrire.

un grand merci

cette discussion a devie sur laa gestion d'erreur et cela ne pouvait pas mieux tombe.
j'avais d'ailleurs dans une conversation passe demancde des questions et n'avaiten pas eu ces reponses
cette une des choses que je comprend tres mal et vous avez eclairci ce point pour moi. pour ma part j'ai trouve un astuce pour ccontourner mon probleme ( qu'un collegue m'a passe pour tout vous dire) quee je vous laisse
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 Dim WshNetwork As Object Dim oPrinters As Variant Dim strPrinterList As String Dim strPDFPrinter As String Dim i As Integer Set WshNetwork = CreateObject("WScript.Network") Set oPrinters = WshNetwork.EnumPrinterConnections For i = 0 To oPrinters.Count - 1 Step 2 If Left(oPrinters.Item(i + 1), 3) = "PDF" Then strPDFPrinter = oPrinters.Item(i + 1) & " on " & oPrinters.Item(i) Next 'i Set WshNetwork = Nothing

29/10/2008, 11h09
ucfoutu

Je te félicite ...

Et donc : aucun traitement d'erreur ..;) (ce qu'il convient de faire chaque fois qu'in le peut, comme dit également plus haut ...)

C'est d'ailleurs ce que voulait dire l'un de mes messages précédents, à quelques petits détails prés, qui sont les suivants :
1) faire cette vérification d'existence dès l'ouverture de ton appli et mettre ce résultat dans une variable booléenne.
Ce qui t'évitera de recommencer la vérification d'existence à chaque envoi vers pdf (il te suffira de regarder si ta variable est à True ou à False)
2) ne pas utiliser FSO (qui alourdit inutilement et te rend dépendant) mais directement une fonction de l'API de Windows ...
Tu en as deux possibles à ta disposition :
- EnumPrinters de la librairie winspool.drv ===>> et tu vérifies que ton impri est dans la liste ==>> si oui ===>> ta variable à True
- GetPrinter, toujours de la librairie winspool.drv, et tu vérifies que la valeur retournée est différente de 0 pour l'imprimante concernée ===>> si différente de 0 ===>> ta variable à True.

Amitiés.

Edit :
J'ajoute ceci, si tu veux parfaire ton travail, toujours sans gestion d'erreur :

Il sera bon de vérifier certains points qui pourraient générer des surprises dans certains cas de figure :
- vérifier la queue d'impression :
Utilisation des fonctions suivantes (toujours de Winspool.drv )
EnumJobs, OpenPrinter , ClosePrinter
- vérifier le statut (la fonction GetPrinter visée plus haut te le permet) de sorte à s'assurer qu'il est "bon" et que ton "imprimante" est prête

Ces deux dernières vérifications, contrairement à la première, doivent, elles, être faites juste avant le lancement.

Ce sont ces "petites choses" qui font souvent la différence entre une appli et l'autre ;)