EXECUTE....wait

Sujet: EXECUTE....wait Ven 27 Nov 2009 - 13:30

Salut à tous

Personnellement, ça ne me cause aucun problème de gérer deux programmes. Pour cela j'ai fait un exemple. Essayez-le et dites moi ce que vous en pensez.
Les WAIT tous azimuts sont la juste pour suivre la progression et l'interactivité des deux programmes.
Seul contrainte, compiler le deuxième code, le nommer EXEC2.exe et le mettre dans la racine c:

Sinon le premier code vous pouvez soit l'exécuter en mode BAS ou EXE et le placer ou vous voulez

voici le premier code

Code:: error_french
label boucle,suite
dim a,b,c,g,h,i
left 0,30 : top 0,50 : width 0,300 : height 0,450 : caption 0,"Premier programme"
picture 1 : left 1,0 : top 1,0 : width 1,290 : height 1,420
a=10 : b=20
print_target_is 1
print "Execution du premier programme"
wait 3000
print
print "Déroulement du premier programme"
print
wait 3000
print "Déclaration de deux variables :"
wait 3000
print
print "Première variable :";a
print "Deuxième variable :";b
wait 3000
print : print
print "Calcul d'une troisième variable !"
c=a*b
wait 3000
print "La troisième variable est : ";c
print
wait 3000
print "Passage des trois variables"
print "au deuxième programme"
' création de la translation
dir_make "c:\files"
file_open_write 1,"c:\files\prov.txt"
file_writeln 1,a
file_writeln 1,b
file_writeln 1,c
file_close 1
print
print "Passage au deuxième programme"
wait 3000
execute "c:\exec2.exe"
display
boucle:
display
if file_exists("c:\files\ts.txt")=1 then goto suite
goto boucle
suite:
file_open_read 1,"c:\files\prov2.txt"
file_readln 1,g
file_readln 1,h
file_readln 1,i
file_close 1
wait 3000 : print
print "retour au programme principal" : print
print "les 3 valeurs récupérées sont :"
wait 3000 : print
print "la première : ";g
wait 3000 : print "la seconde : ";h
wait 3000 : print "la troisième : ";i
wait 3000 : print : print : print "Opération de réinitialisation"
file_delete "c:\files\prov.txt"
file_delete "c:\files\prov2.txt"
file_delete "c:\files\ts.txt"
dir_remove "c:\files"
wait 3000 : print "fin des opérations de réinitialisation"
wait 5000
terminate

et voici le deuxième code à compiler en EXE sous le nom EXEC2 dans la racine c:

Code:: error_french
dim d,e,f,g,h,i
left 0,350 : top 0,50 : width 0,300 : height 0,450 : caption 0,"Deuxième programme"
file_open_read 1,"c:\files\prov.txt"
file_readln 1,d
file_readln 1,e
file_readln 1,f
file_close 1
print "Exécution du deuxième progamme" : print
wait 3000
print "Récupération des données"
print "du premier programme" : print
wait 3000
print "La première variable est : ";d
print "La deuxième variable est : ";e
print : print "La troisième (produit de a x b) : ";f
wait 3000
print : print "Maintenant : nouveau calcul !"
print : print "Racine carré des 3 variables !"
wait 3000
g=sqr(d) : h=sqr(e) : i=sqr(f)
print : print "racine de a : ";g
print "racine de b : ";h
print "racine de c : ";i
wait 3000
print : print "Passage des 3 données"
print "au premier programme"
file_open_write 1,"c:\files\prov2.txt"
file_writeln 1,g
file_writeln 1,h
file_writeln 1,i
file_close 1
file_open_write 1,"c:\files\ts.txt"
file_writeln 1,"ts"
file_close 1
wait 8000
terminate

J'attends vos avis.
Ils m'interressent tous.
C'est une façon de programmer un EXECUTE_WAIT

Georges
@+

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 14:47

1er essai:
j'ai enregistré exec2 et le l'ai transformé en EXE, il se trouve maintenant dans: C:\Documents and Settings\MONNOM\Bureau\PROG PANORAMIC
qand je lance le premier il se déroule, mais là il attend indéfiniement donc [ctrl+alt+sup]

