RÉSOLU (pas de queue de files des sub) aucun bug

Depuis que les nouvelles versions ont sortie avec la file d'attente, il y a eu des amélioration concernant certains objets, et le traitement d'événement. Cependant je constate constamment des problèmes de traitement sur lesquelles je ne m'y attendais pas. Plus d'une fois j'ai voulu mettre en avant les problèmes. Mais comment? Chaque fois qu'un problème apparait, je me débats pour le résoudre, et modification après modification, il ne reste rien à dire. Aujourd'hui, j'ai constaté dans une procédure dans une boucle for/next, j'ai mis repeat:until scancode =27. en suivant les variables pas à pas. A chaque fois que la boucle était fini, elle recommençait, et je ne m'en sortait pas. En supprimant le teste avec repeat/until, le programme fonctionnait correctement.
Un autre cas, celui que je présente maintenant, dont j'ai enfin pu établir le problème. J'en dis pas plus la lecture du code et les essais montreront le problème.

Code:

rem essai les appels aux sous programmes, et le résultat

dim choix%,a$
label attente,oui,non,essai

button  1  :caption 1,"essai":on_click 1,essai
          ' -----------------------------
          ' création de la boite d'attente
form  11  :hide 11:top 11,300:left 11,800:width 11,350:height 11,120:color 11,237,232,124:border_small 11
            caption 11,"essai de la boite"
alpha  12  :parent 12,11:top 12,10:left 12,20:width 12,180:font_size 12,10:font_bold 12
button 13  :parent 13,11:top 13,50:left 13,60:caption 13,"oui":on_click 13,oui
button 14  :parent 14,11:top 14,50:left 14,160:caption 14,"non":on_click 14,non

            a$= "normalement en cliquant sur essai, je devrais voir la boite de choix"+chr$(13)
            a$=a$+"y répondre, et voir ensuite le message sur le bouton choisi"
            message a$
end
' ==============================================================================
essai:
  rem    "volonté de faire un choix pour faire une tâche ou une autre"
  gosub attente
  message "choix%="+str$(choix%)
return

attente:
  show 11
  inactive 0
return

oui:
  choix%=1:active 0:hide 11
return
non:
  choix%=2:active 0:hide 11
return

Je me demande si il y a des programmeurs sur ce site. Je montre un vrai problème de programmation et comme toujours pas de réaction, seulement sur des sujets qui sont moins grave.
Pourquoi l'exemple que je montre est grave? Cela fait près de 2 mois que je constate dans des programmes, des choses aberrantes dont je ne connais pas la cause. Certe je ne suis pas un vrai programmeur, et pour certain d'entre-vous je suis certainement un ..., mais jusqu'à présent, lorsque je faisais un programme, il suivait les instructions dans l'ordre de leur lecture. La volonté de mettre les routines en queue de file est une chose normale et logique. On termine le travail en cours, et on fait la suite une fois la tâche terminée.
Vous qui optez pour des includes, êtes-vous certain qu'il vont fonctionner normalement, si l'appel aux sous programmes, sont mis de côté, et ne seront exécutées, qu'une fois que le programme arrivera au <return> de la procédure en cours?
Dans l'exemple que j'ai mis sur le forum, même en modifiant la procédure
'essai' comme cece

Code:

essai:
  choix%=0
  gosub attente
  repeat:until choix%>0
  message "choix%="+str$(choix%)
return

il y a problème, parce que le programme est bloqué.
La méthode Panoramic pourrait très bien restée comme elle est, mais dans ce cas une instruction du genre GOSUB_WAIT s'impose. Autrement, on ne s'en sortira pas (où alors, c'est l'instruction GOSUB qui est à revoir).
Je pense que ce que je présente ici est majeur, parce qu'il est inconcevable que l'on puisse programmer sans avoir de contrôle sur l'ordre des évennements du programme..
Une chose: lorsque je mets un post sur un problème, ne regardez pas si cet "cosmos70" qui pose ce post, (on s'en fout, pour moi je n'ai pas de valeur), mais regardez précisément ce qu'il y a dedans.
Autre chose: je peux très bien faire une erreur de programmation, si c'est le cas, personnellement j'essaye de corriger les erreurs des autres.
Si il n'y a plus d'intervention sur les problèmes que je pose, ne soyez pas surpris que les miennes soient mauvaises. J'ai aimé Panoramic, parce que le principe même est intelligent, et compréhensif par tous. Mais maintenant je perds mon temps, et tout ce que je dis n'a en fait pas d'importance. Je vais regarder vos réactions (en rapport avec le problème, et non avec moi) si je vois que cela est sans réponse, il y aura un Panoramicien de moins, et c'est bien dommage, parce que Jack se démène comme il peut.

