Problème boucle repeat/until -> until ignoré

Bonjour,
je voulais répondre plus rapidement à cosmos au sujet de la gestion des boutons de la souris,
mais je tombe sur un os:
j'ai un problème avec la boucle repeat/until qui n'a pas l'air de vouloir fonctionner dans mon programme...

Code:

dim x%,y%,d%,h%,go%,sortie
dim Bouton_gauche,Bouton_droit
label suite
sortie=0
list 1:width 1,200:height 1,100:print_target_is 1
timer 2:timer_interval 2,2000
on_timer 2,suite


x%=left(1):y%=top(1)
repeat
 if Bouton_gauche=1 then sortie=1
 if Bouton_droit <> 0
  color 1,255,0,0
  x%=mouse_x_position(Bouton_droit-1)
  y%=mouse_y_position(Bouton_droit-1)
  wait 50
 else
    color 1,0,255,0
 end_if
 top 1,y%:left 1,x%
 if scancode=27 then terminate
until (sortie = 1)

terminate
end

suite:
  timer_off 2
  if mouse_right_down(1)=1 then Bouton_droit=2
  if mouse_right_down(0)=1 then Bouton_droit=1
  if Bouton_droit<>0
    if mouse_right_up(1)=1 or mouse_right_up(0)=1 then Bouton_droit=0
  end_if
  if mouse_left_down(0)=1 or mouse_left_down(1)=1
    Bouton_gauche=1
  else
    Bouton_gauche=0
  end_if
  timer_interval 2,100
  timer_on 2
return

et je ne vois pas pourquoi...
l'instruction 'until' à l'air d'être complètement ignorée par Panoramic...

Bonjour NARDO26,

Code:

until (sortie = 1)

La syntaxe serait until sortie = 1.
Mais çà ne change rien

Hello Jean-claude

J'ai fait l'essai avec et sans les parenthèses.
Au final je laissé les parenthèses pour qu'il n'y ai aucune ambiguïté...

Depuis j'ai fait d'autres petits programme de test avec while/end_while et j'ai le même problème... ça doit être lié avec le timer mais je ne vois vraiment pas pourquoi... l'intervalle au départ est initialisé à 2 secondes pour être sûr que je rentre dans la boucle avant que le timer se déclenche. Puis celui-ci remet sa base de temps à 100 ms pour un fonctionnement normal...

Il est probable qu'il y ait un conflit entre timer et repeat...until. J'ai remplacé ces instruction par un label et un if...goto, et le problème disparaît.

Code:

dim x%,y%,d%,h%,go%,sortie
dim Bouton_gauche,Bouton_droit
label suite  , xxx
sortie=0
list 1:width 1,200:height 1,100:print_target_is 1
timer 2:timer_interval 2,2000
on_timer 2,suite


x%=left(1):y%=top(1)
' repeat
xxx:
 if Bouton_gauche=1 then sortie=1
 if Bouton_droit <> 0
  color 1,255,0,0
  x%=mouse_x_position(Bouton_droit-1)
  y%=mouse_y_position(Bouton_droit-1)
  wait 50
 else
    color 1,0,255,0
 end_if
 top 1,y%:left 1,x%
 if scancode=27 then terminate
' until sortie=1
if sortie<>1 then goto xxx

terminate
end

suite:
  timer_off 2
  if mouse_right_down(1)=1 then Bouton_droit=2
  if mouse_right_down(0)=1 then Bouton_droit=1
  if Bouton_droit<>0
    if mouse_right_up(1)=1 or mouse_right_up(0)=1 then Bouton_droit=0
  end_if
  if mouse_left_down(0)=1 or mouse_left_down(1)=1
    Bouton_gauche=1
  else
    Bouton_gauche=0
  end_if
  timer_interval 2,100
  timer_on 2
return

Il n'y a plus le plantage qui se produit avec repeat...until. Ceci dit, je ne vois pas bien ce que le programme fait, car chez moi, quelque soit le bouton appuyé, au-dessus de la liste ou au-dessus de la form 0, il n'y a aucune réaction...

Je regarde rapidement, et je vais te dire pourquoi il y a problème:

Tu utilises et je crois que c'est à toi que je l'ai déjà dit le timer qui est une fonction événementielle, alors que le reste des instructions n'est pas fait.
D'abord tu mets terminate avant end, le end ne sert à rien!.
Il faut mettre le on_timer lorsque tout est installé, par ce que tu le lance au départ, et la procédure utilisant le timer, au return ne trouve pas le end.

A propos: terminate mets le à la fin du programme, il ne déclenche pas de boum à cet endroit.

