Excel macro envoi fichier en cours via outlook

Je suis un super novice en macro, mais je commence à les exploiter pour le boulot et je n'imaginais pas les possibilités qu'elles offrent..

Bref je cherche à ajouter une macro qui enverrait le classeur actif par mail, toujours à la même adresse et toujours avec le même objet de message.
Mais qui testerai d'abord qu'outlook est ouvert. Mais j'aimerai que si outlook est fermé une message-box m'informe et stop la macro en cours.
Et enfin si outlook est ouvertil faut que le fichier soit enregistré sur la première feuille du classeur avant d’être envoyer.

J'ai trouvé plusieurs message à se sujet, et j'arrive à faire chaque fonction indépendamment mais je n'arrive pas à les lier entre elles.

Merci d'avance pour votre aide...

A titre informatif voila où j'en suis

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Sub EnvoiMail()   Set appli_outlook = Outlook.Application   If appli_outlook.ActiveWindow Is Nothing Then   MsgBox "erreur envoi e_mail car outlook non chargé"   End If     Sheets("Commande ").Select Range("A1").Select ActiveWorkbook.Save     Workbooks("Commande.xlsm").SendMail Recipients:="adress@mail.net", _ Subject:="Test envoi classeur", _     End Sub

---

bonjour,

j'ai juste une question avant de te répondre. Pourquoi stopper la macro si outlook n'est pas démarré?

C'est pas idiot ce que tu dis ;)

Je veux que ça soit simple et facile, pour que n'importe qui puisse le faire sans se poser de question.

Dans l'idéal j'aurai même aimé qu'outlook s'ouvre s'il est fermé, mais ça je n'y arrive pas.
Tu as raison la macro peux ne pas s'interrompre, puisque une fois outlook ouvert le fichier partira.

Bonjour,

à ce stade, quels sont les problèmes non résolus à ton sujet ?


Concernant la détection/ouverture d'une instance Outlook, regarde du côté de la fonction CreateObject dans l'aide :f1:

alors fait comme ça si cela concerne juste un mail
ne t'inquietes pas de savoir si outlook est ouvert ou pas et lance juste une session que tu refermera une fois terminé

par exemple :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

Sub envoi_mail() Dim oApp As New Outlook.Application Dim oMailItem As Outlook.MailItem   Set oMailItem = oApp.CreateItem(olMailItem)   With oMailItem .To = "foo@mail.com" .Attachments.Add ActiveWorkbook.FullName .Send End With   Set oMailItem = Nothing Set oApp = Nothing End Sub

---

edit: ne pas oublier d'indiquer la référence à outlook dans les options de l'EDI via Tools=>Références ==>> cocher Microsoft Outlook xx Object Library

Bonjour mayekeul,

pourquoi ne pas proposer une liaison tardive en utilisant une variable Object à instancier durant l'éxecution ?

ça évite de cocher la référence en question.
dans son contexte (aller au plus simple pour ses utilisateurs), ça serait stratégique non ?

mais tu as peut être une raison que je ne vois pas en l'état :aie:

bonjour joe.levrai,

c'est simplement didactique. En faisant comme cela, il aura accès a l'intellisense de VBA.

Mais effectivement une meilleure pratique serait de tester si l'objet à instancier existe avant.
Et évidemment ouvrir l'instance au bon moment.

;)

Merci du retour,

donc c'est du pratico-pratique pour lui (développeur) : récupérer le modèle objet Outlook :P

j'approuve, il débute sur l'automation Outlook et n'a probablement jamais écrit de procédures VBA Outlook

alolaterre, notre charabia des deux derniers messages sera important pour ton développement futur, et également quand tu seras amené à distribuer ton code à d'autres utilisateurs.

mayekeul t'a proposé un code qui fait appel à des liaisons précoces : tu es obligé de charger la référence qu'il t'as indiqué, afin que ton VBA Excel récupère la bibliothèque des objets Outlook