Bonjour,

Je vais essayer de te répondre pour ton problème avec les sous-programmes.

Il ne s'agit pas d'unb problème de file d'attente. Panoramic fonctionnne bien dans la logique à laquelle on peut s'attendre et que tu réclames, à savoir l'exécution, l'une après l'autre, des instructions. Un gosub est une instruction qui entraîne l'exécution de la première instruction du sous-programme et le prgramme appelant ne continue PAS immédiatement après le gosub. Ce n'est qu'après le return dans le sous-programme que l'instruction suivante est exécutée.

Ton problème vient en fait d'une mauvaise compréhension de la programmation par évènements. Je m'explique: dans ton programme, en cliquant sur "essai", tu actives la form 11 qui s'affiche bien. Tu désactives la form 0 et tu crois qu'elle s'arrète dexécuter. Que nenni - elle ne reçoit simplement plus d'interaction par les objets (click, survol de souris, frappe au clavier etc). Tous les évènements sont dirigés vers la form 11.

Or, dans ta routine essai, tu as l'instruction message qui t'affiche le résultat de la form 11 qui ne peut pas encore être prêt puisqu'il n'y a pas encore eu d'action de souris sur cette form. La fenêtre de message s'affiche bien (en bas à droite de la form 0), mais c'est pas le bon moment pour l'afficher. Tu ne peux l'afficher que par un évènement qui le déclenche.

Il faut donc déplacer ton instruction message comme dans la version modifiée que je poste ici:

Code:

 rem essai les appels aux sous programmes, et le résultat

dim choix%,a$
label attente,oui,non,essai

button  1  :caption 1,"essai":on_click 1,essai
          ' -----------------------------
          ' création de la boite d'attente
form  11  :hide 11:top 11,300:left 11,800:width 11,350:height 11,120:color 11,237,232,124:border_small 11
            caption 11,"essai de la boite"
alpha  12  :parent 12,11:top 12,10:left 12,20:width 12,180:font_size 12,10:font_bold 12
button 13  :parent 13,11:top 13,50:left 13,60:caption 13,"oui":on_click 13,oui
button 14  :parent 14,11:top 14,50:left 14,160:caption 14,"non":on_click 14,non

            a$= "normalement en cliquant sur essai, je devrais voir la boite de choix"+chr$(13)
            a$=a$+"y répondre, et voir ensuite le message sur le bouton choisi"
            message a$
end
' ==============================================================================
essai:
  rem    "volonté de faire un choix pour faire une tâche ou une autre"
  gosub attente
rem  message "choix%="+str$(choix%)
return

attente:
  show 11
  inactive 0
return

oui:
  choix%=1:active 0:hide 11
  message "choix%="+str$(choix%)
return
non:
  choix%=2:active 0:hide 11
  message "choix%="+str$(choix%)
return

et tu verras que ton programme fonctionne comme tu le souhaites.

Je résume: les instructions active et inactive ne suspendent jamais une form (ou un objet en général). Elles empèchent simplement cet objet de recevoir des interactions utilisateur.

Si tu veux conditionner un bout de code par une action, il faut placer ce code (ou l'appel s'un sous-programme exécutant ce code) DANS le code de traitement de l'action concernée, en général dans la routine on_click ou similaire qui déclenche l'action. Tu ne peux JAMAIS attendre dans une autre partie du programme, par une boucle par exemple, qu'une variable change de valeur ou quelque chose de similaire. Cela conduit inévitablement à un bloquage total du programme, car on se trouve en consommation pure de temps d'unité centrale et l'évènement attendu ne pourra peut-être même plus se produire car le programme ne pourra simplement plus y réagir.

