Que faire d'une attente.

Je me suis plus d'une fois posé la question: Que faire si dans un programme on ne fait rien?

Je m'explique: on arrive au END. On a des trucs à faire, et on les faits. Mais le END n'est-il pas une boucle d'attente?

Ne pourrait-on pas avoir une instruction qui dit: tient cela fait x minutes qui ne se passe rien. Pourrait-on pas en profiter pour faire quelque chose de particulier. Disons au bout de 5 mn, mettre en veille, faire un calcul, en profiter pour faire une sauvegarde, ou que sais-je?

Cela est possible avec un timer, mais ne peut-il pas y avoir une autre possibilité, car un timer, il faut en tenir compte dans tous les codes à cause des détournements.

Ce blocage sur le END m'intrigue, et je pense qu'il pourrait y avoir un détournement pour quelque chose d'autre.

Cela pourrait aussi être le cas par exemple, on appuit sur un combo ou une liste. Si dans 2 secondes il ne se passe rien, alors on met le focus sur un objet pour être traité. Dans le cas contraire on montre le contenu d'un mémo ou autre pour voir si c'est bien là. On peut ainsi différer une commande. Je ne suis pas idiot. Je sais qu'on peut coder ce truc, mais ce serait plus silmple, si cette possibilité existait. Cela ouvrirait d'autres possibilités. Non?

Tenez en pensant au combo: on peut défiler la liste avec la molette, mais si après le clic sur la liste, on met le focus sur une fenêtre, on perd le scroll du combo. J’arrête car on va me mettre un code pour me dire comment on peut faire. Mais là c'est juste une remarque en passant.

Suis-je le seul à penser cela?

Dans l’aide, on peut lire :
« END : cette commande arrête l’exécution du programme principal. Le programme reste actif et traite les événements. »

Mais s’il n’ya pas (ou plus) d’événement à traiter, que fait cette commande ? est-ce des NOP ( NO OPERATION) ?
Y a-t-il une différence entre ces 2 codes (au point de vue comportement du système après l’exécution) ?

Code:

PRINT "Bye"

et

Code:

PRINT "Bye"
END

Oui d'accord, je sais que END est une attente d’événements. Mais allons plus loin. Ne pourrait-on avoir une instruction qui regarde périodiquement si il se passe quelque chose.

Si je prend JustBasic par exemple: la boucle n'est pas constitué, On ouvre
OPEN "titre" FOR windows AS #main
[main.inputLoop]
...processus
goto [main.inputLoop]

[main.END]
end
....

il faut l'intégrer.

C'est la même méthode avec Autoit avec Do - While je crois et une instruction msg() (je vois tellement de code, que je peux mélanger).

Si il y avait une ouverture sur END, on pourrait incrémenter un compteur, ou alors avoir une instruction comme wait_events(2000), qui permettrait de traiter une attente. Je ne sais pas si j'arrive à me faire comprendre.

Cela dit la méthode de Jack par rapport aux autres langage cités, est plus facile à coder, mais on reste figé en attente de traitement.

Techniquement, chaque programme Panoramic que nous pourrons faire, est une routine évènement ! Le programme principal ? L'évènement, c'est el lancement du programme. La commande END dit simplement à l'interpréteur de Panoramic que cette séquence de commandes est terminée. Panoramic se met alors en attente d'un autre évènement, et rend la main à Windows. Rien n'est plus fait en Panoramic - c'est Windows qui est actif. Prochaine action, lorsque Windows envoie un évènement à Panoramic.

En fait, c'est identique à un RETURN d'une routine ON_CLICK. Considère le programme principal par une routine ON_START. Une routine qui ne peut s'exécuter qu'une seule fois.

Oui Klaus, tout cela est compris. Mais en attente d'événement, ne pourrait-il pas y avoir une instruction qui puisse faire quelque chose, si justement on ne fait rien. Je crois que j'ai du mal à me faire comprendre, et que c'est une façon de voir que je suis le seul à intégrer. C'était une simple question.

La seule façon de définir une action qui s'exécute lorsque le programme ne fait "rien", comme tu l'as déjà dit, c'est de faire un timer. Dans la routine du timer, tu le désactives, tu fais ce qu'il y a à faire, puis tu le réactives. Et pour reconnaître si le programme est inactif au moment où cette routine de timer se déclenche, il faut déclarer une variable globale qui serait à zéro en cas d'inactivité, et chaque routine d'évènement du programme, à son début, l'incrémente et à sa fin, le décrémente. Exemple:

Code:

