Timer ?

Voila, je continue le développement de mon appli ( sous XP maintenant, hé hé ... ) Et là je tombe sur une autre difficulté, moins sérieuse car je pourrais contourner cette fois, mais pour la beauté du truc, je voulais mettre un d'objet qui serait une sorte de timer qui déclencherait régulièrement un évènement automatiquement toutes les N milli seconde par exemple un peu comme si c'était un bouton qu'on cliquerait mais bien sur sans qu'on ait besoin de venir appuyer dessus vraiment et sans qu'il ne soit visible d'ailleurs. Mais je n'ai pas trouvé, je n'ai trouvé que TIME$, mais il ne me semble pas qu'il puisse déclencher d'évènement.

Car dans mon appli, j'ai un corps de programme qui vas se résumer à une boucle dont le but sera de m'incrémenter une variable de type static en attendant des évènements, de sorte qu'on puisse faire un chronométrage précis entre deux tops venant de l'ellectronique du projet par la carte d'entrée. Donc si j'avais cet objet Timer, ça me permettrais d'éviter un WAIT que je ne sais pas trop comment dimensionner car je ne sais pas le temps que de reste de la boucle va prendre pour s'executer. Cela dit je pense qu'on peu dans une première approximation considérer ce temps négligeable devant celui du WAIT mais forcément ça dégradera légèrement la précision de notre mesure.

Bref, je continue de dévolopper, je vous tiendrais au courant. ...

Amitiés à tous.

Eh oui, le TIMER...
On me l'a déjà demandé plusieurs fois.

Je verrais son utilisation comme cela:

1 - déclaration:
TIMER N
N=numéro d'objet système

2 - activation du TIMER N:
TIMER_ON N

3 - désactivation du TIMER N:
TIMER_OFF N

4 - réglage de l'intervalle entre 2 exécutions du TIMER N:
TIMER_INTERVAL N,T
T est en millisecondes
T=500 par défaut

5 - indication du code à exécuter toutes les T millisecondes pour le TIMER N:
ON_TIMER N,Code_Timer

avec bien sûr le LABEL Code_Timer:

Code_Timer:
- - -
RETURN

Tout cela, c'est pour bientôt. Mais il est vrai qu'on peut contourner l'absence de TIMER par une boucle WHILE / END_WHILE contenant un WAIT

Oui oui, ce serait exactement comme cela qu'il serait à mon avis le plus utile. D'ailleurs à ce propos j'en profite pour te parler d'un truc sur panora que je ne maitrise pas trop :

Quand il y a un évènement de déclenché et qu'il branche à un label, comment sait-on s'il branche avec une sorte de goto label implicite ( qui supposerait donc un branchement définitif ) ou s'il branche avec plutôt une sorte de gosub label implicite ( qui supposerait qu'on puisse mettre comme dans ton exemple, un Return à la fin du code gérant l'exception ) ? Peut-on le choisir ? Sinon, moi ce qui me va le mieux en général c'est le deuxième cas, car sinon je ne sais pas où renvoyer à la fin, puisque je ne sais pas d'où je suis partit, puisque par définition, l'évènement m'est tombé dessus sans que je ne m'y attende. Or dans les tests que j'ai fait jusque-là j'ai eu l'impression que par exemple l'évènement déclenché par le clic d'un bouton à plutôt produit un goto label implicite ( car panora m'a répondu erreur au niveau du return à moins que j'ais mal compris un truc ).

Quand un événement est déclenché, il y a un GOSUB implicite.
Mais il n'y a pas de retour à une quelconque ligne du programme.
Le RETURN qui termine le sous-programme de traitement de l'événement n'a pas d'autre fonction que de terminer l'exécution du sous-programme.
On peut mentalement le remplacer par "END_EVENT" ou quelque chose comme ça.

Le schéma typique est:

LABEL EXECUTE

OBJET N
ON_CLICK N, EXECUTE
- - -
END (fin du programme principal)

EXECUTE:
- - -
RETURN

Il faut bien noter que pour qu'un événement soit exécuté, le programme principal doit être terminé: le END doit avoir été exécuté pour que, à chaque fois que l'événement CLICK sur l'objet N apparait, il y ait exécution du bout de programme commençant pas EXECUTE.

Le mot-clé RETURN porte effectivement à confusion dans ce cas, car il ne renvoie à rien dans le programme principal. Je me demande si END_EVENT ne serait pas plus approprié?
C'est vrai que le mot-clé RETURN est aussi utilisé pour le retour d'un sous-programme appelé par GOSUB (abréviation de GO SUBROUTINE), et là, on "retourne" effectivement juste après l'appel.
Je pourrai mettre les 2 syntaxes dans le prochaines versions, puis un jour, ne laisser que END_EVENT...
Cela, en tout cas, mérite réflexion.

D'accord, c'est plus clair mais alors ça me pose un autre problème ( LOL, tu vas me dire que je suis chiant mais .... ) si le programme principal doit être finit pour qu'on puisse devenir sensible à un évènement alors comment peut-on par exemple mettre un bouton dans un programme qui permette de déclencher quelque chose ? Car si on met un tel bouton, c'est justement parce qu'on ne sait pas dans le programme quand le mec va appuyer dessus à l'extérieur de la machine ? Faut-il prévoir des arrêts périodiques du programme pour laisser cette sensibilité ? Mais alors dans ce cas, si jamais personne n'appuie sur le bouton, comment le programme va-t-il pouvoir repartir après le premier arrêt de contrôle ? Avec un Timer alors sans doute ? Mais dans ce cas ça implique qu'on pense dès le départ, tout le programme en programmation par évènement ou non alors ? Je veux dire qu'on ne doit pas mixer alors ? Cela dit, ça m'irait très bien car intuitivement, je ne sais pas pourquoi mais je conçois plus facilement la programmation de type évènement, seulement dans ce cas, il me faut alors forcément le Timer.

J'ai appelé "programme principal" le programme qui crée l'interface utilisateur. J'aurai pu utiliser le terme "programme créant les objets", cela aurait été plus clair.
Dès que l'exécution de ce programme s'est terminé, tous les événements qu'on a programmé à l'intérieur de ce programme (par ON_CLICK N, EXECN ou par ON_CHANGE N, EXECN) deviennent actifs. C'est seulement à ce moment que que tous les "bouts de programme" qui contiennent le code de traitement d'un événement peuvent s'exécuter de façon totalement asynchrone.

C'est à dire, que dès qu'on va appuyer par exemple sur un bouton de numéro N, il y aura éxécution du "bout de programme" qui commence par le label EXECN:
Mais dans ces "bouts de programme", on peut bien évidemment y mettre n'importe quel traitement sur n'importe que objet.

Pour mieux me faire comprendre, voici un programme très simple qui crée un bouton, puis qui affiche dans le bandeau de FORM0 le nombre de fois qu'on clique sur ce bouton. Exécute le, tu comprendras. (copier-coller dans l'éditeur)

Code:

dim i:rem pour compter le nombre de clicks
label compte

button 1
top 1,30:left 1,30
on_click 1,compte
caption 1,"clique"

rem on pourrait continer à construire l'"interface" mais on s'arrête ici
end

compte:
i=i+1
caption 0,"on a cliqué "+str$(i)+" fois"
return