Garde bien en vue ceci:
dans les vieux basic come Qbasic, Basic11 etc, on exécutait de façon linéaire, on affichait ce qu'on voulait, et on avait une interaction avec l'utilisateur uniquement lorsque le programme de demandait (par un input ou similaire), donc, lorsque le programme s'y attendait.
Dans Panoramic (comme dans d'autres langages (Visual Basic, Delphi, etc) on a un programme d'initialisation qui ne s'exécute qu'une seule fois, puis passe la main au "système" qui est alors en attente d'un "évènement". Ces évènements peuvent concerner d'autres programmes (click sur une autre application, la barre de tâches, ...) ou un objet de la form Panoramic active. Le "système" appelle alors la routine évènement (en général, la routine on_click) qui s'exécute SANS que le reste de l'application le sache, et lorqu'elle fait son return, l'application a perdu la main au profit du "système". Il faut donc que toute routine évènement fasse absolument tout ce qu'elle est censé faire ou déclencher; elle ne peut pas assumer qu'une autre routine prendra la main derrière elle.

J'ai été un peu long, mais j'espère que tu verras un peu plus clair maintenant. Ne te décourage-pas - c'est une habitude de programmation à prendre, et elle donne finalement une bien plus grande liberté de programmation que la méthode ancienne, où il fallait tout prévoir et faire des débranchements dans tous les sens pour déclencher des traitements spécifiques à un cas de configuration précis; en cas de rajout d'une fonction, il fallait quelque fois revoir complètement la logique du programme principal. Avec Panoramic, tu rajoutesune fonction avec un nouvel objet de type bouton et sa routine on_click, et tu n'as absolument pas à toucher à la structure globale du programme.

Bon courage - cordialement Klaus

Bonjours Klaus.
Je te remercie de m'avoir répondu, et ça m'encourage de rester ici.
Ce que tu dis es très bien, d'autant que je l'avais fais pour contrôler, mais cela ne résout rien. Connaitre le message dans oui ou non, ne me convient pas. Ce que je veux, est dans une procédure, de la stopper pour faire un choix, donc aller ici à attente, de connaitre le résultat, et de continuer. Dans les d'autres basics, cela se fait sans problème, mais avec Panoramic, on a rien pour arréter un programme dans une exécution. Si on mets que j'ai fait plus haut une boucle avec repeat/until, il y a blocage du programme.
En réalité, j'ai résolu le problème d'une autre façon: j'ai fais un petit programme, d'ailleur je vais le mettre ici, cela peut servir à des nouveaux:

Code:

dim choix%
label attente,oui,non,fin
          ' création de la boite d'attente
          top 0,300:left 0,800:width 0,360:height 0,130:color 0,237,232,124:border_small 0
          caption 0,"essai de la boite"
alpha  12  :top 12,10:left 12,20:width 12,180:font_size 12,10:font_bold 12

button 13  :top 13,50:left 13,90:caption 13,"oui":on_click 13,oui
button 14  :top 14,50:left 14,190:caption 14,"non":on_click 14,non
dlist 15
file_load 15,"transfert.txt"
caption 12,item_read$(15,1):clear 15
end
attente:
  choix%=0
  repeat
    if clicked(13)=1 then choix%=1
    if clicked(14)=1 then choix%=2
  until choix%>0
return

oui:
  choix%=1
  item_add 15,"1"
  goto fin
return
non:
  choix%=2
  item_add 15,"2"
  goto fin
return
fin:
file_save 15,"transfert.txt"
terminate

programme qui est exécutable (exe), et je fais appel de la boite comme ceci: la boite est enregistrée comme ceci: "boite_2_boutons.exe"

Code:

  clear 15:item_add 15,"Etes-vous sûre de vouloir changer le codage?"
  file_save 15,"transfert.txt":    execute_wait "boite_2_boutons.exe"
  file_load 15,"transfert.txt" :' récupère 1) pour oui ou 2) pour non
  if item_read$(15,1)="1"
etc.....

je transmets le titre du caption de la boite à travers un fichier: "transfert.txt", après fermeture de la forme, je récupère le paramètre du bouton.
Je pense que execute_wait est une bonne approche pour demander une instruction du genre GOSUB_WAIT, cela fait bizarre, mais au moins, on a un arrêt du programme, qui permet de lire un évènement, et de continuer. Peut-être avec ce genre d'instruction, faudrait-il une autre pour débloquer Gosub, je ne sais pas. Je crois que le gros problème est qu'il y a le blocage de Panoramic trop facilement. Avec les autres basics que j'ai utilisé, il n'y avait pas de problème. Tu connais une façon avec Panoramic, d'interrompre comme j'ai voulu faire ici, de faire une tâche et de continuer??? Les boucles ne fonctionnent pas, ça bloque pour de bon. Vraiment Panoramic a besoin d'une bonne instruction pour cela. Il est vrai que Jack va sortir d'ici peut de nouvelles boites de message, et ici le problème sera résolu. Mais il y a d'autre cas que de vouloir faire un choix entre 2 boutons, et là le problème sera encore présent.

Je reviens à mes explications du poste précédent.

Ce qu'il faut faire, c'est de faire un sous-programme indépendant pour la suite du traitement, après ce que tu appelles "attente". Exemple:

Code:

 rem essai les appels aux sous programmes, et le résultat

dim choix%,a$
label attente,oui,non,essai
label suite,module1,module2

button  1  :caption 1,"essai":on_click 1,essai
          ' -----------------------------
          ' création de la boite d'attente
form  11  :hide 11:top 11,300:left 11,800:width 11,350:height 11,120:color 11,237,232,124:border_small 11
            caption 11,"essai de la boite"
alpha  12  :parent 12,11:top 12,10:left 12,20:width 12,180:font_size 12,10:font_bold 12
button 13  :parent 13,11:top 13,50:left 13,60:caption 13,"oui":on_click 13,oui
button 14  :parent 14,11:top 14,50:left 14,160:caption 14,"non":on_click 14,non

            a$= "normalement en cliquant sur essai, je devrais voir la boite de choix"+chr$(13)
            a$=a$+"y répondre, et voir ensuite le message sur le bouton choisi"
            message a$
end
' ==============================================================================
essai:
  rem    "volonté de faire un choix pour faire une tâche ou une autre"
  gosub attente
rem **** ici, il n'y a plus rien à faire !
return

suite:
rem **** ici, il y a la suite du traitement, comme si on y arrivait après l'attente !
if choix=1 then gosub module1
if choix=0 then gosub module2
rem ...
return

module1:
rem  message "choix%="+str$(choix%)
rem ...
return

module2:
rem  message "choix%="+str$(choix%)
rem ...
return

return

attente:
  show 11
  inactive 0
return

oui:
  choix%=1:active 0:hide 11
  gosub suite
return
non:
  choix%=2:active 0:hide 11
  gosub suite
return

Et comme cela, tout se tient dans un seul programme, pas besoin de passer par execute, et on respecte la logique des "évènementsé.

Merci pour tes efforts. Un vrai Pro.
Salutation

Je regarde de nouveau tes explications. La résolution que tu proposes, est justement celle que je voulais éviter.
J'ai fais une forme avec 2 boutons, justement pour qu'elle me serve dans plusieurs appels. Or les réponses sur oui ou non résolvent la demande, mais est tributaire d'un seul appel. Et c'est pour cela que je tique. Quand je fais ce genre de sous programme, c'est pour que l'appel de celui-ci soit une généralité des différents modules qui en ont besoin. Je vois, tu vas me dire: il suffit avant de l'appeler de faire on_click (oui),mon traitement. Mais ce serait tellement plus simple, de pouvoir arrêter une procédure, pour chercher une info, et dès qu'elle est acquittée, de continuer. T'es pas d'accords avec moi, que ce que je propose serais une facilité. As-tu essayé de faire entre autre un essai, d'arrêter
J'ai un petit exercice pour toi, pour que tu puisses dire que je n'ai rien compris.

Code:

width 0,500:height 0,500
dim a%,b$
label essai,go,fin

button 1 :left 1,250:caption 1,"a%=10":on_click 1,go
memo  2
button 3 :left 3,250:top 3,60:caption 3,"stop":on_click 3,fin

on_click 0,essai:hint 0,"cliquez sur la forme pour voir le résultat"
end
rem "votre mission, si vous l'acceptez est de cliquer sur le bouton a%=10, et de voir le résultat"
rem "en appuyant sur ce bouton, normalement on met le compteur a% à 10, ok?. Si maintenant je clique"
rem "sur la forme, je dois me brancher au sous/prog essai. Théoriquement, que dois-il se passer?"
rem "je sens que je vais aller me coucher, je suis un peu trop fatigué pour réfléchir."

essai:
  input b$
  item_add 2,a%
return

go:
  a%=10
return

fin:
terminate

Résolution du problème
Cette fois ci, cela suit ma logique, et la boite de bouton, peut servir ailleurs.

Code:

dim choix%,a$
label attente,essai

button  1  :caption 1,"essai":on_click 1,essai
          ' -----------------------------
          ' création de la boite d'attente
form  11  :hide 11:top 11,300:left 11,800:width 11,350:height 11,120:color 11,237,232,124:border_small 11
            caption 11,"essai de la boite"
alpha  12  :parent 12,11:top 12,10:left 12,20:width 12,180:font_size 12,10:font_bold 12
button 13  :parent 13,11:top 13,50:left 13,60:caption 13,"oui"
button 14  :parent 14,11:top 14,50:left 14,160:caption 14,"non"

            a$= "normalement en cliquant sur essai, je devrais voir la boite de choix"+chr$(13)
            a$=a$+"y répondre, et voir ensuite le message sur le bouton choisi"
            message a$
end
' ==============================================================================
essai:
  rem    "volonté de faire un choix pour faire une tâche ou une autre"

  repeat:until scancode=0  :rem "efface le click précédent"
    gosub attente
  repeat
  until scancode=1            : rem "attente du click gauche de la souris"
  message "choix%="+str$(choix%)
return

attente:
  show 11
  inactive 0:choix%=0
  repeat
    if clicked(13)=1 then choix%=1
    if clicked(14)=1 then choix%=2
  until choix%>0
  active 0:hide 11
return

Bonjour, cosmos70,

J'ai regardé les deux derniers codes que tu as postés.

Le premier mène à un magnifique plantage - même avec écran bleu et reboot de XP ! En fait, Panoramic perd complètement les pédales avec l'instruction input: ne pouvant pas contrôler sur quel objet arrivent les évènements, il ne peut pas servir l'instruction input correctement. Cette instruction n'a un vrai sens que dans la partie initialisation d'un programme Panoramic (entre le début et l'instruction "end"). Là, l'ordre d'exécution est bien établi et correspond à ce que l'on connaissait avant, dans Qbasic par exemple: un mode linéaire. Mais je vois que tu as déjà participé souvent aux discussions autout de input et tu préconises toi-même d'utiliser un objet edit pour les entrées. En tout cas, l'instruction input dans une routine de traitement d'évènement est à prohiber. J'ai décalé ton mémo un peu pour voir le haut de la form, et j'ai rajouté un input_mark_on au début du programme. Résultat: on voit apparaître un premier "?", puis (de façon aléatoire) des caractères que l'on tape, et après le premier return, c'est fini - le programme est planté. Il faut utilisar control/alt/suppression pour l'arrêter.

Ton deuxième programme est intéressant. Mais attention: tu sors de la logique de Panoramic ! La preuve: si tu fermes ta boite en cliquant sur la croix rouge, ton application est bloquée... De plus, en attendant le click, tu consommes du temps de l'unité centrale à gogo.

Tu essaies de réaliser une gestion des évènements "maison" par un gestionnaire créé par toi. Il est élégant et effectif, mais il courcircuite ce que Panoramic a déjà mis en place et qui constitue l'essence même de Panoramic. Comme le gestionnaire d'évènements de Panoramic continue de fonctionner pendant ce temps-là, cela ne peut que conduire à des problèmes. Tu ne le vois pas forcément avec le petit exemple par lequel tu illustres très clairement ta technique, mais si tu l'emploies à plus grande échelle dans un vrai programme, je te souhaite bien du plaisir !

Tu fais bien sûr comme tu l'entends, et chacun a évidemment droit à sa propre méthode pour réaliser ses programmes. Je voulais simplement montrer que Panoramic a une façon qui lui est propre de gérer ce genre de problèmes, et de s'y adapter permet d'une part de ne pas réinventer la ficelle à couper le beurre, et d'autre part de s'éviter des problèmes d'incompatibilité de gestion.

Ne prends surtout pas cela comme une critique - c'est pas du tout mon objectif.

Contrairement à ce que tu crois, ton approche et tes points de vue ont toujours été intéressant pour moi, parce que tes remarques sont pertinentes, et réfléchies, de plus tu prends beaucoup de mal pour bien expliquer les choses (au contraire de moi)
Cela dit, si clicked existe, à quoi elle sert, si il ne faut pas l'utiliser Quant aux ressources, permet moi de te dire que j'ai un ordi qui me le fait comprendre lorsque je suis en boucle, mais beaucoup moins depuis que j'ai utilisé une nouvelle session.
Théoriquement, lorsqu'on fait appel à ce type d'événement, c'est pour y répondre tout de suite, je ne vois pas en quoi il faut réfléchir midi à quatorze heures pour affirmer un choix (surtout que ce type d'appel fait suite à sa propre demande comme: "estes-vous certain de vouloir sauvegarder?"), et les ressources ne sont que très limitées dans le temps. Là où je suis plus sceptique, c'est de l'avoir utilisée dans mon premier programme (jardin potager), parce que à l'époque, je n'ai pas trouvé d'autre solution. C'était pour visualiser une image agrandie pour voir des détails, et le temps aurait pu être interminable, mais SCANCODE à l'époque n'était pas au point et les instructions pas suffisantes pour faire autrement (cela dit, je n'en ai pas trouvé d'autre et c'est peu-être moi l'ereur).
Franchement dans ce cas là, je préfère mon système qui est pour toi moins élégant, mais permet de faire une diversion provisoire du programme avec une boite généraliste pour l'ensemble du programme . Si elle ne servait qu'une fois, le problème serait différent, mais à quoi faire une boite si il faut à chaque fois en reprogrammer les sorties. Mais ceci n'est que du provisoire, vu que l'on va avoir une instruction comme "MESSAGE_CONFIRMATION_YES_NO()", et là tout devient possible.
Je finis, la sonnette ne fini pas de sonner.

Me revoilà pour le final, je crois.Je vais t'apprendre à vouloir fermer la boite par la croix, elle n'est pas faite pour cela.
Et là, essai de me bloquer!

Code:

rem essai les appels aux sous programmes, et le résultat
dim choix%,a$
label attente,essai

button  1  :left 1,300:caption 1,"essai":on_click 1,essai
            ' -----------------------------
            '  création de la boite d'attente
form    11  :hide 11:top 11,300:left 11,800:width 11,350:height 11,120:border_hide 11
            color 11,216,218,0
alpha  12  :parent 12,11:top 12,10:left 12,20:width 12,180:font_size 12,10:font_bold 12
button  13  :parent 13,11:top 13,60:left 13,60:caption 13,"oui"
button  14  :parent 14,11:top 14,60:left 14,160:caption 14,"non"
picture 15  :parent 15,11:top 15, 5:left 15,5:width 15,340:height 15,110:color 15,237,232,124
            print_target_is 15:font_size 15,10:font_bold 15:print_locate 20,10
            2d_target_is 15:2d_fill_color 237,232,124 :print "faire un choix"

end
' ==============================================================================
essai:
  rem    "volonté de faire un choix pour faire une tâche ou une autre"
  repeat:until scancode=0
    gosub attente
  repeat:until scancode=1
  message "choix%="+str$(choix%)
return

attente:
  show 11
  inactive 0:choix%=0
  repeat
    if clicked(13)=1 then choix%=1
    if clicked(14)=1 then choix%=2
  until choix%>0
  active 0:hide 11
return

Je n'accepte pas la défaite!!

Je vois - ça marche ! Le border_hide est efficace ! C'est ce que j'ai fait aussi dans mon calendrier_popup: c'est une fenêtre réutilisable librement un peu comme la tienne, associée à un petit programme test. Regarde ceci:

http://membres.multimania.fr/klaus/files/calendrier.bas

(lien extrait de mon site Panoramic).

Je crois que tu y trouveras des similitudes...

Continue comme ça - comme tu dis, la défaite n'est pas acceptable !

Oui j'avais déjà regardé tes oeuvres. Chapeau!
Mais ce que j'aimerai bien, et je l'ai déjà dis (dommage, les autres ne participent pas), c'est une instruction de blocage. Comme tu as pu le voir, input inutile (il y a longtemps qu'on le sais), il ne reste plus que la boucle repeat until avec un scancode ou autre, ce qui prends de la ressource. J'ai pas l'impression que je genre d'instruction comme Gosub_wait, tu y sois favorable.
Pourtant c'est ce que j'ai fais avec execute_wait. Ne pourrait-on pas partir de cette idée, pour entrevoir un arrêt? Je ne sais pas ce qu'en pense Jack, et je comprends qu'il ne veuille pas répondre. Il a assez de travail comme ça. De toute façon, j'ai déjà 2/3 possibilités rien qu'avec ce post. Les miens, les tiens.
Salutation
A propos, j'ai essayé le programme sur un ancien éditeur, avant que les appels soient sur la liste d'attente. Le fonctionnement est identique. Les problèmes que j'avais remarqués, sont autres.

