Discussion :

[saidino]

Bonjour,
Je travaille sur une appli en VB, et des mises a jour sont faites manuellement chaque semaine grace à une fonction que l'on lance avec un simple click, or je voudrais lancer cette fonction periodiquement sans intervention de tiers, mais je ne voi pa du tout coment faire!!

[Delbeke]

En donnant le boulot au planificateur de tache de windows ?

[ThierryAIM]

c'est ce que j'aurais fait aussi
un petit prog à part qui ferme l'appli si elle est ouverte, effectue la maj et relance le tout

[saidino]

merci pour vos conseils, je ne connaissais pas cet outil, je m'y met de ce pas

[saidino]

J'arrive effectivement à lancer mon appli à partir du planificateur de taches mais je ne vois pas comment on peut accéder à une fonction de l'appli à partir du planificateur de taches?

[OhMonBato]

On ne peut pas mais peut etre par contre tu pourrais faire une petite appli dédiée à ta mise à jour et c'est celle là que tu lancerais par le planificateur.

[ThierryAIM]

un petit prog à part qui ferme l'appli si elle est ouverte, effectue la maj et relance le tout

[ucfoutu]

Bonjour,

d'aucuns ont l'habitude :

- de procéder à cette vérification à l'ouverture d'u ne session
- si résultat = nécessité de lancer le programme :

a) l'utilisateur est invité à choisir entre une action immédiate ou une action différée à la prochaine fermeture (et un simple drapeau suffit alors à la fermeture).
b) Dans tous les cas de figure, un fichier texte permet de mémoriser le dernier lancement de la procédure en cause.

Une variante : signaler à l'utilisateur que la procédure devra être lancée dans l'heure qui suit et qu'il devra donc cesser toutes modifications avant ce délai.
Le tout accompagné d'un timer de vérification de non dépassement du délai accordé (et lancement de la procédure de sortie) , ainsi que d'un drapeau qui déclenchera l'opération à la sortie.

[saidino]

Il s'agit en fait dans mon cas d'importation de données contenu dans des fichiers excel, le probleme d'utilisateur connecté ne se pose car cette importation devra se faire la nuit. J'ai déjà la fonction d'importation qui est lancé par un administrateur, mais oi ce que je veux en faite c'est que cette e
administrateur n'ai plus besoin d'effectuer cette tache mais qu'elle soit faite toute seule.

[OhMonBato]

Ok, mais je crois que thierry t'as donné une piste non ? l'as tu essayé ?

[MGD_Software]

J'arrive effectivement à lancer mon appli à partir du planificateur de taches mais je ne vois pas comment on peut accéder à une fonction de l'appli à partir du planificateur de taches?

Il me semble que la manière la plus simple est de fournir un paramètre à l'appel de l'appli dans le planificateur de tâches, et d'exploiter dans le code de démarrage de l'appli la variable command qui représente la chaine de paramètre passée.

Par exemple :
Dans le planificateur de tâche, on appelle l'appli par (les guillemets sont impératifs si le chemin ou le nom de l'appli contiennent des espaces) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

"disque:\chemin\appli a lancer" Action=3

Dans l'application, code de la feuille de démarrage:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Private Sub Form_Load()
    Dim sParams$, nToDo%
    If Command Like "Action*" Then
        sParams = Split(Command, "=")
        nToDo = Val(sParams(1))     'Val pour éviter une valeur non numérique
        Select Case nToDo
            Case 1:     Call Proc1  'Procédure à lancer si action = 1
            Case 2:     Call Proc2  'Procédure à lancer si action = 2
            'etc.
        End Select
    End If
End Sub

Version beaucoup plus puissante : on passe directement le nom de la fonction en paramètre, avec les propres paramètres de la fonction à appeler.

Exemple :
Dans le planificateur de tâche, on appelle l'appli par

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
"disque:\chemin\appli à lancer" FonctionAppellée/paramètres

Le "/" est utilisé pour séparer le nom de la procédure de ses paramètres. Il peut être remplacé par n'importe quel caractère (à condition de modifier aussi le code ci-dessous).

