libérer toutes les variables d'un programme sans le fermer

Bonjour,

TERMINATE libère toutes les variables d'un programme et ferme ce dernier.
Existe-t-il une fonction qui libérerait toutes les variables du programme mais sans fermer celui-ci ?
Si non, comment pourrait-on faire ça sans passer par un régiment de FREE ?

Je vous remercie.

Peux-tu m'expliquer pourquoi tu souhaites libérer toutes les variables, mais pas les objets, pas les fichiers, pas les évènements ? Ou veux-tu seulement redémarrer le programme comme s'il venait d'être lancé ? Car dans ce cas, il y a des solutions très simples...

En effet, la question laisse perplexe !

Bonjour à tous deux et merci de votre attention.

Voici mon problème et le pourquoi de ma question : Mon programme ouvre une base de données (enregistrée dans un fichier texte) par le menu. L'utilisateur voudra, pour une raison ou une autre, changer de base de données à travailler (= ouvrir un nouveau fichier texte). Lorsque je tente cette manipulation, j'obtiens l'erreur "Variable déjà déclarée" et le programme plante.
Je souhaiterais donc remettre tout à zéro, sans quitter le programme, chaque fois que l'utilisateur cliquera sur le menu "Ouvrir une nouvelle base".

Qu'en pensez-vous ?

Tu as certainement des commandes DIM dans le traitement du clic sur le menu, ce qui marche bien lors de la première fois, mais pose problème lors de la seconde.

Trois solutions:

1. La méthode "brute force": tu scindes ton programme en deux: la partie "sélection" dans un programme, et la partie "traitement' dans un autre. Dès qu'une sélection est faite, tu fais

Code:

execute "partie2.exe "+NomDeLaBase$
terminate

et dans partie2, tu fais tout ce qui'il faut. A la fin, tu fais

Code:

execute "partie1.exe "
terminate

et tu reviens sur ton module de sélection. Plus de problème de gestion de variables.

2. la méthode "douce": demant chaque dim d'une variable, tu insères

Code:

if variable("NomDeLaVariable")=1 then delete NomDeLaVariable

et comme par magie, cela marchera.

3. la méthode "Panoramic": tu déplaces tes déclarations en début du programme, de sorte qu'elles soient exécutées avant la commande END. Ainsi, tu n'as plus de double définition. Et tu fais un sous-programme raz que tu appelles en cas de clic sur un menu:

Code:

label raz
...
' en cas de clic sur le menu:
gosub raz
...
raz:
variable1=...
variable2=...
...
clear objet1...
clear objet2...
...
caption objeti,""
caption objetj,""
...
text objetx,""
text objety,""
...
return

Merci pour la réponse rapide.

La méthode 3 ne peut pas convenir à l'une de mes variables, et c'est d'ailleurs celle qui ne m'aime pas. Il s'agit en effet d'une variable construite par le programme, s'agissant d'un tableau de variables, dont l'indice est calculé en fonction du nombre de lignes du fichier qui est ouvert par l'utilisateur.

Lorsque je tente la méthode 2, elle échoue à cette même variable (Name already defined).
J'ai essayé :

Code:

if variable("actes$(ligne_fichier%)")=1 then delete actes$(ligne_fichier%)
...
dim actes$(ligne_fichier%)

Quant à la méthode 1, elle me fait un peu peur... Mais peut-être qu'il ne me restera plus que cette solution...

Alors, autant dans la solution 2 que dans la solution 3, il faut utiliser la commande FREE pour libérer la variable. Je suis désolé pour l'erreur que j'ai faite en décrivant la méthode 2: la commande DELETE s'adresse à un objet, non à une variable. Pour cela, il faut FREE comme dans l'exemple suivant:

Code:

' première déclaration
dim actes$(20)
actes$(20)="ddd"
' suppression de la variable
free actes$
' seconde déclaration
dim actes$(30)
actes$(30)=yyy
end

Et je pense que tu as la solution à ton problème.

Free est la solution. Ca marche à merveille. Je te remercie encore et encore pour ta disponibilité et... ton savoir !

Ce sujet me conduit à exposer une réflexion que je me fait souvent à propos de EXECUTE.

Dans le langage QB il y a la possibilité d'utiliser (dans le code) RUN sans aucune autre précision. Dans ce cas le programme se relance à la première ligne et remet toutes les variables à zéro.
Je me pose la question de savoir s'il ne serait pas possible d'avoir en Panoramic la commande EXECUTE sans rien préciser et ainsi le programme redémmarerait en faisant un DELETE sur toute les variables, label et sur tous les objets.