Effectivement, il n'y a pour l'instant que peu de moyens pour suspendre une exécution, en-dehors des boucles que tu proposes. Il y a bien l'instruction Wait, mais elle suspend tout pour un temps fixe, y compris les évènements, ce qui n'est pas le but. Il y a égamenent l'instruction Display, mais elle ne suspend le traitement que le temps de finir une mise à jour de l'affichage à l'écran, sans lien avec autre chose.

J'ai réfléchi à une instruction du type que tu proposes, ou un
SUSPEND_UNTIL objet,cause
mais apès un peu de réflexion, j'ai trouvé pourquoi cela ne PEUT PAS marcher. Pour Panoramic, il n'y a pas de structure de modules dans le programme. Tout est d'un seul tenant, et suspendre l'exécution à un endroit équivaut à mettre l'ensemble du programme en sommeil, et les boutons sur ta fenêtre ne seront pas actifs. C'est le problème de l'instruction Wait, pendant laquelle absolument rien n'est actif.

En réalité, cela vient du fait que Panoramic ne connait pas la notion de fenêtre dans le sens d'un objet windows indépendant. Je sais que je vais susciter une levée de boucliers de certains, mais c''est comme ça. Pour Panoramic, une Form n'est pas un Window, c'est juste un objet Panoramic comme un autre. La preuve: dans le source Panoramic, on crée l'objet de la form, puis on crée des objets qui iront dans cette form, mais il faut le préciser explicitement, soit par l'instruction PARENT, soit par l'instruction COMMAND_TARGET_IS. D'ailleurs, si on n'utilise pas les instructions ACTIVE et INACTIVE, tous les objets de toutes les forms sont actifs en mêmê temps. Panoramic ne gère que des objets et neconnaît pas la notion de fenêtre mère, fenêtre fille, etc. En termes techniques, Panoramic n'a pas de fenêtres modales.

