 1 membre
Connectés : ( personne )
 - La Charte du Forum - Forum
 - Questions générale
 Sujet n° 333 |
Contrôler une application lancée depuis Access |
le 28/02/2010 : 10:33
par bpria
visiteur
|
BonjourMon application Access (A) lance une autre application access (B) via l'instruction "Retour = Shell(Appli, vbMaximizedFocus)"Je voudrais reprendre la main à la fin de l'exécution de B et effectuer une action dans A qui dépende de la façon dont B s'est déroulé. Le moyen que j'ai trouvé est d'utiliser le code "Shell and wait" décrit dans ce site mais j'ai des difficultés : dans l'appli B je mets une boucle d'attente de plusieurs secondes (ce qui pour moi signifie que B s'est déroulé d'une certaine façon) et malgré cela je reprends la main dans A au bout d'une fraction de seconde seulementLe contexte : au lancement de B j'ouvre un formulaire, et c'est dans le code Form_Current de ce formulaire que je teste de quelle façon B se déroule. J'utilise Access2000NB Je me demande s'il n'existe pas un meilleur moyen de contrôler comment B s'est déroulé, autre que de mettre une boucle d'attente (solution qui ne me plaît pas mais je ne trouve rien d'autre). Par exemple en contrôlant comment on sort de BJ'espère être clair, en tout cas merci d'avance |
|
|  
|
Réponse n° 1
--------
le 28/02/2010 : 16:46
par 3Stone
Administrateur
|
Bonjour,
Pour attendre qu'une application lancée depuis Access se termine, il faut utiliser ceci.
Une "boucle" d'attente est toujours une mauvaise solution. Pour attendre un certain laps de temps, il faut utiliser ceci.
Par ailleurs, on peut reprendre la main... mais on n'a pas de réel contrôle sur ce qui se fait (ou s'est fait).
Si cela est nécessaire, il faut se tourner vers ce que l'on appelle l'automation.
L'automation permet de piloter un programme "à distance". Ainsi, on peut piloter Excel, Word, mais aussi Access.
Un début d'explication est donné par Raymond: nouvelle instance et impression d'un état.
Le principe est assez simple et consiste à s'adresser à une "autre base" (cette nouvelle instance) au lieu de la base actuelle.
Ceci dit: l'utilité de cette méthode dépend en fait de ce que l'on souhaite faire...
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 2
--------
le 28/02/2010 : 17:25
par bpria
visiteur
|
Merci
Entre temps j'ai trouvé le moyen, après avoir repris la main, de savoir comment mon application B s'est terminée (depuis B j'écris dans une table de A) mais je me heurte à un nouveau problème : bien qu'ayant quitté B par DoCmd.Quit j'ai toujours le fichier AppliB.ldb ouvert (et en effet B n'est pas fermée !)
Merci encore pour votre aide toujours pertinente, et qui m'a déjà aidé à plusieurs reprises |
|
|
|
Réponse n° 3
--------
le 28/02/2010 : 18:09
par 3Stone
Administrateur
|
Citation : depuis B j'écris dans une table de A
Bien sûr, il y a une multitude de possibilité de ce style... comme écrire dans un fichier texte, dans la base de registre, etc.
Citation :bien qu'ayant quitté B par DoCmd.Quit j'ai toujours le fichier AppliB.ldb ouvert (et en effet B n'est pas fermée !)
C'est que le code n'est pas exécuté proprement.
Entre autre, il faut veiller à libérer les variables et autres objets déclaré par "Set yx = ..."
Cordialement,
Pierre(3stone) |
|
|
|
Réponse n° 4
--------
le 28/02/2010 : 19:11
par bpria
visiteur
|
En fait mon code s'exécute normalement mais j'étais en mode débogage dans mon application maître A. En mode normal tout se passe bien
Donc problème réglé, tout va bien, merci encore |
|
|
|
 sujet actif
sujet clos
 Important!
 Nouveau message -
 Rectifier message
 Clôturer sujet
 Remonter
|
© 2004-2013 