j'arrête j'ai plus le temps

J'ai refait le programme en utilisant l'indication judicieuse de Cosmos70, et voilà le résultat:

Code:

dim x%,y%,d%,h%,go%,sortie
dim Bouton_gauche,Bouton_droit
label suite  , start
sortie=0
list 1:width 1,200:height 1,100:print_target_is 1
timer 2: timer_off 2 : timer_interval 2,100
on_timer 2,suite

button 3 : top 3,10 : left 3,200 : caption 3,"Démarrer" : on_click 3,start
end

start:
timer_on 2
x%=left(1):y%=top(1)
repeat
 if Bouton_gauche=1 then sortie=1
 if Bouton_droit <> 0
  color 1,255,0,0
  x%=mouse_x_position(Bouton_droit-1)
  y%=mouse_y_position(Bouton_droit-1)
  wait 50
 else
    color 1,0,255,0
 end_if
 top 1,y%:left 1,x%
 if scancode=27 then terminate
until sortie=1

terminate

suite:
  timer_off 2
  if mouse_right_down(1)=1 then Bouton_droit=2
  if mouse_right_down(0)=1 then Bouton_droit=1
  if Bouton_droit<>0
    if mouse_right_up(1)=1 or mouse_right_up(0)=1 then Bouton_droit=0
  end_if
  if mouse_left_down(0)=1 or mouse_left_down(1)=1
    Bouton_gauche=1
  else
    Bouton_gauche=0
  end_if
  timer_interval 2,100
  timer_on 2
return

Excuse moi Klaus, j'ai pas le temps, constamment pris par le temps.
voici un code pour tester le timer.

Code:

'  pour les codes provisoirs:      chain C:\TESTE\fichiers_teste\controle.bas
label time:dim a%
  caption0, "appuyer sur escarpe et cliquez sur la croix pour arrèter"
timer 1: on_timer 1,time
timer_interval 1,100
for a%=1 to 100000:print a%:next a%
button 2
end
time:
  left 2,100
  if scancode=27 then stop
return

à plus tard

il y a un truc que je trouve étrange avec scancode, en principe, d'après la doc, SCANCODE retourne le code de la touche actuellement enfoncées, hors çà n'a pas l'air d'être le cas.
Pour vérifier (avec le code de Klaus) appuyer en premier sur la touche Echap (scancode 27) et ensuite sur le bouton démarrer.

Je crois qu'il y a un BUG.

A+

@Jean Claude
Tu es dans l'erreur. Comment veux-tu qu'il fonctionne?
Tu as on_timer 2,suite. C'est le seul branchement que tu as, et scancode n'est pas dans la sub suite.
Pour que scancode soit sollicité, il faut appuyer sur le bouton afin d'aller dans start.

Afflelou c'est pour toi, cette fois-ci!
@+

Je m'excuse d'avance cosmos,
car je dois te paraitre borné mais je pige toujours pas :


Ok, en fait au départ, je n'avais pas d'instruction terminate,
mon prog se terminait sur end. en faisant plusieurs essais j'ai rajouté le 'terminate' car je ne voulais pas rester bloqué par le timer (ce qui arrive si j'arrête le prog sur 'end').
Mais il est vrai que j'aurais du enlever le end... comme j'avais mis le terminate avant,
le 'end' n'avait plus d'importance.

Cosmos dis : "Il faut mettre le on_timer lorsque tout est installé"
ben lorsque je déclare le on_timer tout est en place: les variables, les objets...
et que je me donne une marge de 2 secondes (2000 ms !!!) pour permettre au prog séquentiel d'être dans la boucle (ce qui d'ailleurs n'a aucune importance)
il faut plus de 2 secondes pour exécuter la ligne : x%=left(1): y%=top(1) ?
Attend cosmos !! je t'entend déjà crier, regarde de que j'écris ci-dessous :

Ne dois-je pas considérer le fonctionnement d'un timer comme étant l'équivalent de celui d'une IT ?
si oui, le return doit renvoyer à l'endroit où le programme séquentiel est interrompu.
ce qui se fait depuis la nuit des temps (opcode rti,etc...)

Un truc que je ne pige toujours pas: je sais que mon prog n'a rien d'évènementiel (en dehors du timer lui-même).

Pourquoi n'ai je pas le droit d'avoir en un programme séquentiel avec une boucle infinie par exemple et d'utiliser en meme temps un timer (qui lui se déclenche à partir d'une base de temps)?
Le timer n'est lié à aucun objet. Il ne fait que scruter des boutons de souris et de mettre à jour des variables.