C'est ce constat qui m'a conduit à la technique de programmation utiliée pour mon calendrier pop_up; le même constat t'a conduit à téa technique d'attente d'une validation. Mais tant que Panoramic fonctionne selon ce mode, il n'y aura pas d'autres solutions, et encore, il faut jongler judicieusement avec les ACTIVE et INACTIVE, sinon, rien ne fonctionne comme prévu.

Peur-être, un jour, Panoramic aura des sous-programmes externes que l'on peut appeler par
CALL sousprogramme(param1,param2,...)
Et là, on peut imaginer une variante
CALL_WAIT sousprogramme(param1,param2,...)
pour désactiver automatiquement TOUS les objets en définis à ce moment, et le sousprogramme appelé créerait ses propres objets (sa form, ses boutons etc) et Panoramic ne réagirait que pour ces objets...

Mais pour l'heure, je ne pense pas qu'une telle chose soit possible avec la structure actuelle de Panoramic.

On a vraiment un problème pour faire attendre le programme dans certain cas. il faudrait une commande ATTENDS_UN_CLICK (en français) ou WAIT_A_CLICK.

En attendant j'ai peut-être une piste avec END

Code:

attente:
for n=4 to 7
 if clicked(n)=1 then return
next n
end
return

çà marche à condition de ne pas revenir sur l'un des bouttons de 4 à 7 qui aurait été clické et comme je l'ai demandé sur un nouveau post, on ne peut pas remettre le CLICKED d'un boutton à zéro.

