2009-04-16 6 views
1

J'aimerais disposer d'une boîte d'alerte non modale appelée formulaire de traitement par lots. Actuellement, je suis en utilisant vbscript pour créer une zone d'alerte modale:Boîte de notification non modale du script de traitement par lots

>usermessage.vbs ECHO WScript.Echo^("Generating report - this may take a moment." ^) 
WSCRIPT.EXE usermessage.vbs 

Mais je voudrais poursuivre le script (génération du rapport) sans attendre l'interaction utilisateur. Comment puis-je accomplir cela? Je m'en fous si c'est vbscript ou pas - je veux juste que cela fonctionne à partir de mon script de traitement par lots (dans Windows XP).

Répondre

2

Une simple réponse qui n'a aucune nouvelle exigence par rapport à votre astuce actuelle consiste à utiliser la commande start pour détacher le script de l'exécution du fichier de commandes.

Cela pourrait ressembler à:

 
>usermessage.vbs ECHO WScript.Echo^("Generating report - this may take a moment." ^) 
start WSCRIPT.EXE usermessage.vbs 
echo This text is a proxy for the hard work of writing the report 

où la seule différence utilise start pour exécuter wscript. Cela souffre du défaut qu'il laisse un fichier temporaire traînant dans le répertoire en cours, et que la boîte doit être finalement fermé manuellement.

Les deux problèmes sont faciles à manipuler:

 
@echo off 
setlocal 
set msg="%TMP%\tempmsg.vbs" 
ECHO WScript.Echo^("Generating report - this may take a moment." ^) >%msg% 
start WSCRIPT.EXE /I /T:15 %msg% 
echo This text is a proxy for the hard work of writing the report 
ping -n 5 127.0.0.1 >NULL 
del %msg% >NUL 2>&1 

Ici, je propose le script temporaire vers le dossier %TMP%, et rappelez-vous de le supprimer quand nous aurons fini avec elle. J'ai utilisé une commande echo et une commande ping pour perdre du temps à faire la démonstration d'un long processus en cours. Et, j'ai utilisé les options /I et /T à wscript pour m'assurer que le script est exécuté "interactivement" et pour définir un délai maximum pour permettre l'exécution du script.

Le @echo off et le setlocal le rendent plus propre lorsqu'il est exécuté à partir d'une invite de commande et l'empêche d'afficher le nom% msg% dans l'environnement de l'invite.

Éditer: La critique de Johannes Rössel de setlocal dans les commentaires est incorrecte. Si cela est invoqué à une invite de commande, sans le setlocal la variable msg sera visible à l'invite et aux autres fichiers batch et programmes lancés à partir de cette invite. Il est recommandé d'utiliser setlocal pour isoler les variables locales dans un fichier de traitement par lots si l'on est en train d'écrire quoi que ce soit de plus qu'un script "throw-away".

Ceci peut être facilement démontré:

 
C:> type seta.bat 
@set A=SomeValue 

C:> set A 
ALLUSERSPROFILE=C:\Documents and Settings\All Users 
APPDATA=C:\Documents and Settings\Ross\Application Data 

C:> seta.bat 

C:> set A 
A=SomeValue 
ALLUSERSPROFILE=C:\Documents and Settings\All Users 
APPDATA=C:\Documents and Settings\Ross\Application Data 

C:> 
+1

Désolé, mais vous assumez que cmd.exe est trop comme une coquille * nix. Chaque fichier batch appelé à une invite de commande est interprété par cette même copie de cmd.exe et peut en effet modifier l'environnement pour les autres commandes. C'est pourquoi setlocal a été ajouté. Vous avez raison si un fichier batch est appelé depuis l'explorateur. Cela a été vrai depuis DOS 1.0 et COMMAND.COM, et reste vrai au moins sous XP. – RBerteig

Questions connexes