2ème essai: je déplace exec2.exe dans C (emplacement c:\)
je lance le 1er depuis l'editeur, le programme se déroule jusqu'à l'apparition de la 3ème variable (200) et là apparait le message d'erreur 102 Impossible de créer le répertoire ligne 31

Que dois-je faire ?

J'ajoute que si je vais dans rechercher et que je lance exec2 manuellement, il fonctionne, mais n'ouvre pas le premier.

Sujet: re Ven 27 Nov 2009 - 14:54

salut Jean-Claude

Tu vas dans la racine C de ton disque dur et tu supprime le répertoire "files" qui a été créé par le progs et tu relances.
ça va marcher

@+

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 15:07

Merci Georges, çà marche, mais je comprend pas pourquoi il faut supprimer le fichier que le programme crée lui même, pour que cela fonctionne. Pour les commentaires, il faut que j'y regarde de plus près.
A+

Sujet: re Ven 27 Nov 2009 - 15:11

Salut Jean-Claude

Dans le répertoire, il y a deux fichiers provisoires et un fichier test.
Dans ce cas il ne servent plus à rien après l'exécution de ce prog.
Inutile de les garder.
C'est un exemple de solution qui permet de pouvoir controler le premier prog pendant l'exécution du second.
C'est idée m'est venue suite au post EXECUTE
@+

Nombre de messages : 2747 Date d'inscription : 13/09/2009

C'est une possibilité, en effet. Les remarques de Jean Claude montrent cependant que ce n'est pas simple. J'ai simplement lu tes programmes sans les essayer. Excuse-moi, mais les programmes équipés de boucles infinies (ou pouvant potentiellement le devenir) (avec des gosub montant) (et pouvant de ce fait nécessiter des CTRL-ALT-SUPPR) me hérissent le poil. Sans doute un souvenir des époques héroïques où le CTRL-ALT-SUPPR n'existait pas encore et où il fallait redémarrer pour en sortir.
Mais pourquoi n'utilise-tu pas pas execute "machin.exe "+a+b+c+d suivi de terminate, suivi du calcul des racines carré par le programme machin qui renvoie les résultats au premier programme de la même manière ? Cela semblerait plus simple, non ?

PS: enfin, à vrai dire, renvoyer les résultats au premier programme n'est peut-être pas aussi simple que de les renvoyer à un 3° qui s'occupe de la suite...

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 15:26

Dis-moi si je me trompe, Georges, mais dans ton exemple tu parle de l'hypothèse d'un programme Panoramic que tu as écrit et compilé, qui lance un second programme Panoramic que tu as écrit et compilé, donc tu es maître des deux programmes.
Dans ce cas, évidemment, il y a toujours moyen de contourner la difficulté.

Moi, mon problème, c'est mon programme Panoramic qui appelle un programme compilé récupéré je ne sais où, et dont je ne suis pas du tout maître du fonctionnement interne. S'il rend un ou des paramètre(s), par exemple à la console, je peux dérouter la sortie de ce paramètre dans un fichier:

Code:: Programme.exe [paramètre(s) d'entrée] >FichierDeSortie

Et c'est ce fichier que je récupère dans mon programme appelant.
Le hic c'est que je ne peux pas savoir quand ce fichier sera créé, puisque le File_Exists n'est pas fiable dans ce cas.
Un exemple type:

Code:: EXECUTE "Command.com /c DIR C:\etc... \*.txt >Fichierresultat"

L'autre problème, encore plus ardu, c'est la présence d'espaces dans les noms de chemin... comme tu as pu le constater (C:\Documents and Settings\MONNOM\Bureau\PROG )

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 15:34

pourquoi tu te fais du mal Georges, J'ai regardé dans la liste de Jack, la commande EXECUTE_WAIT est annoncée sous 2 semaines.

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 15:39

Je ne me fais pas du mal, et je suis même très très content de l'annonce du EXECUTE_WAIT, et pas impatient du tout (comme certains... Very Happy

) , c'était juste pour dire à Georges que sa solution ne résout pas mes problèmes.

Nombre de messages : 2747 Date d'inscription : 13/09/2009