A+

C'est un peu brutal, mais tu peux l'obtenir actuellement pour peu que tu connaisses le chemin vers l'exécutable qui est actuellement en cours. Et je parle d'exécutable parce que la commande EXECUTE ne permet de lancer qu'in fichier EXE. Tu fais ceci:

Code:

EXECUTE ce_programme$
terminate

où la variable ce_programme contient le chemin (en nom court) vers le programme actuel.
Evidemment, ce serait plus simple d'avoir EXECUTE sans paramètres, ou plutôt une commande RESTART pour éviter les problèmes de syntaxe sur la commande EXECUTE. On éviterait la difficulté d'obtenir le nom court de l'exécutable en cours.

@Klaus,

J''ai déjà fait l'essai EXECUTE "CE_programme.exe" dans le code de ce même exécutable (comme tu l'indiques) et j'ai constaté que le programme ne repars pas au début, il reprend là ou il s'est arrêté (comme si on avait écrit EXECUTE_WAIT "CE_programme.exe").
J'ai aussi vérifié ce qui se passe au niveau des variables, elles conservent leur dernière valeur connu du programme.
Donc j'ai abandonné cette idée de commander la relance du programme avec EXECUTE.

Par contre ton idée de RESTART serait une solution.
On pourrait aussi imaginer une commande CLEAR_ALL_VARIABLE sans arrêter le programme. (c'est le souci d'Ambroise)

A+

Citation :

J''ai déjà fait l'essai EXECUTE "CE_programme.exe" dans le code de ce même exécutable (comme tu l'indiques) et j'ai constaté que le programme ne repars pas au début, il reprend là ou il s'est arrêté

?????????????????
Impossible. As-tu fait TERMINATE juste après EXECUTE ? Et surtout pas EXECUTE_WAIT ?

Non je n'ai pas utilisé TERMINATE (vu que c'était un essai pour voir ce qui se produisait en relançant le programme par lui-même). Je n'ai pas non plus utilisé EXECUTE_WAIT.
Avec TERMINATE le programme repars et trouve en premier TERMINATE à exécuter (je vois pas l'intérêt).
Bref, l'essai est pour moi est concluant, il ne sert à rien d’utiliser EXECUTE pour qu'un exécutable se relance lui-même, vu qu'il repars juste après EXECUTE et que les variables sont toujours incrémentées.

Je voulais juste voir si cela aurait pu être comme RUN en QB et maintenant je sais que ce n'est pas le cas.

A+

Désolé de te contrdire, mais EXECUTE du même programme suivi d'un TERMINATE relance bien le programme au début, avec son état initial, et toutes les variables sont oubliées. Regarde ceci:

Code:

dim i%, prog$
prog$ = "C:\DOCUME~1\Klaus\MESDOC~1\MESPRO~2\test\TEST_E~2.EXE"
i% = i% + 1
message "i%="+str$(i%)
i% = i% + 1
execute prog$
terminate
end

J'ai appelé mon source test_EXECUTE.bas. Il faut générer l'exécutable sous le même nom, dans le répertoire qui te convient, puis adapter le contenu de la variable prog$ pour avoir le nom court vers cet exécutable. Surtout, ne le lance pas par l'éditeur. Double-clique sur cet exécutable. Tu verras une fenêtre "i%=1" qui s'affiche. Lorsque tu fermes cette fenêtre, après un bref délai, la MEME fenêtre s'ouvre avec toujours "i%=1" et ainsi de suite à l'infini.

Si tu regardes le source, si les variables étaient préservées, i% devrait s'incrémenter, au moins de 1, sinon de 2. Or, ce n'est pas le cas.

Attention: il faut tuer le programme par le gestionnaire des tâches !

Oui Klaus on est d'accord:

Citation :

Avec TERMINATE le programme repars (à cause de EXECUTE prog$) et trouve en premier TERMINATE à exécuter....

En tout état de cause, il n'y aucun intérêt de demander au programme de se relancer lui même en Panoramic, car en fait il n'y a pas de commande spécifique pour cela.

Merci de ta réponse et à plus.

Edit:

Citation :

vu qu'il repars juste après EXECUTE et que les variables sont toujours incrémentées.

là je pensaiis sans terminate