A+

Je n'avais pas l'intention de répondre, tu as déjà tout dis. Je ne vois pas en quoi tu lève une série de bouclier (de toute façon je ne suis pas assez costaud pour dire le contraire).
Mais j'ai mis un exemple plus haut avec l'appel d'un programme externe en Panoramic exécutable, et je crois qu'il manque une ligne. J'en ai profité pour améliorer la présentation, et le rendre fonctionnel, ce qui n'était pas le but au départ, mais seulement un exemple.
Donc la première partie est la boite qu'il faut compiler sous le nom: boite_2_boutons.exe, pour que le programme appelant puisse le trouver.

Code:

dim choix% :label oui,non,fin
          ' création de la boite d'attente
            top 0,300:left 0,800:width 0,360:height 0,130:color 0,181,218,0:border_hide 0
picture 1  :top 1,10:left 1,10:width 1,340:height 1,110:color 1,237,232,124
button 13  :top 13,90:left 13,90 :caption 13,"oui": on_click 13,oui
button 14  :top 14,90:left 14,190:caption 14,"non": on_click 14,non
list  15  :top 15,20:left 15,20:width 15,320:height 15,50:color 15,237,232,124:font_size 15,12:font_bold 1
            file_load 15,"transfert.txt" :end
oui:
  choix%=1
  clear 15
  item_add 15,"1"
  goto fin
