De: "Laurent Longre" Objet: Re: Interpréter un code de retour d'un programme externe à Excel Date : mardi 20 juin 2000 01:08 Une autre piste possible : passer par les variables d'environnement. Quelque-chose comme : Private Declare Function GetEnvironmentVariableA Lib "Kernel32" _ (ByVal lpName As String, ByVal lpBuffer As String, _ ByVal nSize As Long) As Long Private Declare Function setEnvironmentVariableA Lib "Kernel32" _ (ByVal lpName As String, ByVal lpValue As Any) As Long Sub Test() Dim RetCode As String * 1 Shell "..." ' exécution de ton programme DOS Do: Loop Until GetEnvironmentVariableA("RetCode", RetCode, 2) If CInt(RetCode) Then MsgBox "Aucune erreur." Else MsgBox "Erreur." setEnvironmentVariableA "RetCode", 0& ' destruction de la variable "retcode" End Sub A la fin de ton programme C, il faudrait que tu crés la variable d'environnement "retcode" en lui affectant par exemple "1" en cas de succès et "0" en cas d'erreur -si ma mémoire est bonne, il faut faire par exemple un system("set recode=1"); dans les programmes C sous DOS. Tant que la variable d'environnement "RetCode" n'a pas été définie, GetEnvironmentVariable renvoie 0 et le Do-Loop boucle en attendant la fin du programme. Quant celui-ci est terminé, la variable RetCode récupère le contenu de la variable d'environnement et sait par là si le programme s'est correctement exécuté ou non. Seulement, j'ai peur qu'une variable créé de cette manière par un programme DOS n'existe que dans la session DOS ouverte, et ne soit pas accessible à partir de Windows... Autrement, il y a toujours la solution "bourrin" de l'écriture du résultat dans un fichier temporaire... Le plus simple, ce serait peut-être que tu adaptes et recompiles ton programme avec un compilateur Windows. Déjà, en l'exécutant non pas avec Shell, mais de la même manière qu'une procédure avec l'aide d'un 'Declare Sub', le problème de synchronisation avec la macro VBA serait d'emblé réglé. Sous DOS, ça complique terriblement les choses... Laurent Laurent Mortézai a écrit : > > (je re-soumets ce message et le complète un peu car il figure trop loin > dans la liste. Désolé si je radote...) > > Merci à Frédéric et Laurent (Longre -je précise- car il commence à y en > avoir beaucoup de Laurent....) > > Merci à vos réponses récentes sur la manière d'attendre après > l'exécution d'un programme (cf. ven 12:43). Très intéressant, je > conserve précieusement le tout. Par contre, ça ne répond pas totalement > à toutes mes attentes: j'aimerais que le programme appelé transmette un > code de retour. C'est pour ça que j'avais pensé au presse-papiers. Bref, > avec vos méthodes, je sais que le programme a terminé (c'est déjà > énorme), mais je ne sais pas s'il a correctement exécuté. Plus > concrètement: j'appelle un programme écrit en C qui effectue un > transfert FTP. Je peux m'arranger pour que le programme en C retourne > dans le presse-papiers un code attestant le succès ou les codes > d'erreurs rencontrés pendant le transfert, je l'ai testé et ça marche! > > Seul inconvénient, je dois coller la valeur dans une cellule (je dois > déprotéger, décacher une feuille pour ce besoin, coller, puis recacher > et reprotéger...). Je me demande s'il serait possible de consulter ce > code facilement dans Excel SANS coller (je suis difficile!). En somme > j'aimerais détecter ce qu'il y a dans le presse-papiers SANS le coller > (du genre: CodeRetour = Clipboard.Value ). Est-ce possible? > > Laurent (au Québec au moins, les Laurent sont rares...) ;-) > > P.S.: la seule raison pour laquelle j'appelle un programme C, c'est pour > effectuer un transfert FTP, mais si quelqu'un connaît le moyen > d'effectuer une connexion et un 'PUT' FTP via Excel, ça serait vraiment > le pied!