Réponse à JL35 :
Pour dire exactement l'inverse de ce que je viens de préciser dans mon précédent message (mais la contradiction n'est-elle pas une grande caractéristique humaine ...?) tu peux (je crois) résoudre ton manque de fiabilité du file_exists en enfermant celui-ci dans une boucle (potentiellement) infinie (comme j'aime bien...) comme l'a fait Georges dans son programme. Si ça ne plante pas, cela devrait n'en sortir que lorsque ton (ou tes) fichiers existeront enfin.
Pour les espaces dans les noms de fichiers et répertoires, je ne vois pas de solution si tu ne contrôles pas ces noms.
scratch

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 15:45

??? comprends pas très bien.
Si je sors du file_exists (qui me dit oui) pour faire file_open, c'est lui qui va planter !
J'ai bien pensé à un truc du genre On_Error goto... jusqu'à ce qu'il n'y ait plus d'erreur, mais ça ne fait pas très propre. (je ne l'ai pas encore pratiqué en Panoramic).

Le plus simple, finalement, en attendant Execute_Wait, c'est de mettre un Wait suffisamment dimensionné avant le file_open...

Sujet: re Ven 27 Nov 2009 - 15:53

salut à tous

@jjn4
ne t'inquites pas, dans ce cas il n'y aura pas de problème.
Je l'ai testé suffisament de fois pour ça.
comme je l'ai dit la seule contrainte est de compiler le second prog avec le nom EXEC2.exe et de le mettre dans la racine C: et t'as pas de prob.

Effectivement la difficulté réside dans le fait de récupérer des données du second programmes quelque soit sa durée.

@JL35
Effectivement, sur cet exemple on est propriétaire des deux codes. Et on peut dans ce cas contourner et éviter tous les problèmes.
Ceci étant dit, ce n'est pas parce qu'on n'est pas maitre d'un progs qu'on ne peut pas trouver de solution.
Je ne sais pas si le futur EXECUTE_WAIT pourra ("questionner") le programme appelé ou carrement interrompre le prog principal sur une durée de temps.
faudra voir. de toute les façons nous sommes des programmeurs (oui oui c'est bien ça - même si on n'est pas les meilleurs du monde). Et en tant que tels, on a vraiment le choix d'expérimenter toutes les solutions pour faire tourner nos progs.
Il me semble que, et beaucoup sur ce forum seront d'accord avec moi, que l'on programme pas forcément pour soi - donc on teste toutes les pistes qui permettent à nos progs de ne pas bugger

@+

Nombre de messages : 2747 Date d'inscription : 13/09/2009

En effet, mais il y a des fois où on n'en est plus à savoir si cela fait propre ou pas...
Idée: Idea

tu pourrais mettre effectivement un on_error_goto enchaînant avec un
message "Avez-vous vérifié que le gaz est bien fermé ?"
le temps de répondre (en ayant eventuellement fait un tour par la cuisine), le open_dialog ne ferait plus d'erreur...
Laughing

(c'est une idée que j'ai sorti du tiroir situé tout à fait en bas et intitulé "idées complètement sauvages"...)

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 15:57

Donc, je recommence, Ton idée Georges est très bonne. Je résume.
Tu fait créer par prog2 un fichier bidon qui sert de feu rouge à prog1 et quand ce fichier est détruit par prog2 (à la fin) le feu repasse au vert pour prog1.
Une bonne astuce, mais tu me dis pas pourquoi le fichier files est créer et qu'il faut le détruire ??
Attendons de voir la nouvelle commande.
Bravo, A+

j'ai bien du mal à passer mes messages, il y a du traffic.

Sujet: re Ven 27 Nov 2009 - 16:01

salut

@jjn4
dans la boucle (potentiellement) infinie, on pourrait insérer un scancode pour en sortir en cas de problème.

@Jean-Claude
je te rassure, je ne me fais pas de mal. même après le codage de l'EXECUTE_WAIT, je pourrais (je dit bien pourrait ) avoir besoin de ce type d'interaction pour d'autres situation.

@JL35
a mon avis on n'a pas besoin de on_error_goto sur file_exist puisque le résultat attends un 0 ou bien un 1. Il suffit de traiter l'information comme on le souhaite

@+

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 16:07

Attention Georges, ne te méprends pas, je ne critique absolument pas ta façon de faire, bien au contraire ! je dis simplement que ça ne semble pas résoudre MON problème à moi, mais je te suis bien reconnaissant de faire partager tes tentatives de solutions.
Comme moi ça m'arrive de poster du code qui ne convient certainement pas à tout le monde, mais ça peut donner des idées, même pour autre chose que le sujet dont on parle.
Comme bien souvent en programmation, et pour moi c'est ce qui en fait le charme, il y a différents moyens de contourner les problèmes, et chacun a sa façon de le faire.