return
non:
  choix%=2
  clear 15
  item_add 15,"2"
  goto fin
return
fin:
  file_save 15,"transfert.txt"
  terminate

Un petit programme d'essai qui utilise le programme:

Code:

' partie d'un programme faisant l'essai d'appel d'un programme extérieur, qui
' représente une forme avec 2 boutons, ayant pour but de faire un choix
label essai
dlist 1
memo 2 :width 2,200:height 2,100:font_size 2,10
button 3 :left 3,210:caption 3,"essai":on_click 3,essai
          hint 3,"cliquez sur ce bouton pour faire apparaître la boite"
end
' _____________________________________________________________________
essai:
  clear 1
  item_add 1,"Attention, si vous modifiez le codage,"
  item_add 1,"le texte précédent est perdu. On continu?"
  file_save 1,"transfert.txt":  execute_wait "boite_2_boutons.exe"
  file_load 1,"transfert.txt" :' récupère 1) pour oui ou 2) pour non
  if item_read$(1,1)="1"
      item_add 2,"reçu :1"
  else
      item_add 2,"reçu :"+item_read$(1,1)
  end_if
return

C'est idiot, je le mets ici pour corriger l'autre plus haut, dans les unitilitaire, il avait une meilleure place
Je viens de voire ton message Jean-Claude au moment de l'envoyer, mais je dois partir.
Salutation

