Appel d'événement en dehors du END

Invité

J'ai régulièrement un problème avec Panoramique, que j'ai adopté, pour les programme pour certains types, car il est impossible à partir du END (à ma connaissance) d'enclencher un programme automatiquement avec les évènements.

Si on a une routine à faire avant le END, tous les boutons ou autres ne servent à rien jusqu'à ce que le programme (dans son exécution, et non pendant la phase de "compilation") rencontre le END.
Il faudrait soit une fonction qui simule un évènement, par exemple: pour pouvoir démarrer le démarrage d'une action, j'utilise on_click 0,label, ou le clic d'un bouton. Et celui parfois ne convient pas.

Il y aurait aussi la possibilité lors de l'exécution du programme de dire maintenant il y a un end, mais le mieux serait à mon sens une instruction du type: ON_END,label, qui une fois tous les événements en place, pouvoir continuer le programme, sans que celui-ci soit bloqué.

Ne me dites pas que c'est pas indispensable, que cela peut attendre, je suis même persuadé que c'est non seulement indispensable, mais prioritaire.

Même Nicolas ne peut pas me désavouer, vu que:

Citation :: on_key_up 0,suit

dans le poste: des débuts sans prétentions, cette instruction ne sert à rien,vu que le END est hors de fonctionnement (C'est pas de sa faute, combien de fois j'ai eu ce problème)

Avec d'autre basic, on peut concilier les deux, ici non.

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Citation :: Si on a une routine à faire avant le END, tous les boutons ou autres ne servent à rien jusqu'à ce que le programme (dans son exécution, et non pendant la phase de "compilation") rencontre le END.

Pas du tout !
Un sous-programme de traitement d'événement peut être appelé dès que ON_CLICK, ou ON_CHANGE, ou ON_KEY... a été exécuté.
Et voici un exemple qui te le prouve. Attention, le programme ne peut être terminé que par un clic sur l'icone de fermeture (croix rouge).

Code:: label action_sur_bouton

button 1
caption 1,"cliquez"
on_click 1,action_sur_bouton

rem à partir de maintenant, un clic sur le bouton
rem va provoquer le traitement commençant par ACTION_SUR_BOUTON

rem et pour bien montrer que cela fonctionne AVANT le end
rem je met une boucle infinie

while 1=1:wait 10:end_while

rem on ne passera jamais ici
END

action_sur_bouton:
caption 1,"c'est actif"
return

Citation :: Avec d'autre basic, on peut concilier les deux, ici non.

Bien sûr que si.
Panoramic a été conçu pour pouvoir mélanger deux types de programmation:
- à l'ancienne, où c'est le programmeur qui s'occupe de tout et teste les événements (IF CLICKED(N)=1 THEN - - -)
- événementielle où le programmeur crée une interface avec des objets et définit le comportement de ces objets face aux événements (ON_CLICK N,LABEL ...... LABEL: - - - RETURN)

Il va falloir qu'un jour je fasse un tutoriel sur ce sujet car c'est un sujet récurrent sur le forum.

Ma propre réflexion sur ce sujet:
Je pense que la programmation "à l'ancienne" et les mots-clés comme CLICKED(), INPUT, INKEY etc n'ont vraiment plus leur place aujourd'hui et posent des problèmes au programmeur pour leur utilisation. Lorsque je les ai fait, j'ai voulu être compatible avec des pièces de musée comme GWBASIC, QBASIC qui tournaient en monotache sous un OS (MSDOS) qui ne pouvait faire qu'une chose à la fois, et cela a été une grosse erreur. J'aurai du prendre VisualBasic comme modèle, pour lequel il n'y a ni INPUT, ni PRINT, ni test d'événements.

Donner la possibilité de mélanger les deux types de programmation est une deuxième grosse erreur: le codage de INPUT est une véritable usine à gaz aujourd'hui.
Ce mot-clé était naturel du temps où on pouvait tout suspendre pendant la saisie d'une valeur. Aujourd'hui, pour simuler un INPUT, il faut compenser le fait pendant la saisie que tout continue à tourner et que les événements s'empilent !

J'en arrive à penser, après tout ce que je vois comme incompréhension sur ce forum, que PANORAMIC ferait un progrès majeur avec l'abandon de tous ces mots-clés hérités du monotache.

Je préfère de loin un tutoriel, plutot que la suppression de certains mots-clés, car j'ai encore des progs "à l'ancienne".
Et je pense que çà aiderait beaucoup d'entre nous sur la programmation par évenements.