Dans l'application, code de la feuille de démarrage:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
Private Sub Form_Load()
    Dim sAction$()
    If Command <> "" Then
        sAction = Split(Command, "/")
        If UBound(sAction) < 1 Then         'Pas de paramètre
            CallByName Me, sAction(0), VbMethod
        Else
            CallByName Me, Trim(sAction(0)), VbMethod, sAction(1)
        End If
    End If
End Sub

Attention, pour que cela fonctionne, toutes les procédures appelées doivent impérativement déclarées publiques et être situées dans la feuille courante. Si la fonction n'existe pas, ou si le nombre ou type de paramètres n'est pas correct, il y aura une erreur d'exécution. Il est donc nécessaire de prévoir une gestion d'erreur (non faite ici pôur de raisons de clarté et de place)

Le paramètre après le / peut représenter une chaine de paramètres, du style "param1, param2, param3"

Notez que la variable Command n'est pas à déclarer (même en mode Option Explicit), c'est une variable intrinsèque de VB.

Si avec ça vous n'arrivez pas à faire ce que vous souhaitez, c'est à désespérer !

[saidino]

Merci beaucoup!!

[ThierryAIM]

Si avec ça vous n'arrivez pas à faire ce que vous souhaitez, c'est à désespérer !

ok
mais je me pose quand même une question ?

si l'appli tourne déjà (oubli de la fermer !) quand le planificateur la lance de nouveau pour les mises à jour, que se passe-t-il ?

comment est gérer le App.PrevInstance ?

[MGD_Software]

Si on lance une appli à intervalle régulier pour effectuer une tâche précise, c'est qu'elle se termine à la fin de cette tâche. Sinon, il suffit de la lancer une fois et d'y mettre un timer...

Si la session précédente s'est plantée avant de se refermer, l'appel suivant créera une nouvelle instance qui, elle, exécutera (normalement) son boulot, sauf si la raison du plantage est la même, auquel cas on aura N tâches plantées au bout d'un moment.

On peut éviter cela bien sûr en introduisant en début de procédure une ligne:
If App.PrevInstance then Unload Me: Exit Sub

Mais si la tâche précédente est plantée sévère, je ne réponds pas du comportement de PrevInstance. Et de toutes façons, on ne pourra rien faire pour elle.

Pour les foldingues du hardcore, j'entrevois l'utilisation de l'API Windows pour détecter le module chargé, récupérer son ID de process, et lui envoyer un Kill. Moi je savais faire ça sous Unix, mais pas sous Windows.
S'il y a un candidat, yaka !

Moralité : yakapa faire des programmes qui plantent !

[ucfoutu]

Bonjour,

Que veux-tu dire ?
Récupérer l'ID est facile (si l'on utilise Shell)
Récupérer le hwnd correspondant à cet ID est relativement simple.
L'utilisation de SendMessage (en se référant à ce hwnd) peut alors permettre de fermer l'application lancée par Shell.

[MGD_Software]

Bonjour,

Récupérer l'ID est facile (si l'on utilise Shell)
Récupérer le hwnd correspondant à cet ID est relativement simple.
L'utilisation de SendMessage (en se référant à ce hwnd) peut alors permettre de fermer l'application lancée par Shell.

D'accord pour les deux premières lignes.
Pour la troisième, je demande à voir ce que donne SendMessage à une appli qui ne répond même plus au gestionnaire de tâches. J'avoue que je n'ai jamais essayé..

Pour que l'appli réponde à un SendMessage, encore faut-il qu'elle écoute les messages de la boucle de messages de Windows (celle qu'on programmait à la main en C sous les premiers Windows, et qui existe toujours bien qu'enfouie dans les profondeurs des MFC). Je ne suis même pas sûr qu'une boucle du style "Do while True: Loop" laisse l'appli répondre à un SendMessage (en mode compilé bien sûr, pas en dévloppement).

Je parlais du KillProcess envoyé au noyau, l'équivalent du "fin de tâche" du gestionnaire de tâche.

Mais je pense que là on déborde largement du débat initial, dont le problème me semble résolu au vu du message précédent de Saidino.
Comme dit le proverbe, ceci est une autre histoire.

Et je répète : yakapa faire des programmes qui plantent !