label click, tim
dim actif%, compteur% : actif% = 0
button 1 : on_click 1,click
timer 2 : timer_interval 2,500 : on_timer 2,tim
end

click:
actif% = actif% + 1
message "bouton"
actif% = actif% - 1
end

tim:
if actif%>0 then return
timer_off 2
compteur% = compteur% + 1
caption 0,"Compteur% = "+str$(compteur%)
timer_on 2
return

Lorsque tu cliques sur le bouton, un message s'affiche. Pendant ce temps, le compteur n'est pas incrémenté. Tu peux mettre la ligne 14 en commentaire. Alors, le programme semble se comporter de la même manière. Seulement, après avoir validé le message provoqué par un clic sur le bouton, on constate que le compteur a continué à être incrémenté en arrière-plan, alors que le programme semblait attendre la validatioin du message.

Ceci montre qu'en cas normal, les évènements continuent à être traités, même si une routine évènement est déjà en cours. Et pour s'assurer qu'aucun évènement n'est en cours d'exécution, il n'y a à ce jour que cette astuce avec une variable gérée par chaque routine évènement.

J'ai bien compris que tu voulais faire cela d'une façon plus "élégante". Par exemple, avec une commande du type "ON_INACTIVE_GOSUB label". Cela peut avoir son intérêt. A voir avec Jack.

Merci. Mais Klaus, je sais tout cela. Je crois que j'ai été le premier à me servir du timer pour enclencher un événement. De toute façon ce n'était qu'une simple discution.
Timer est pour moi un événement en parallèle à la boucle interne d'attente END - RETURN.
Moi je pensais qu'une interception sur la boucle interne de end/return, (je pense qu'on peut l'appeler comme cela) serait intéressant. Je vois que e ne peux pas faire admettre le principe, et ce n'est pas grave. Je reste sur mon idée qui me parait bonne, car elle présente des avantages, et je la garde pour moi. Il faut savoir s’arrêter.
Bonne journée! et avec le soleil.

Mais si, Cosmos70 ! Comme ça n'existe pas actuellement en Panoramic, j'ai simplement voulu montrer comment on peut faire cela avec les moyens existants. Tu connais ça, et j'en suis bien conscient, mais j'ai mis le code pour que tout le monde puisse comprendre de quoi on parle.

Ceci dit, à la fin de mon dernier post, j'écris:

Citation :

J'ai bien compris que tu voulais faire cela d'une façon plus "élégante". Par exemple, avec une commande du type "ON_INACTIVE_GOSUB label". Cela peut avoir son intérêt. A voir avec Jack.

Et je maintiens: c'est une fonctionnalité qui peut avoir son intérêt pour certaines applications, et une commande de ce type permettrait de faire cela de façon simple et élégante.

Cosmos, Klaus n'a pas dit que l'idée n'était pas bonne. Juste que techniquement, ce n'est pas évident, ce qui n’empêchera pas, je pense Jack de le rajouter s'il trouve bonne l'idée via un mécanisme interne (genre un timer 'invisible' à l'utilisateur qui suspende tous les autres événements lors de son exécution et les réactive à la fin) si cela est réalisable.

Ok. Je vais devoir partir, donc ce sera mon final.

Je porte cette discussion pour voir si mon point de vue a une valeur.
Voila comment je vois les choses.
Avec un timer on peut faire plein de choses. Mais: un timer est un événement qui intervient à n'importe quel moment, donc peut intervenir pendant un autre événement. On fait un clic par exemple, et on accède au traitement et tout d'un coup, on est détourné. Ce qui oblige de mettre partout des TIMRT_OFF, puis des TIMER_ON à la fin du traitement dans tout le code, et faisant attention de ne pas avoir la même variable dans un timer et le traitement du clic.

Pour un événement d'attente, si il pouvait y avoir "une boite" comme (c'est pas très élégant):
end / boite / end en boucle si il n'y a pas d'événement, tout le trafic de code qu'on rajoute n'a pu lieu d'être . La boite traite cet événement suplémentaire, et là un problème peut-être résolu: avoir de l'événementiel, et travail à côté.

Je me souviens à mes débuts, dès que j'essayais de faire du code en dehors des événements, n'étant pas habitué à ces concepts d'événements, cela posait plein de problèmes. Cela ne marchait pas, et je n'étais pas le seul à essayer de faire ainsi.
Avec cette boite, et peut-être un exit événement en suplément, on peut faire autre chose. je crois.

Je n'ai pas fais cette discussion pour faire une demande, mais pour voir si je suis dans le vrai. Et votre avis est aussi important.