Débat ouvert....

A+

Invité

Merci pour ta réponse Jack.
Je suis un peu embarrassé, car j'ai toujours eu des problèmes avec ce type de programmation.

Je viens de modifier un programme, pour qu'il corresponde un peu à ta présentation.

Ce programme j'avais l'intention de m'en servir comme exemple pour une autre demande, qui est la fonction Grid, comme on le trouve en ...(je mettrais bien le nom mais pas correct ici) Qui me parait bonne surtout que tu nous avais fait part d'un désir si je m'en souviens bien de faire des programmes Open Source comme un tableur. Programmer en Panoramique c'est presque possible, sauf qu'il y a le temps d'exécution, qui pour une page entière de données est longue, et le déplacement des colonnes pratiquement ingérable en direct.

Sur ce programme en essai (je suis en train de le construire, donc c'est de la recherche pour l'instant), j'ai essayé de faire avec les évènements sans le END pour voir suite à ta réponse:

Code:: ' essai de faire un memo en picture avec lignage
width 0,1000:height 0,900
error_french
' réduction : Grid

dim Grid% , Grid_creat$(20,30) , Grid_line(20) , Grid_col(30) , Grid_Surf$(20,30)
dim Grid_ink$(20,30) , rouge% , vert% , bleu% ,Grid_couleur%

label grid_rouge , grid_vert , grid_bleu , grid_blanc , grid_noir , grid_gris
label grid_jaune , grid_orange , grid_rose , grid_violet , grid_marron

label grid_r , grid_v , grid_b , grid_w , grid_n , grid_g , grid_j , grid_o
label grid_p , grid_l , grid_m , Grid_couleur , essai , loop , fin , annonce

dim a% ,h%,v%,a$
picture 1 :top 1,50:width 1,800:height 1,800:font_name 1,"Bitstream Ver Sans Mono":font_size 1,10

on_click 1,essai
on_click 0,annonce
goto essai
loop:
repeat
wait 1
until scancode=27
goto fin
' end
' ==============================================================================
annonce:
message "on a cliquez sur la forme 0"
return
' ==============================================================================
essai:
2d_target_is 1:2d_pen_color 214,211,247 :font_bold 1
print_target_is 1
Grid_line(1) =20 :' largeur colonne 1
for a%=2 to 20:Grid_line(a%)=Grid_line(a%-1)+70:next a%
for a%=1 to 20:2d_line Grid_line(a%),1,Grid_line(a%),800:next a%

Grid_col(1) =20 :' hauteur colonne 1
for a%=2 to 30:Grid_col(a%)=Grid_col(a%-1)+25:next a%
for a%=1 to 30:2d_line 1,Grid_col(a%),800,Grid_col(a%):next a%

for a%=1 to 20
Grid_creat$(a%,1)=chr$(a%+64)
Grid%=(Grid_line(a%)-Grid_line(a%-1))/2-5
print_locate Grid_line(a%-1)+Grid%,Grid_col(0)+Grid_col(1)-15:print Grid_creat$(a%,1)
next a%

Grid_creat$(2,3)="case:2,3":Grid_surf$(2,3)="J":Grid_ink$(2,3)="B"
Grid_creat$(5,8)="case:5,8":Grid_surf$(5,8)="N":Grid_ink$(5,8)="R"
Grid_creat$(7,9)="case:7,9":Grid_surf$(7,9)="p":Grid_ink$(7,9)="b"

for h%=2 to 20
for v%=2 to 30
if Grid_creat$(h%,v%)<>""
Grid%=(Grid_line(h%)-Grid_line(h%-1))+2
a$=grid_surf$(h%,v%):gosub Grid_couleur:2d_fill_color rouge%,vert%,bleu%
2d_rectangle Grid_Line(h%) , Grid_col(v%), Grid_Line(h%+1)+1 , Grid_col(v%+1)+1
a$=Grid_ink$(h%,v%) :gosub Grid_couleur
font_color 1,rouge%,vert%,bleu%
print_locate Grid_Line(h%)+2,Grid_col(v%)+5:print Grid_creat$(h%,v%)
end_if
next v%
next h%
wait 1000
2d_clear

goto loop

