Discussion :

[ZenZiTone]

Bonjour !

Alors pour faire simple : J'ai une application graphique executant une certaine procédure suite au clique sur le bouton 'démarrer'. Mon but maintenant est de lancer cette application dans une tâche planifiée de façon transparente.
Dit comme ça, ça à l'air simple ! Mais le débutant que je suis s'est vite confronté à plusieurs problèmes.

J'ai donc pensé à la solution suivante : rendre la fenêtre invisible puis simuler le clique sur le bouton.

J'avais aussi pensé à modifier mon unit qui est une classe TForm en classe simple, mais mes composants de base de données sont dans la form justement..

Je voudrais donc savoir si la voie que je choisis est la bonne et, si oui, comment simuler le clique? :O

Merci d'avance

[Gilbert Geyer]

Bonjour,

rendre la fenêtre invisible puis simuler le clique sur le bouton.

Pour simuler :

Code :

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

1
2
3
4
5
6
7
var       p : TPoint;
begin     p.x:=20; p.y:=20;     // coordonnées locales du bouton sur lequel on simule le click
          p:=ClientToScreen(p); // coordonnées écran du même point
          SetCursorPos(p.x,p.y);
          Mouse_Event(MOUSEEVENTF_LEFTDOWN, 0, 0, 0, 0);
          Mouse_Event(MOUSEEVENTF_LEFTUP, 0, 0, 0, 0);
end;

Comme la fenêtre est invisible il suffit de détecter l'appui d'une touche-clavier :

Code :

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

1
2
3
4
5
function  ToucheCla(t : integer) : boolean; // Appui Touche
//        utilisations : if ToucheCla(VK_CONTROL) then
//                       if ToucheCla(Ord('R')) then
begin     Result:= ((GetAsyncKeyState(t) and 32768)<> 0)
end;

A+.

EDIT : dans l'exemple p.x:=20; p.y:=20; correspond à un bouton situé situé sous la barre de titre de la form principale
et avec p.X := 400; p.y := -5; ça ouvre l'item situé en X = 400 d'un MainMenu1

[ZenZiTone]

Merci pour ta réponse mais je ne voudrais pas que l'utilisateur ait a agir sur le programme.

Dans la finalité, celui-ci s'exécute dans une tâche planifiée et est entièrement autonome. Seul les messages d'erreur s'afficheraient dans des message box.

[Gilbert Geyer]

Re-bonjour,

mais je ne voudrais pas que l'utilisateur ait a agir sur le programme.

Bin, dans ce cas il suffit de déclencher la simulation du click dès le onCreate ou bien via un Timer s'il faut retarder l'action.

A+.

[ZenZiTone]

Ah mais c'est que c'est pas bête tou ça..

beaucoup pour ton aide

[e-ric]

Salut

Tout dépend de l'objectif, est-ce que tu veux que toute l'application soit automatisée ou seulement une petite partie ? Est-ce que l'application graphique sera toujours utilisée en tant que telle ?

L'idéal est de commencer par déplacer la procédure dans un DataModule, c'est plus sain et ce sera plus facile à transformer après. Mais attention au couplage (les dépendances) entre ta procédure et la fiche où elle est définie.
2 axes de solution:

- tu écris une nouvelle application console qui reprend le code à automatisé en le copiant ou le partageant avec l'application graphique initiale.

- tu transformes ton application graphique en application console, c'est de la bidouille, il faut savoir que tu peux très bien afficher des fiches depuis une application console, il n'y a pas d'impossibilité, on obtient une forme d'hybride entre les 2 modes. Tu pourras prévoir un paramètre en ligne de commande pour décider si tu passes directement en mode graphique ou en mode automatisé. Tout cela est bien sûr à coder.

@+

[ZenZiTone]

J'ai vu que l'on pouvait lancer une form depuis une console mais je trouve ça bisarement fait... J'ai suivi ce cours et j'ai regardé les exemples. Le fait est que mon application n'est pas très conséquente et s'occupe juste de vérivier des champs dans une table. Le coup de rendre la fenêtre invisible n'est sûrement pas le plus optimal, j'en conviens, mais ça reste assez pratique dans le cas ou un utilisateur voudrait lancer l'appli manuellement.

Le petit soucis restant est que la fiche s'ouvre a la fin de l'exe. Mais un appel de méthode genre close() doit bien exister ^^

[e-ric]

Sans passer par une application console mais en modifiant légèrement le fichier dpr, tu pourrais peut-être éviter cela, en conditionnant l'exécution normal du code du projet (.dpr) à un paramètre du programme.

Selon la valeur du paramètre, tu exécute normalement le code du projet ou tu exécutes uniquement le code de contrôle. Dans ce cas plus d'affichage bizarre et plus besoin de pirouettes dans le code de la fiche qui ne seront pas faciles à comprendre plus tard.

Cette solution a l'inconvénient de modifier le fichier dpr, ce qui peut compliquer l'ajout de nouvelles fiches ou de nouveaux datamodules plus tard.

[ZenZiTone]

Hum lors de l'execution de l'appli un mdp utilisateur est demandé. J'ai la propriété login prompt a true c'est donc normal je suppose. Cependant lorsque je décoche la case et met le mot de passe dans les propriétés du TDataBase, l'execution génère un violation de cle.. Comment ça se fait?

[e-ric]

Discussion résolue, vous dites ??

Question bête (je m'(attend à une réponse idiote) : as-tu défini ll nom de l'utilisateur ?
Dans le code que tu exécutes, fais-tu des insertions ?

@+

[Andnotor]

tu transformes ton application graphique en application console, c'est de la bidouille, il faut savoir que tu peux très bien afficher des fiches depuis une application console, il n'y a pas d'impossibilité, on obtient une forme d'hybride entre les 2 modes.

Ça n'a rien d'hybride, une application se déroule du begin au end, GUI comme console. La différence est qu'une application "GUI" crée implicitement un TApplication intégrant une boucle de messages (dans sa méthode Run) et par conséquent une fenêtre "invisible" (un Handle pour recevoir ces messages). Dans le même temps, elle n'affiche pas la console.
Pour afficher la console depuis une app "GUI", soit AllocConsole, soit définir Générer une application console dans les options du projet.
A l'inverse, pour utiliser une fiche dans une application "console", il faudra obligatoirement qu'elle soit modale pour justement créer une boucle de messages. Sinon, le programme quitte immédiatement.

Le coup de rendre la fenêtre invisible n'est sûrement pas le plus optimal, j'en conviens, mais ça reste assez pratique dans le cas ou un utilisateur voudrait lancer l'appli manuellement.

C'est également la méthode que je privilégierais

[Paul TOTH]

il suffirait de déporter tout le code utilisable sans GUI dans un DataModule et de créer deux DPR, le premier utilise une fiche et le DataModule, le second (une application CONSOLE) n'utiliserais que le DataModule.

dans la fiche, Button1Click appellerait une méthode de traitement du DataModule, laquelle méthode serait appelée directement dans le .DPR de l'application console.

Code :

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

1
2
3
4
5
6
7
8
9
 
program ModeConsole;
{$APPTYPE CONSOLE}
uses
  Unit2;
begin
  DataModule2 := TDataModule2.Create(nil);
  DataModule2.LancerTraitement;
end;