Pour Jean-Claude:

Ce qu'il faut faire pour résoudre ce problème dans l'esprit de Panoramic (et sans nouvelles fonctions ou instructions):

1. definir une variable "sémaphore" qui sert à mémoriser où on est et ce à quoi on s'attend
2. laisser la main à Panoramic en faisant return dans le sousprogramme où l'on voudrair attendre quelque chose
3. dans tous les sous-programmes à évènements, et en particulier les routines on_click, commencer par tester cette variable et déclencher un traitement particuliersi cette variable indique qu'on attent quelque chose.

Exemple:

Code:

dim semaphore%
rem valeurs pour semaphore%:
rem    0 = on n'attend rien
rem    1 = on attend la réponse d'une boite de dialoge "form11"
rem    2 = on attend un choix de l'utilisateur sur une case à cocher quelconque
rem    ... et ainsi de suite



rem ici, on place le reste du programme jusqu'au end, avec la définition de tous les objets
semaphore% = 0
end

on_click code_client:
semaphore% = 1    ' signaler "on attent le résultat de la boite de dialogue"
rem ici, appel de la boite de dialogue form11
...
return

on_click type_de_contrat:
semaphore% = 2    ' signaler "on attend une des cases à cocher"
...
return

on_click prenom:
if semaphore%>0 then goto attente_en_cours
...
return

on_click code_postal:
if semaphore%>0 then goto attente_en_cours
...
return

et ainsi de suite


rem le code qui suit est activé par un goto;
donc, le return à la fin termine en fait l'évènement activateur !
attente_en_cours:
select semaphore%
  case 1: goto on_attend_form11
  case 2: goto on_attend_case_a_cocher
....
end_select
return


on_attend_form11:
rem traiter ici le résultat de la boite de dialogue form11
...
semaphore% = 0    ' on a terminé l'attente
return

on_attend_case_a_cocher:
rem traiter ici l'attente d'un click sur une case à cocher
...
semaphore% = 0    ' on a terminé l'attente
return

De cette manière, on obtient une VRAIE attente, tout en restant dans la logique de Panoramic, et SANS manger des ressources unité centrale...

Pour Commos70:

Je regarderai ton programme en détail demain. Au premier coup d'oeil, il est évident qu'il fait ce que tu souhaites; en fait, tu utilises les execute_wait pour simuler ce que j'ai suggéré plus haut par CALL ou CALL_WAIT. Ca marche avec les moyens disponibles aujourd'hui, et on peut passer des paramètres (d'ailleurs dans le sans aller/retour) ce qui n'est pas possible avec gosub. Donc, fonctionellement, une réussite, et si le temps d'exécution ne compte pas, la solution est encore meilleure qu'une subroutine ou une form ajoutée par #INCLUDE car les vaiables et objets ne rentrent pas en conflit avec le programme appelant.