' ==============================================================================
grid_couleur:
Grid_couleur%=asc(upper$(a$))
SELECT Grid_couleur%
CASE 82:GOSUB Grid_r :' rouge
CASE 86:GOSUB Grid_v :' vert
CASE 66:Gosub Grid_b :' bleu
CASE 87:GOSUB Grid_W :' blanc soit WHITE
CASE 78:GOSUB Grid_N :' noir
CASE 71:GOSUB Grid_g :' gris
CASE 74:GOSUB Grid_j :' jaune
CASE 79:GOSUB Grid_O :' orange
CASE 80:GOSUB Grid_P :' rose soit PINK
CASE 77:GOSUB Grid_M :' marron
CASE 76:GOSUB Grid_L :' violet soit LILAS
END_SELECT

return
' ==============================================================================
grid_rouge:
grid_r:
rouge%=255:vert%=0:bleu%=0
return
' ==============================================================================
grid_vert:
grid_v:
rouge%=0:vert%=255:bleu%=0
return
' ==============================================================================
grid_bleu:
grid_b:
rouge%=0:vert%=0:bleu%=255
return
' ==============================================================================
grid_blanc:
grid_w:
rouge%=255:vert%=255:bleu%=255
return
' ==============================================================================
grid_noir:
grid_n:
rouge%=0:vert%=0:bleu%=0
return
' ==============================================================================
grid_gris:
grid_g:
rouge%=180:vert%=180:bleu%=180
return
' ==============================================================================
grid_jaune:
grid_j:
rouge%=255:vert%=255:bleu%=0
return
' ==============================================================================
grid_orange:
grid_o:
rouge%=255:vert%=180:bleu%=0
return
' ==============================================================================
grid_rose:
grid_p:
rouge%=255:vert%=210:bleu%=255
return
' ==============================================================================
grid_violet:
grid_l:
rouge%=255:vert%=100:bleu%=255
return
' ==============================================================================
grid_marron:
grid_m:
rouge%=190:vert%=110:bleu%=0
return

' ==============================================================================
fin:
terminate

Donc je peux cliquer sur le picture 1 pour faire apparaitre une fois l'affichage, et sur la forme 0 pour voir un message, et <esc> pour sortir.

Si après le clique sur 0, après le message, apparait: (67) Pas trouvé de Repeat...
Si je clique sur picture 1, et après sortie par ESC j'ai Acces violation
Si je clique sur 1 puis sur 0, plus de prise en compte des clics. (pas d'évènement).
Le programme est peut-être mal fait, mais je ne l'avais pas prévu pour cela, et je dois partir tout à l'heure.

Toujours est-il que j'ai toujours constaté des problèmes avec ce type de programme, et j'ai pourtant besoin de ce type de programmation.

Maintenant on me demande, @+, merci

Admin Nombre de messages : 2386 Date d'inscription : 28/05/2007

Quelque chose me choque dans la structure de ton code:

on_click 1,essai
et il n'y a aucun return dans ce sous-programme essai

de plus, dans essai, tu mets goto loop puis une boucle testant le clavier.

Pire, tu appelles un sous-programme de traitement d'événement par un goto !

En fait, dans ton programme principal, si on ne fait rien, on se retrouve dans cette boucle de test du clavier.
Si on clique sur le bouton, on attend 1 seconde puis on se retrouve à nouveau dans cette boucle.

Comme on reste éternellement dans ton traitement dévénement du clic sur l'objet 1 (il n'y a aucun RETURN pour en sortir), plus rien ne répond car les événements sont mémorisés et traités les uns après les autres. C'est inévitable...

Invité

Je reviens en vitesse, parce que je suis aujourd'hui pris de partout (heureusement je ne suis pas une femme -excusez moi pour celle qui me lise).
Au départ j'avais fais un gosub, et je viens de le refaire, et return à la sortie de la routine essai à la place de goto loop, mais ça ne marche pas non plus, au retour du clic sur le picture 1, j'ai ausi Pas trouvé de Repeat.

Quant a la façon de programmer, j'ai modifié mon programme pour trouver un truc qui corresponde à ce poste. J'ai trouvé plus simple d'effacer un picture, et de cliquer sur ce qui est présent, j'ai pas le temps d'aller à fond dans le programme aujourd'hui.

Mon programme n'est peut-être pas un bonne exemple, mais à chaque fois que j'ai voulu utiliser ce type de programmation, je ne m'en suis pas sortie.