l'avantage, c'est que quand tu vas écrire ton code, tu vas conserver la saisie intuitive de tes objets/méthodes/propriétés (le petit menu déroulant quand par exemple tu écris Range("A1"). // donc après avoir écrit le "point") ==> c'est ça l'intellisense de VBA

l'inconvénient, c'est que si la référence n'est pas cochée, ton programme va planter, ton VBA Excel ne reconnaissant pas les variables que tu utilises (Dim oApp As New Outlook.Application par exemple).
Aussi, obligera tout tes futurs utilisateurs à cocher cette référence.


Pour palier à ça, on peut travailler en liaison tardive : au lieu de déclarer les types de variables adéquats (New Outlook.Application), on les déclare en Object (Dim oApp As Object)
Et c'est dans l'exécution du code qu'on effectue la liaison entre cette Object, et ce qu'il représente exactement... d'où l'appelation "liaison tardive"

Exemple de liaison tardive :

Code:

---

1 2 3 4 5 6 7

' Déclaration Dim OutApp As Object ' l'application Dim OutMail As Object ' un objet MailItem   ' Instanciation Set OutApp = CreateObject("Outlook.Application") ' l'application Set OutMail = OutApp.CreateItem(0) ' l'objet "Mail"

---

A toi maintenant de choisir ta bonne stratégie ... sachant qu'il est également possible de développer ta procédure en liaison précoce (pour t'aider grâce à l'IntelliSense)
Et quand ta procédure est stable, tu modifies simplement tes déclarations et instanciations pour passer en liaison tardive ==> tes utilisateurs n'ont pas besoin de cocher la référence "qui va bien"

Pour approfondir : http://mhubiche.developpez.com/vba/f...endre/binding/ et aussi les cours et tutoriels pour apprendre Excel : https://excel.developpez.com/cours/

Citation:

---

Aussi, obligera tout tes futurs utilisateurs à cocher cette référence.

---

en est-tu bien sur???
la liaison est "liées" a son fichier. Si il distribue le fichier, ce la fonctionne... sauf si... le nouvel utilisateur ne possède pas la même librairie référencée.

Salut, pourquoi ne pas utiliser CDO ( sauf si proxy ) ?

J'en suis sûr, mais tu soulèves le raccourci que j'ai improprement utilisé dans mon message :king: ...

tout est dans ton "Sauf si" ... avec les jolies [MANQUANT] qu'on adore dans les références :aie:

L'utilisateur est obligé d'activer la référence liée à sa librairie ... si elle est déjà active (le mot active est au sens littéral) car librairie idem, c'est tant mieux

si, on pourrait... mais l'utilité d'une telle chose????

Citation:

---

Envoyé par joe.levrai

J'en suis sûr, mais tu soulèves le raccourci que j'ai improprement utilisé dans mon message :king: ...

tout est dans ton "Sauf si" ... avec les jolies [MANQUANT] qu'on adore dans les références :aie:

L'utilisateur est obligé d'activer la référence liée à sa librairie ... si elle est déjà active (le mot active est au sens littéral) car librairie idem, c'est tant mieux

---

je suis d'accord bien sur mais... (j'aime bien les petit points) dans l'énoncé ici présent, rien n'indique que son fichier va faire le tour du monde... ;)

Citation:

---

Envoyé par alolaterre

Je veux que ça soit simple et facile, pour que n'importe qui puisse le faire sans se poser de question.

---

En fait c'est cette phrase qui m'a poussé à aborder cette problématique de distribution de la procédure.

Quoi qu'il en soit, je pense que notre échange lui sera utile pour son perfectionnement :plusser:

Non mais, je taquine un peu.

Il doit retenir une chose de ces deux méthodes, et c'est ou je vais corriger ce que tu à écrit plus haut, il faut -dans "ma" méthode- s'assurer que le destinataires possède la même librairie. Dans le cas contraire, l'autre est plus adaptée.

:plusser::plusser:

:)

Merci à tous pour cette éclairage (pas toujours clair pour moi mais j'en comprends les grandes lignes)

J'ai plusieurs point de ventes et je dois dupliquer ce fichier, donc effectivement je préfère utiliser la liaison tardive, pour n'avoir qu'a envoyer le fichier sans passer par des paramétrages des différentes librairies de chaque poste.

Mon problème actuel est que le code que je vous ai envoyé au début du post ne fonctionne pas (c'est un copié/collé de différente macro trouvées et je n'arrive pas à les "additionner" entre elles... ). J'aimerais que vous me donniez votre avis
Je ne suis pas assez perfectionné pour comprendre chaque terme.

Est il possible d'envoyer le classeur actif sans passer par outlook
Jai supprimer les sécurités de ma messagerie mais malgré ca il me demande d'autoriser l'envoi

Bonjour,
comme dis plus haut :

Citation:

---

Envoyé par kiki29

Salut, pourquoi ne pas utiliser CDO ( sauf si proxy ) ?

---

Mais il faut alors posséder les information de ton serveur

Bonjour Mayekeul,
J'ai bien vu, et j'ai cherché à droite à gauche, mais ca reste du charabia :?
C'est quoi les proxys?

Et comment paramétrer l'envoi, j'ai vu qu'il fallait rentrer le smtp, les codes de messagerie, etc, dans le code. Je suis hebergé par OVH et mes adresse mail doivent apparemment être paramétrées en pop3...

Ca serai sympa de me guider parce que je suis vraiment à la masse...

si tu ne passe pas par un réseau d'entreprise, ne t'en soucie pas pour l'instant.

Pop3, c'est pour la réception

ici tu trouvera ton bonheur je pense

guide ovh - ConfigurationEmail

voici une petite fonction qui pourra t'inspirer :

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

Public Function OvhMail(strTo As String, strSubject As String, strContent As String) As Boolean Dim objEmail As Object   On Error GoTo errLabel   Set objEmail = CreateObject("CDO.Message")   With objEmail.Configuration.Fields .Item(CdoConfiguration.cdoSendUsingMethod) = 2 .Item(CdoConfiguration.cdoSMTPAuthenticate) = 1 .Item(CdoConfiguration.cdoSendUserName) = "TonAdresse@ovh.xxx" .Item(CdoConfiguration.cdoSendPassword) = "Ton Password OVH" .Item(CdoConfiguration.cdoSMTPServer) = "ns0.ovh.net" .Item(CdoConfiguration.cdoSMTPServerPort) = 587 .Update End With   With objEmail .To = strTo .Subject = strSubject .textbody = strContent .AddAttachment ThisWorkbook.FullName .Send OvhMail = True End With   Set objEmail = Nothing   Exit Function   errLabel: MsgBox Err.Description OvhMail = False Set objEmail = Nothing   End Function

---

Merci c'est parfait, votre aide ma été très précieuse.

Je vais exploiter ca.