C'est pas dur Nardos, et je pense ne pas me tromper, et la réflexion est l'observation des évènements depuis que je suis sur Panoramic.
Timer agit en mode évènement, et pour que cela fonctionne bien, lorsque qu'il finit son sous-programme, il lui faut le end pour se brancher.

D'après ce que j'ai déjà remarqué, et les problèmes ne sont pas apparent pour moi depuis aujourd'hui, il y a toujours eu un problème en faisant un programme non évènementiel avec une instruction évènementiel. Pourquoi, il n'y a que Jack qui peut le dire.

Maintenant tu dis qu'il faut 2 secondes pour que le timer se déclenche. Peu importe le temps, mais peut-être que cela ne se passe pas comme tu dis. Il peut très bien prendre son adresse de départ, il s'enclenche, mais n'agit qu'au bout de son temps.

De toute façon, l'emplacement de ce type de code agit différemment selon l'endroit où tu le mets. Ton programme tu fais comme tu veux, mais les problèmes il faut les assumer. Moi je te donne une façon de faire, qui fonctionne, et c'est le fruit d'observation et de teste. Si tu veux faire d'autres testes pour voir d'autres choses, tu dois assumer les conséquences. Panoramic est en construction, rien n'est vraiment fini, une instruction qui fonctionne pour une version, il n'est pas certain qu'il n'y ait pas de problème pour la version suivante. Pour l'instant, il faut faire les programmes, en suivant les possibilités du basic.

A ceci, j'ajoute que normalement le programme se lit ligne par ligne, ça c'est normal. Mais si tu ajoute dans le code un moment donné une instruction comme timer, qui lui est indépendant du programme, il peut y avoir des surprises. Donc pour moi, agissant logiquement, je mets tout en place, ensuite le lance le timer. C'est pas compliqué, et les problèmes que tu dis disparaissent

J'en connais pas plus que les vous autres. Je suis seulement observateur, et j'agis selon ce que je vois. Le fonctionnement à l'intérieur du basic, lui reste obscure.

Tout ceci n'est pas méchant de ma part, c'est juste ma façon d'expliquer.
Salutation

@COSMOS, je suis pas d'accord...

Citation :

Pour que scancode soit sollicité, il faut appuyer sur le bouton afin d'aller dans start.

Justement, c'est là le problème car si tu commence par appuyer sur Echap (une fois le programme lancé) et que tu cliques sur le bouton démarrer après, le programme s'arrête. Donc l'enfoncement de la touche Echap a éte pris en compte et est resté en mémoire.

Pour moi soit c'est un BUG ou il faut modifier le manuel en stipulant que scancode retourne le code de la dernière touche (ou click_mouse) enfoncée et non pas actuellement enfoncée.

Je pense que tu n'as pas fait l'essai. Fais-le et dit-moi ce que tu en penses.

A+

Excuse-moi, mais je trouve ça normal, Jean-Claude
Je m'explique:
a t1:
scancode=27
a t2:
'touche "Démarrer"'

Bon, cela étant dit, étant donné que le code 27 est associé à terminate, au moment t1, le programme traite d'abord ce terminate, ce qui fait, qu'il ne prend pas en compte la touche 'Démarrer' en t2 (il est occupé à autre chose)..



En tout cas, je trouve ça logique

Tout à fait exact Flowerkinzy. L'appui sur scancode met l'appui dans la queue de file, comme tout autre fonction de windows. Si tu appuis sur la fermeture de ton navigateur, pendant qu'il cherche, lorsque celui-ci aura terminé sa tâche, la tâche suivante est la fermeture, et c'est ce qu'il fait.

@Nardo26:

Cosmos70 a parfaitement exposé le problème de fonctionnement en linéaire et en évènementiel. Et tu te trompes si tu dis que l'instruction "end" est inutile dès que tu as exécuté "terminate". Ces deux instructions ont un fonctionnement totalement différent, et sont totalement indépendantes l'une de l'autre.

L'instruction "terminate" arrête le processus Windows. La seule chose exécutée après un terminate est éventuellement une routine on_close spécifiée sur la form 0. Le return de cette routine est alors le signal pour l'arrêt effectif.

L'instruction "end" est en fait très mal nommée, et je pense qu'elle s'appelle ainsi pour des raisons historiques. Elle s'appellerait beaucoup plus justement "event_mode_on" ou quelque chose de simulaire. Elle fait deux choses: elle bascule du mode linéaire en mode évènementiel, et ensuite, elle passe la main au noyau de Panoramic. Et c'est Ce noyau qui reçoit alors tous les évènements en provenance de Windows, et si une routine d'évènement est déclarée pour un évènement arrivant, alors le noyau appelle cette routine; sinon, l'évènement est perdu.