La seule possibilité je crois a été d'éviter les évènements sur les objets, et de tout contrôler par des if clicked sur toute la programmation. Peut-être depuis avec toutes les modifications sur ce basic, on peut mieux faire, mais pour moi, d'après mes constatations, un évènement tant qu'il ne rencontre pas le END dans un gros programme, pose problème.

Pour moi, c'est à suivre, et j'espère te donner raison (je préfère me tromper ici, et que ça marche, parce qu'en ce cas je pourrais mettre mes deux routines que j'ai besoin, au point.

Salutation, je pars.

Quel dommage que je dois partir plusieurs jours, pour mettre un exemple plus convaincant.

Il y a quelque temps, j'ai fait un post à ce sujet. Je n'arrive pas à récupérer le lien vers ce post, donc voici le texte intégral:

Citation :: MessageSujet: Re: Bizarrerie d'affichage Ven 19 Mar 2010 - 1:04 Répondre en citant Editer/Supprimer ce message
Bonsoir,

A moi de mettre mon petit grain de sel au sujet des print et input.

On peut les utiliser exactement comme dans les anciens nasics, à condition de faire un programme dans l'esprit des anciens basics. Ceci est uniquement le cas entre le début du programme et l'instruction end. Après l'instruction end, c'est le mode évènement qui est activé.

En mode ancien, les objets Panoramic interactifs n'ont aucun sens; pour eux, cette phase ne sert qu'à ma préparation d'une form en vue de la phase "évènements".

Donc, si l'on veut programmer dans l'ancien mode, il faut tout placer entre le début et end, et là, print ET input fonctionnent comme on a l'habitude. Attention néanmoins à ne pas créer des objets occultant la zone utilisée par print, ou alors les créer et les positionner plus loin AVANT de faire le premier print.

D'alleurs, dans cette phase "ancien mode", aucun évènement n'est pris en compte, les routines on_click ne sont pas actives, etc. C'est bien ce qui permet d'utiliser input normalement, dans cette phase.

Une fois passée l'instruction end, on rentre sans uneautre logique, celle des évènements. On ne peut plus se fier au déoulement linéaire du prgramme: c'est l'utilisater avec sa souris ou des évènements windows qui décident. Donc, input n'a plus sa place dans cette phase. Et pour utiliser print, il y a l'instruction print_target_is qui permet de diriger l'impression vers un objet panoramic. Pour afficher des informations, il convient alors d'utiliser un mémo, objet parfaitement adapté à cela.

J'espère que ces quelques explications vous seront utiles.

Cordialement Klaus

Moi aussi, je pense que des instructions comme input ont perdu leur sens dans le contexte de programmation évènementielle, c'est-à-dire après l'exécution de l'instruction "end". Et même avant, comme Jack l'a si bien démontré, cela pose problème car les évènements sont déjà actifs.

Les saisies dans un programme Windows doivent passer par une boite de saisie, par un objet de type edit etc. Seule l'instruction scancode (et éventuellement inkey$, et encore...) a un sens réel, dans le contexte des jeux ou des simulations, par exemple.

Je pense vraiment qu'il faut faire l'effort de "penser" en évènements windows. Microsoft dit:

Citation :: Unlike MS-DOS-based applications, Windows-based applications are event-driven. They do not make explicit function calls (such as C run-time library calls) to obtain input. Instead, they wait for the system to pass input to them.

Michel Bardou (spécialiste Delphi) dit sur un forum:

Citation :: Pourquoi les messages ?

Les messages sont directement liés au phénomène de programmation événementielle :

Pour certaines actions, Windows génère un message. Il peut alors être récupéré par le programme qui peut ainsi réagir à cet événement.

Par exemple : vous appuyez sur le bouton gauche de la souris et un message WM_LBUTTONDOWN est automatiquement envoyé par Windows. Votre application peut être avertie de cette action de plusieurs façons.

Notamment par les événements OnMouseDown qui sont déclenchés automatiquement lorsque ce message est intercepté par votre application.

La programmation événementielle est donc un subtil mélange de génération de messages et réactions face à ces messages.

Le site "The Code Project" indique:

Citation :: Perhaps one of the most important means of communication in windows is Messages. The traditional program starts at your main() function, moves down line-by-line in your code, and eventually exits. The Windows concept is different. The way you program in windows is by responding to events. These events are called messages.

Messages can signal many events, caused by the user, the operating system, or another program. An event could be caused by a mousemove, a key-press, or by your window getting resized. There are 2 kinds of messages: a window message, or a thread message. Since Threads are an advanced issue, I'll refer only to window messages.

Tout montre clairement que le fonctionnement même de Windows (NT,XP, Vista, Windows 7) est fondamentalement différent de celui de MS-DOS et éventuellement Windows 3. Donc, la philosophie sousjacente à GWBasic et autres clônes de cette époque n'est plus du tout applicable et conduit dans le contexte actuel inévitablement à une multitude de problèmes de programmation, de fonctionnnement erratique.

Je ne peux que conseiller à tout le monde de prendre un peu de temps pour s'imprégner de cette notion d'évènements. Le principe de base est le suivant:

Citation :: 1ère étape: mise en place de l'interfae utilisateur visuel, avec les forms et les objets
2ème étape: faire toutes les initialisations (ouverture de fichiers, valeurs initiales de variables, ...), donc tout ce qui ne doit être fait qu'une seule fois
3ème étape: se mettre en attente d'un évènement Windows (c'est l'instruction Panoramic "end" qui le fait !)

A partir de ce moment, tout, mais vraiment tout, est géré par les routines d'évènements qui ont été déclarées par les instructions on_click, on_change etc. Ces routines peuvent bien sûr en appeler d'autres qui ne sont pas des routines d'évènements, mais le principe du traitement d'une routine d'évènement est extrêmement simple:

Citation :: 1ère phase: Windows signale un évènement à Panoramic (invisible pour l'utilisateur)
2ème phase: Panoramic détermine l'action à effectuer et appelle éventuellement une routine d'évènement déclarée dans le programme (invisible pour l'utilisateur)
3ème phase: la routine déclarée par on_xxx demarre. Ce n'est que maintenant qu'on se trouve dans le vrai code du programmeur.
4ème phase: le code écrit par le programmeur doit effectuer toutes les actions nécessaires pour traiter cet évènement précis, c'est-à-dire réagir à la raison qui a conduit le programmeur à déclarer cette routine.
5ème phase: signaler à Panoramic que l'évènement a été complètement pris en compte. C'est l'instruction Panoramic "return" qui le fait

Ensuite, le programme se retrouve nouveau dans la situation d'attente d'un autre évènement dont la nature et la survenue sont par définition totalement aléatoires.

A bien y réfléchir, cela donne une liberté de programmation bien plus grande que sous MS-DOS. En effet, c'est Windows, puis Panoramic, qui se chargent entièrement de la cohérence de l'ensemble du traitement. En tant que programmeur, on a juste à écrire de "petits" modules indépendants qui doivent chacun réaliser une fonction précise. Cela simplifie énormément la logique d'un programme qui n'a plus tu tout besoin de "prévoir" l'odre dans lequel telle ou telle opération de déroule: c'est Windows qui s'en charge.

Cela simplifie également la mise au point d'un programme. On peut parfaitement mettre au point une fonction pour un évènement précis sans interagir avec les traitements pour une autre partie du programme; on peut ajouter des fonctions (traitements de nouveaux évènements) sans incidence sur les traitements déjà existants, etc.

Bon, j'espère que mon long post na pas été trop rébarbatif et que j'ai pu contribuer à éclairer un peu le sujet.

Invité

5 mn pour répondre.
Je constate que tu es d'accord que les évènements posent problèmes avant le END, où j'ai mal lu.

Mais je voudrais qu'on m'explique pourquoi, (non de Dieu), vous considérez qu'il est interdit d'avoir une routine automatique, qui fonctionne au départ, et qu'on puisse avoir ensuite la possibilité de cliquer sur un bouton. J'ai besoin de ce principe. Si je programme aujourd'hui, c'est justement pour pouvoir avoir les programmes qui ne sont pas dans le commerce, et qui ont la particularité de fonctionner selon mes besoins.

A part se faire plaisir, pour certain, ça ne sert à rien de ne pas pouvoir faire le programme qu'on veut en disant mais Windows fonctionne comme çà, et intel a dit cela. Je veux pouvoir faire ce qui me chante (en étant poli envers toi, parce que tu le mérites), en dehors des programmes que je vois tous les jours, et qui ne m'intéresse pas.

Programmer c'est un besoin, soit pour son égo, sans par nécessité, et il y a nécessité pour moi. Pour le plaisirs, je l'ai fais dans le temps, mais j'ai mes inventions, et le reste qui presse.

Je m'en "fout" que cela soit vieux jeu ou non. Je préfère un langage avec des instructions qui me permette d'aller au bout, que de dire non, plus maintenant, c'est comme çà, et être bloqué.

Je lance un appel: si quelqu'un a réussi à faire un programme complet (et non pas 10 lignes) qui permette de se lancer tout seul, et qu'on puisse à tel occasion ou une autre avoir un évènement , qu'il le dise, ou le montre. Je l'en remercie par avance. On pourra l'analyser, et dire qui a raison ou tord.

Je suis peut-être un peu sévère, c'est ça va plus vite. Ah si j'avais un sosie.

J'essayerai de lire ici vers 15h. Après je sais pas.
@+

Je te comprends parfaitement, et je suis entièrement d'accord avec toi quant aux raisons qui nous poussent à utiliser un langage comme Panoramic.

Seulement, les contraintes techniques de Windows s'imposent à tous, et à Panoramic en premier lieu, et par voie de conséquence, à nous tous qui essayons humblement d'en faire quelque chose. Tu ne peux pas dire qu'un fer à souder ne sert à rien, sous prétexte qu'il ne sait pas faire des trous dans une planche. Ce que je veux dire par là, c'est qu'il faut utiliser tout outil dans le but pour lequel il a été conçu, et non pour le but pour lequel on voudrait bien l'utiliser. Bien sûr, tu peux percer une planche avec un fer à souder, mais tu mettras beaucoup de temps, et le trou sera loin d'être joli.

Pour en revenir à Panoramic: Jack à très clairement démontré que les évènements sont actifs dès leur déclaration par on_xxx, même avant l'instruction "end". Or, avant l'instruction "end", tu te trouves exactement dans le même cas de figure qu'avec les anciens Basic (GWBasic, ...) et tu peux écrire un code procédural exactement comme avant. Attention aux évènements cependant: un click sur un bouton pour lequel une routine on_click a été déclarée, exécute immédiatement la routine assiciée SANS que ton code principal puisse s'en rendre compte.

Il y a une solution simple à ce problème. Il faut jouer avec les instructions on_xxx car malheureusement, il n'y a pas d'instruction générale pour désactiver une routine évènement installée par on_xxx (sauf pour on_click pour lequel il y a off_click, mais pas pour les on_change etc). Le petit bout de code suivant montre comment faire:

Citation :: label click_bouton,click_edit, change_memo,ignore

rem ------ on définit 3 objets ACTIFS mais sans évènements
edit 1
top 1,10
left 1,10
on_click 1,ignore

button 2
top 2,40
left 2,10
caption 2,"Bouton"
on_click 2,ignore

memo 3
top 3,70
left 3,10
on_change 3,ignore

rem -------- ici, suit le code normal, sans être perturbé pas les évènements

rem --------- ici, veut pouvoir exécuter une action par un click sur le bouton
on_click 2,click_bouton
rem ---------- le traitement normal continue, le click sera actif

rem ---------- ici, on veut désactiver le click
on_click 2,ignore

rem ----------- ici, on veut être averti d'un changement dans le memo
on_change 3,change_memo
rem ----------- le traimenent normal continue, mais on est averti si le memo change

rem ----------- ici, on ne veut plus être perturbé par les changements de memo
on_change 3,ignore
rem ------------ le traitement normal continue

rem ------------ fin du programme "style classique"
terminate
end

rem ---------- un évènement "ignoré"
ignore:
return

rem ---------- click dans le edit
click_edit:
rem ----------- traitement du click dans le edit

return

rem ----------- click sur le bouton
click_bouton:
rem ------------ traitement du click sur le bouton

return

rem ----------- changement de memo
change_memo:
rem ------------ traitement du changement du memo

return

Je crois que tu as saisi le principe: à l'aide d'un sousprogramme "ignore" qui ne fait "rien", on simule une désactivation des évènements. Ceci est une méthode beaucoup plus subtile que d'utiliser "activate" et "inactivate", car on peut toujours saisir dans les edit et les memo et on peut, selon les besoins, permettre un évènement on_change sur ces objets ou l'interdire, au lieu de bloquer ces objets purment et simplement.

Et de cette manière, tu prux programmer comme tu le souhaites, en permettant un évènement lorsque cela t'arrange.

Deux choses seulement sont impossibles techniquement, et cela tient justement à la nature asynchrone et aléatoire des évènements: tu ne peux pas "attendre" un évènement, et tu ne peux pas dérouter le programme principal par un évènement. Qu'il y ait un évènement ou pas, ton programme principal n'en saura rien, à moins de positionner un drapeau ou une valeur quelconque dans la routine d'évènement, et de tester cette variable de temps en temps. C'est la seule possibilité d'établir un lien entre évènement et parcours du programme principal.

@Klauss
TERMINATE se trouve avant END dans ton exemple, ce qui l'empêche de fonctionner.

@...
Je pense que ce qu'il faut retenir, c'est que l'on ne peut pas écrire un programme avec Panoramic de la même façon qu'avec QB, Etc...
Je comprends Cosmos, car j'ai cette même difficulté de sortir de cette façon de faire. Mais j'ai compris également qu'il n'y a pas le choix.
On parle toujours d'anciens Basics (QB, etc...) et du coup on ne souligne pas suffisement le coeur du problème, qui n'est pas lié au language utilisé mais à la façon dont le programme se déroule. Ce que je veut dire c'est qu'il ne faut pas essayer de fabriquer des codes "séquentiels" pour un language "événementiel" . (çà ne peut pas fonctionner).
Quand à écrire en séquentiel avant END, c'est possible éffectivement, mais c'est source d'erreurs.

A+

A Jean-Claude:

J'ai mis sciemment terminate avant end. Il va de soi que dans ce type de programme, on a une boucle ou quelque chose d'approchant pour englober l'ensemble du traitement, et on va vers le terminate quand on veut que le programme se termine. Je l'ai indiqué comme ça juste pour montrer que dans ce type de programme, l'ensemble de l'action se déroule AVANT l'instruction end que l'on n'atteint en fait jamais. Dans ce cas, tout fonctionne comme je l'ai décrit dans mon post précédent (et je l'ai essayé !), car je répète: comme Jack l'a montré, les évènements sont actifs même AVANT l'instruction end, en fait dès le moment de leur déclaration pas les instructions on_xxx.

Bien sûr, je suis entièrement d'accord avec toi: avec Panoramic, l'intérêt c'est d'écrire du code évènementiel ce qui n'était tout simplement pas possible avec les anciens Basics. Cependant, en respectant les règles que j'ai données dans mon post précédent, on peut toujours programmer en procédural comme avant, tout en profitant par moment de la possibilité d'utiliser les évènements. Mais encore une fois: il faut qu'au niveau de la conception, l'idée soit claire dès le départ: soit, on programme en procédural avec les règles ci-dessus, soit, on programme en évènementiel, et il faut changer de façon de programmer pour s'adapter à cette technologie.

Si en évènementiel, la partie "initialisation" a un peu plus de travail à faire que déclarer quelques objets pour dessiner l'écran, si par exemple il faut déclarer beaucoup d'objets, lire des fichiers etc, il faut déplacer toutes les instructions on_xxx, ainsi que les mark_on par exemple, à la fin de la partie initialisation, juste avant l'instruction end. Ainsi, on est certain qu'un click intempestif ne viendra pas perturber cette partie en principe non prévue pour les évènements.

Oui, çà y est, j'ai pigé l'astuce grace a cette phrase

Citation :: J'ai mis sciemment terminate avant end. Il va de soi que dans ce type de programme, on a une boucle ou quelque chose d'approchant pour englober l'ensemble du traitement, et on va vers le terminate quand on veut que le programme se termine. Je l'ai indiqué comme ça juste pour montrer que dans ce type de programme, l'ensemble de l'action se déroule AVANT l'instruction end que l'on n'atteint en fait jamais.

On atteind jamais end, mais il est indispensable pour le traitement par Panoramic des objets, dim, label (et initialisation de fichiers s'il y en a).
Je pense avoir compris, n'hésite pas à me reprendre si ce n'est pas le cas.

Merci à toi pour ta patiente....

Jean-Claude, tu y est presque ! Quand Panoramic exécute un programme, il commence à exécuter (que ce soit en interprêté par l'éditeur ou en compilé en *.exe) à la première instruction rencontrée. Qu'il s'agisse des dim, une instruction arithmétique, un if, une ouverture de fichier, une création d'objet etc, tout est exécuté pleinement, en séquence. L'instruction end en fait porte très mal son nom. Elle devrait s'appeler wait_for_event par exemple. C'est simplement un signal à Panoramic qu'il n'y a plus rien à exécuter. Donc, Panoramic se me en attente d'un évènement que Windows lui communique et prend alors les mesures qui s'imposent.

Si par exemple on a frappé la lettre "A" dans un edit, Panoramic regarde si cet objet est activ. Si oui, la lettre est placée à l'endroit du curseur dans l'edit, sinon, la lettre est perdue. Ensuite, Panoramic regarde si une routine d'évènement a été déclarée pour cet objet, un on_change par exemple. Si c'est le cas, Panoramic appelle cette routine comme si ton propre programme avait fait un gosub vers cette routine. Cette routine s'exécute puis se termine OBLIGATOIREMENT par un return. Tout retourne alors à l'état précédent: Panoramic attend un évènement.

Si, avant de rencontrer l'instruction mal-nommée end,Panoramic reçoit un message de Windows l'informant qu'il y a un évènement, Panoramic interrompt alors l'exécution du code Basic pour traiter l'évènement, exactement de la même manière que décrite plus haut, à ceci près qu'après la fin du traitement de l'évènement (et donc éventuellement après le return du sous-programme déclaré par on_xxx), Panoramic continue d'exécuter le programme Basic comme si de rien n'était, et le code Panoramic avant end n'a donc aucun moyen de savoir qu'un évènement est venu interrompre son cours, sauf à tester une variable drapeau qui aurait été positionnée par la routine d'évènement. Et il n'y a aucun moyen de savoir, même avec des astuces, à quel moment précis l'évènement est arrivé et a été pris en compte.

P.S.

Il y a bien un moyen plus clair de programmer en Panoramic comme avec les anciens Basic. On ne crée AUCUN objet, et on écrit tout le code avant end. De cette manière, on est libéré des contraintes des évènements, et là, on retrouve l'entière liberté d'utiliser les instructions input, inkey$ et print, exactement comme dans les anciens Basic. Pas de gestion d'écran: tout se déroule comme dans une fenêtre console.

D'autres langages modernes permettent de faire cela aussi: Visual Basic par exemple possède un mode d'écriture d'un programme console qui doit être conçu exactement de la même manière. Sauf avec Visual Basic, c'est un choix explicite, fait au début de la création du programme.

Panoramic permet d'utiliser les deux modes de création, sans explicitement imposer de déclarer dans quel mode on veut travailler, et il est même possible de mixer les deux. Je pense que les difficultés de compréhension viennent de cette absence de formalisme et de la confusion qu'apporte le nom de l'instruction end.

Nombre de messages : 2695 Date d'inscription : 13/09/2009

Mais non, mais non, Jack, il ne faut pas s'affoler et supprimer des possibilités, même désuètes.
L'avantage de panoramic, c'est qu'on peut justement mélanger les deux modes
(de façon ponctuelle, j'entends, pas dans un vaste flou)
(par exemple, si rien d'événementiel n'est prévu pour quelque chose,
eh bien on le crée en une petite séquence de programmation linéaire)
C'est justement cette souplesse qui fait la force de panoramic.

Effectivement, ce qui peut manquer, c'est un tutoriel pour programmer :
- soit complètement en linéaire comme dans le temps :
(en remplaçant les goto 90 par des goto repere:) (et sans end)
- soit en événementiel (sans goto autant que faire se peut) :
avec des déclarations et mises en forme et appels événementiels, avant le end
puis avec exclusivement des routines se terminant par return, après le end.
(ces règles "d'or" pouvant comporter des exceptions, bien évidemment,
mais des exceptions qui ne doivent pas devenir la règle).
jocolor

Complètement d'accord avec toi, jjn4 ! C'est une grande souplesse que Panoramic offre, et à condition de prendre en compte les avantages et contraintes, on peut facilement tirer avantages des deux mondes !

Peut-être un "User's Guide" avec un chapître supplémentaire pour éclaircir les choses ?

Maintenant les choses sont claires,

2 Mondes à maîtriser....

Merci pour ces lumières. Very Happy

En tout cas merci à Klaus et Jack pour ces cours de prog freeware car certaines choses me sont plus claires maintenant.

comme quoi un language plus commun ne dénature rien et rend plus accessible la programmation même sans avoir le QI d'einstein. cheers

C'est çà la programmation, faire des grandes choses sans être un sur'homme (ou femme) Very Happy

» Coloramic
» Problème d'appel de SUB.
» Appel aux matheux
» Astuce lors d'un appel de sub.
» Appel d'un site sur Internet (résolu)