C'est cool !

Georges, on s'est croisés, mais je parlais du On_Error sur le File_Open, évidemment pas sur le File_Exists.

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 16:17

Il se passe des trucs bisards, j'envoie un message et çà en efface un autre, du coup il n'y a plus de cohérence. Mon message précédent a été fait avant que je ne vois le dernier de Georges.

Sujet: re Ven 27 Nov 2009 - 16:19

salut JL35

je sais que tu ne critiques pas ma façon de faire (en tout cas pas négativement) et j'ai bien compris ton intervention - t'inquiète pas - ya pas d'prob.
j'ai compris aussi que ça resolvait pas ton souci, mais enfin on peut toujours chercher des solutions pour y arriver

j'ai bien compris aussi ton souci sur le file_open, mais comme je le dit avec un test sur le file_exist on peut de manière raisonnable éviter l'erreur sur le file_open sans passer par des wait intempestif (puisque les processeurs de calcul change d'un ordi à l'autre donc la vitesse de calcul)
dans mon exemple je créé un fichier test nommé ts.txt (il ne sert à rien sinon de par son existence validé le fait que le fichier précédent à savoir dans mon progs prov2.txt est créé et refermé) .
Et la plus d'erreur sur un file_open adressé sur prov2.txt puisqu'il est écrit physiquement sur le disque

@+

P.S.: c'est cool pour moi aussi

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 16:32

Oui, mais tu lances un programme qui s'exécute très vite.
Pardon si je me répète, mais moi je lance un programme externe qui met un certain temps à s'exécuter, qui fait plein de calculs compliqués, et qui renvoie le résultat dans un fichier, et je constate que Panoramic lance le programme externe mais sans attendre exécute immédiatement les lignes qui suivent l'Execute.
Et je constate que malgré le test File_Exists qui répond 1, l'Open_File qui suit plante en disant le fichier n'existe pas.
C'est illogique, mais c'est comme ça.
Si je rajoute un Wait, il n'y a plus d'erreur.

Ca veut dire pour moi que le fichier existe de manière logique, mais pas de manière physique, il n'a pas encore été réellement écrit sur disque, il est encore quelque part dans un buffer de Windows. Et l'Open ne le trouve pas.

Avec l'Execute_Wait, Panoramic doit avoir un moyen (windows) de savoir quand le déroulement du programme appelé est complètement terminé, et n'exécutera les lignes suivant l'Execute qu'à ce moment-là.

Sujet: re Ven 27 Nov 2009 - 16:48

salut JL35

comme dirait Jean-Claude, à dans deux semaines

@+

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 16:56

Hein ? tu pars en vacances ?

Sujet: re Ven 27 Nov 2009 - 17:05

non j'attends EXECUTE_WAIT et une pizza

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 17:07

pardon, j'ai eu un moment d'absence...
(je me disais aussi, quand on est dans les îles on n'a pas besoin de vacances Very Happy

)

Nombre de messages : 2747 Date d'inscription : 13/09/2009

Jean-Claude, si je puis me permettre de te répondre à la question que tu as posée à Georges (qui ne t'a pas donné la réponse), la fait de détruire le fichier provisoire après l'avoir créé et utilisé, cela sert d'abord à faire plus propre (plus écolo ?) en encombrant la mémoire le moins possible avec des trucs qui ne servent plus à rien. Cela peut aussi avoir son importance quand on traite de données confidentielles, par exemple dans le boulot.
Par contre, dans ce cas-là, on a le même problème que signale JL35 avec ses execute, c'est à dire qu'il ne faut pas créer puis ensuite effacer le fichier lorsque l'autre programme n'a pas encore commencé à l'utiliser, sinon, bug.
Crying or Very sad

Sujet: Re: EXECUTE....wait Ven 27 Nov 2009 - 19:58

J'en conclus qu'il vaut mieux attendre EXECUTE_WAIT.
A+

» Wait / Pause
» execute n'execute pas un exe
» La musique adoucit les moeurs
» La commande EXECUTE
» commande execute