Donc, un programme devrait être conçu de la manière suivante:

1. toutes les déclarations de labels (instruction label)
2. toutes les déclarations de variables (instruction dim)
3. toutes les déclarations de data (instruction data)
4. construction du GUI (Graphic User Interface, c'est le dessin du ou des écrans)
Toutes les forms devraient être définies ici, et éventuellement cachées si elles ne doivent pas être apparentes dès le départ. C'est ici qu'il faut créer tous les objets, les affecter à une form etc. C'est ici qu'on spécifie toutes les routines d'évènement (on_click, on_change, ...). Il est conseillé de DESACTIVER les timers créés ici pour le moment (par timer_off N)
5. Réalisation de toutes les initialisations, lecture de fichiers paramètres, chargement des listes, combos etc, valeurs initiales de certaines variables etc, bref tout ce qui doit être mis en place AVANT que le programme ne démarre vraiment
6. activation du ou des timers requis dès le départ (par timer_on N)
7. instruction END
A partir de maintenant, le programme est en mode évènementiel et ne réagit plus qu'aux évènements (clic sur un bouton ou un autre objet, saisie de données dans un édit, évènement timer etc. Pour tous ces évènements, une routine doit être prévue, son label déclaré en (1) et son action définie en (4).
8. toutes les routines évènement, commençant par un label et terminant par un return. Normalement, une routine d'évènement devrait se suffire à elle-même: elle ne doit pas faire un goto en-dehors d'elle-même et en particulier pas dans une autre routine évènement car cette dernière pourrait être appelée, en cours d'exécution, par son propre évènement et ces routines ne sont PAS réentrantes !
9. toutes les routines de service appelées soit par le code linéaire (en phases (4), (5) et (6)), soit par une routine d'évènement à condition qu'elle ne puisse pas être appelée par une autre routine d'évènement (voir en ().

La directive #INCLUDE peut bien sûr se trouver n'importe où, même à plusieurs endroits, à condition que le programme complet, une fois les #INCLUDE effectués, le programme résultant respecte les règles ci-dessus.

Bon, voilà un bien long exposé, mais l'instruction "end" la mal-nommée mérite bien cela !

@florenski et Cosmos

Pour moi le Timer n'est pas en cause.

J'ai ouvert un nouveau sujet pour ne pas gêner sur ce post.

A+

@Klaus:
Merci pour cet exposé. C'est un peu plus clair dans ma tête.
Je me suis fait piégé par l'instruction 'end' qui en fait correspond à un 'end' de déclaration qui informe le "scheduler" comme quoi l'applic est initialisée et qu'il peut prendre la main pour dispatcher les différents évènements...
Comme tu dis : event_mode_on serait en fait plus approprié...

C'est tout à fait cela. Avec cette idée en tête, on ne se fait plus piéger et on peut tirer des choses formidables de Panoramic !

C'est vrai que maintenant, c'est devenu chez moi un reflexe et mentalement j'assimile END à fin de mise en place du programme. Toutefois il m'arrive de m'en servir pour forcer le programme à attendre un nouvel événement.
A+

Effectivement, un programe peut contenir plusieurs "end". Mais je pense qu'en réalité, cela agit exactement comme un "return" à la fin d'une routine d'évènement, sauf qu'un peut être dans les profondeurs d'un empilement de sous-programmes, et "end" agit de suite.

Mon ordi en ce moment je ne sais ce qu'il fait mais ça fait au moins 1/2 heure qu'il tourne sans que je puisse avoir la main.
Donc je poste ici sans savoir si c'est la suite de la page précédente.

En répondant sur scancode avec le clic souris, l'idée m'est venu de me servir de scancode au lieu de mouse_right_down ou up, et les problèmes que j'avais cités, qui étaient que je n'arrivais pas à me séparer du clic une fois relâché, ont disparus.

Code:

dim x%,y%,d%,h%,go%
label suite
list 1:width 1,200:height 1,100:print_target_is 1
timer 2:timer_interval 2,100
on_timer 2,suite
end

suite:
  if scancode=2
  timer_off 2 
  repeat
      color 1,255,0,0
      x%=mouse_x_position(0)
      y%=mouse_y_position(0)
      top 1,y%:left 1,x% 
      if scancode=27 then terminate
      wait 20
      if mouse_right_up(1)=1 then exit_repeat
  until scancode=0
  end_if
  timer_on 2
return
' =============

Excusez moi si c'était un autre poste, mais j'ai assez perdu de temps comme cela!
Merci

Et çà marche, bravo Cosmos.