Mark_on déclenche un click et pas Mark_off

Bonjour Jack,
Pourquoi Mark_on équivaut à un click ? je pense que çà n'est pas voulu....
Le code ci-dessous illustre bien la situation

Code:

label start,fin
check 1:caption 1,"Check 1":top 1,100:left 1,100
on_click 1,fin
gosub start

END

start:
mark_off 1
mark_on 1:' essayer avec ou sans cette ligne
return

fin:
terminate

A+

Si tu déclares les événements après le mark_on, il n'y a plus de problème....

Code:

label start,fin
check 1:caption 1,"Check 1":top 1,100:left 1,100
gosub start

END

start:
mark_off 1
mark_on 1:' essayer avec ou sans cette ligne
on_click 1,fin
return

fin:
terminate

PS: et c'est voulu : le MARK_ON simule le clic de la souris sur l'objet check... puisque l'evenement est actif
tu obtiens la même chose avec ceci:

Code:

LABEL toto
EDIT 1
ON_CHANGE 1,toto
TEXT 1,"Essai" : ' <- tu modifies le contenu, donc tu vas déclencher l'appel à toto ;)
END
toto:
MESSAGE "Coucou !"
RETURN

MOUAIS,

je suis pas convaincu, mais si c'est bon (tel quel) je vais faire avec (Ce que j'ai déjà fait en utilisant OFF_CLICK N)


Merci pour ta réponse...

A+

Pourtant c'est clair :

en bon français, dans l'ordre, voilà ce que tu as écrit :

1- Pour toute modification de l'objet x aller à y
2- modifier la valeur de x

Ca parait logique que le MARK_ON déclenche le ON_CLICK...
Dans l'exemple que tu donnes : par défaut l'objet est déjà OFF donc l'instruction mark_off ne peut pas provoquer le declenchement d'un ON_CLICK
Si par exemple tu écris ceci :

Code:

label start,fin
check 1:caption 1,"Check 1":top 1,100:left 1,100
mark_on 1
on_click 1,fin
gosub start
END

start:
  mark_off 1
return

fin:
terminate

c'est le mark_off qui déclenchera le ON_CLICK.
Là où c'est litigieux, c'est qu'en fait quand tu écris ON_CLICK et il faut penser ON_CHANGE...

MOUAIS,

je suis toujours septique....

imagine que le CHECK soit appeler plusieurs fois dans le code. A certain moment, tu peux avoir besoin de le faire apparaître décoché, or s'il était coché tu déclenche l'évènement ON_CLICK (qui n'est plus valable à ce stade du code).
Cela oblige de penser à faire un OFF_CLICK sur le CHECK pour pouvoir modifier son apparence...

Bon, c'est pas plus grave que çà, il suffit de le savoir (et surtout de s'en rappeler).

A+

Oui c'est exactement ça.
Regardes le source de ma base de données : tu verras que je désactive les ON_CHANGE avant de modifier leur contenu...

Mon écran est à l'endroit, mais j'arrive quand même à litre

Bon je change mon MOUAIS en oui d'accord car a bien y réfléchir: à partir du moment que tu as déclaré un ON_CLICK sur un objet il reste valide tant qu'il n'est pas changé par un autre ON_CLICK ou annulé par un OFF_CLICK.
Ce qui trouble c'est que quand tu écris MARK_ON tu ne pense pas forcément que tu peux déclencher un évènement (surtout quand tu ne te rappelles plus que tu l'avait affublé d'un ON_CLICK)

A+

Bonsoir,
Je me suis retenu la semaine dernière pour poster ce même problème. De toute façon je n'aurais pas eu de réponse immédiate pour résoudre le cas.

Avec pagiciel, j'ai eu du mal de déboguer le travail que j'ai rajouté, car je ne comprenais pas ce qu'il se passait, et effectivement, en suivant les lignes, j'ai pensé aux détour des checks, et là il y en avait une quantité à détourner et à remettre ensuite (off_click et on_click).Franchement, on a affaire à on_click et non on_change, donc modifier l'état par programme, pour reporter la lecture des états d'un check depuis un fichier, ne devrait pas faire de branchement. Ce qui n'est pas le cas avec on_change.

Vu la quantité de check à modifier et de mettre à jour selon la lecture des objets d'une page, j'ai cherché une autre solution que d'agir avec les off_click, et la méthode me parait plus simple. Je me sers d'une variable tampon, et je branche tous les checks sur une même routine qui décide ce qu'il faut faire selon la valeur de la variable.

Code:

' mark 20_off
label on_off , valide , invalide
dim on_off%
check 10:caption 10,"dix"            :on_click 10,on_off
check 11:top 11, 30:caption 11,"onze" :on_click 11,on_off
button 5:left 5,100:caption 5,"valide":on_click 5,valide
button 6:left 6,100:top 6,50:caption 6,"invalide":on_click 6,invalide
end
' -------------------
valide:
on_off%=1 : return
' -------------------
invalide:
on_off%=0 : return
' -------------------
on_off:
  if on_off%=1
      select number_click :' on se branche selon le clic
        case 10: dix()
        case 11: onze()
      end_select
  else
      message "pas de branchement, invalide"
  end_if
return
' -------------------
sub dix()
  if checked(10)=0 then message "10=0":else:message "10=1"
end_sub
' -------------------
sub onze()
  if checked(11)=0 then message "11=0":else:message "11=1"
end_sub

Mal expliqué, mais le code dit tout.

Ton code est très clair, Cosmos70, et constitue une bonne façon de gérer ce problème.

Merci Klaus, mais il n'est pas valable. J'ai pensé à cette solution il y a une semaine, mais depuis, j'ai eu d'autres problèmes et pagiciel est de côté. Je pense le reprendre demain, ce soir je me vide la tête.

Il n'est pas valable, car dans la lecture des lignes de codes au fur et à mesure, avec on_click, qui s'apparente avec on_change dans ce cas, il y a détournement comme le fait un timer. J'ai pas trop réfléchi, mais je pense quil faut envoyer avant de lire le mark_off ou mark_on, un vrai off_click. Donc on fait un gosub pour invalider le clic selon l'objet.

J’arrête j'en ai marre ce soir. Je regarderai demain.
Je dirai seulement qu'il n'y a pas de rebranchement à la suite du code, après avoir fait mark_on ou off, selon ce qu'on veut mettre. Ici c'est pas pareil, vu que les évènements sont clair.
Bonsoir

Mais si, Cosmos70, il est valide ! Le problème posé était qu'ine commande MARK_ON déclenche l'évènement. Alors, avec ton système, on voit bien que l'évènement est bloqué (bon, il y a un message, mais il suffit de le supprimer) si aucun message n'est attendu. Et ce mécanisme de blocage est valable d'un seul coup pour tous les objets CHECK. Je me suis permis d'ajouter une seule commande MARK_ON pour montrer le phénomène, à part cela, c'est ton code:

Code:

' mark 20_off
label on_off , valide , invalide
dim on_off%
check 10:caption 10,"dix"            :on_click 10,on_off
check 11:top 11, 30:caption 11,"onze" :on_click 11,on_off
button 5:left 5,100:caption 5,"valide":on_click 5,valide
button 6:left 6,100:top 6,50:caption 6,"invalide":on_click 6,invalide

mark_on 10  : ' <== klaus

end
' -------------------
valide:
on_off%=1 : return
' -------------------
invalide:
on_off%=0 : return
' -------------------
on_off:
  if on_off%=1
      select number_click :' on se branche selon le clic
        case 10: dix()
        case 11: onze()
      end_select
  else
      message "pas de branchement, invalide"
  end_if
return
' -------------------
sub dix()
  if checked(10)=0 then message "10=0":else:message "10=1"
end_sub
' -------------------
sub onze()
  if checked(11)=0 then message "11=0":else:message "11=1"
end_sub

Oui Klaus, ça fonctionne. Mais il y a des remarques à faire. Je prend le code suivant qui a une fonction teste, et la encore ça fonctionne:

Code:

' mark 20_off
label on_off , valide , invalide , teste
dim on_off%  , a%
check 10:caption 10,"dix"            :on_click 10,on_off
check 11:top 11, 30:caption 11,"onze" :on_click 11,on_off
button 5:left 5,100:caption 5,"valide":on_click 5,valide
button 6:left 6,100:top 6,50:caption 6,"invalide":on_click 6,invalide
button 7:left 7,200:caption 7,"teste":on_click 7,teste
mark_on 10  : ' <== klaus
gosub teste
end
' -------------------
valide:
on_off%=1 : return
' -------------------
invalide:
on_off%=0 : return
' -------------------
on_off:
  if on_off%=1
      select number_click :' on se branche selon le clic
        case 10: dix()
        case 11: onze()
      end_select
  else
      message "pas de branchement, invalide"
  end_if
return
' -------------------
sub dix()
  if checked(10)=0 then message "10=0":else:message "10=1"
end_sub
' -------------------
sub onze()
  if checked(11)=0 then message "11=0":else:message "11=1"
end_sub

teste:
  for a%=1 to 10
      caption 0,a%
      if checked(10)=1 then mark_off 10:else:mark_on 10
  next a%
return

Mais tu remarques que: on_click 10,on_off joue un rôle. Le fait de modifier l'état d'un check, créé un détournement qui dans ce cas me ramène au sous-programme teste. Mais dans pagiciel aussi il y a détournement et il n'y a pas de retour juste après la modification de l'état, à la suite de la lecture du code.
Ici on a de la chance. Dans la partie du source :teste, on est dans une boucle for/next, et si on n'a pas prévu exit_for, on ne sort pas de cette boucle sans blocage du système.
Moi je pose une question: comment est conçu le système d'événement dans Panoramic? Jack ne dis rien, et il acceptera pas de répondre à ce sujet. Il n'accepte jamais de donner la moindre explication. En JustBasic, et en AutoIt, il faut construire la boucle de lecture d’évènement, avec par exemple do/loop, où des instruction spécifique comme wait en JustBasic. Je veux dire par là qu'en Panoramic, ce n'est pas notre problème, et pourtant si!

En Delphi je n'ai fait que des programme de début, j'avais pas le temps pour continuer. Il doit bien y avoir des instructions d'exceptions qui a x moment arrète le code pour savoir si un évènement est intervenu, comme si c'était un timer. Ce qu'il faudrait savoir si tel est le cas, le temps qu'il y a entre deux interruptions. Dans ce programme, il n'y a juste qu'un teste et un message, mais comme message est une interruption qui désactive les autres objets, l’arrêt par message ne compte pas. Mais si le détour de on_click fait un travail important, il ne se rebranche pas à la suite. C'est le cas dans pagiciel.

Une question Klaus: tu trouves normale que le changement de l'état par programme d'un check, provoque un évènement? Ce n'est pas un click!, si c'était on_change, je comprendrais, mais pas pour on_click.

Ne pas oublier que si ma méthode est une résolution de ce problème, il faut insérer avant de modifier l'état d'un check: on_off%=0, et remettre à 1, une fois terminé.

Oui, c'est normal. Et ce n'est pas Panoramic, c'est Windows qui fonctionne comme ça. Toute modification du contenu d'un objet Windows génère toute une série de messages que Windows envoie au programme, à la fenêtre et à l'objet concerné. Et chaque message correspond à un évènement.

Ainsi, la frappe d'une touche génère potentiellement les évènements key_down, key_up et change. Si tu fais passer la souris par-dessus, cela génère les évènements mouse_in et mouse_out. Un clic gauche génère left_click_down, lect_click_up, left_click. Et ainsi de suite.

Maintenant, tout dépend pour quel évènement le programme application a déclaré des routines évènements spécifiques. En cas d'absence de déclaration, la plupart ce ces évènements sont tout simplement ignorés et tu as l'impression que rien ne se passe. Mais dès qu'un programme a déclaré une routine d'évènement, celle-ci sera appelée, quelque soit le contexte.

Et c'est ce qui arrive dans ton cas. Fais le test suivant: déclare un EDIT avec un ON_CHANGE. Puis, change le texte de l'EDIT par TEXT n,"vvv" - tu verras que la routine ON_CHANGE sera appelée ! Et dans le cas d'un CHECK (et d'un OPTION, d'ailleurs), le fait de changer le contenu génère l'évènement ON_CLICK puisque dans Windows, un changement d'un tel objet est obtenu par un clic gauche. L'évènement ON_CHANGE ne peut pas être déclaré en Panoramic pour un CHECK.

Essaie ce programme - il montre bien ce qui se passe:

Code:

label clic

check 1 : caption 1,"Essaie la barre d'espacement"
on_click 1,clic : top 1,10 : left 1,10 : width 1,200
set_focus 1

end

clic:
  message "clic"
  return

Bonjour à tous,

Klaus a écrit:

....tu as l'impression que rien ne se passe. Mais dès qu'un programme a déclaré une routine d'évènement, celle-ci sera appelée, quelque soit le contexte.....

C'est ce que je retiens et c'est important. Il faut être vigilant dans la construction de nos nos codes.

Le piège (pour moi) a été d'oublier que j'avais déclaré un on_click sur le check et que je me suis resservi de celui-ci plus loin dans le code. Mais j'aurais pu tout aussi bien le déclarer plus tard....

Ce qui m'amène à penser que je vais regarder en détail la liste des mots clé de Panoramic pour regarder tout ceux qui sont susceptibles de déclencher un évènement.....

A+

Oui, j'ai pensé que c'était Windows au départ. Mais Panoramic récupère l'évènement et le traite de sa propre façon. Si en me servant d'AutoIt ou de JusteBasic, si je ne teste pas par intermittence pour savoir si il y a eu changement dans l'état, il ne se passe rien. C'est la routine de Panoramic, qui fait ou qui ne fait pas, et là il peut y avoir une autre approche, ou alors le mot clé ON_CLICK n'est pas le bon. Il aurait fallu choisir: ON_CHANGE. C'est toute la différence. Si dans un edit, on choisit ON_CLICK, la modification d'un edit ne fait rien, alors que ON_CHANGE provoque l'évènement.
L'écriture d'un code et la compréhension de celui-ci se fait de ce que l'on croit en attendre. Le fait d'écrire ON_CLICK pour un objet, fait qu'on attend qu'un clic provoque l'évènement. Le fait que l'écriture d'une modification de value ne fait pas penser à un clic, perturbe quelque peut le raisonnement dans le déroulement de cette écriture. Panoramic étant voulu pour être utilisé par des programmeur du dimanche comme on dit (expression que je n'aime pas), l'écriture doit être conforme à ce qu'on lit. Je pense que je suis assez bon programmeur pour ce type de langage, et bien dans mes 3500 lignes actuelles, en ne listant pas les sub_de kgf, il m'a fallu 2 jours pour comprendre mon problème. JE CROIS QU'IL FAUT PRÉCISER DANS L'AIDE DE PANORAMIC, QUE LA MODIFICATION PAR MARK_ON OU OFF, INTERVIENT DANS L'ÉVÈNEMENT.

Tu ne dis rien sur la façon que Panoramic intercepte un évènement, c'est une interruption, ou pour toi un listage périodique des évènements dans une liste? Y-a-t'il dans Delphi une programmation d'interruption?

Bonjour Jean-Claude. on se croise et ta réponse ne change rien à ce que j'écris.

C'est une interruption, Cosmos70. La notion d'évènement implique l'interruptioin du cours du programme normal et l'exécution prioritaire de la routine d'interruption.

Si plusieurs évènements arrivent rapidement, ils sont mis dans une file d'attente. D'abord par Windows lui-meêm, puis, au fur et à mesure qu'ils sont envoyés à Panoramic, par Panoramic. Mais même par Panoramic, ils sont toujours traités comme une interruption du cours normal du programme.

RE bonjour,

Ce débat est intéressant car, comme le laisse entendre Cosmos, (Panoramic se voulant être un langage simple - pour programmeur du dimanche - cette expression ne me gêne pas) ce n'est pas forcément évident de comprendre la réaction de certaine action, dans le code, suivant l'objet ou la commande employé.

La conséquence est qu'on se retrouve avec des appréciations différentes suivant qu'on est "programmeur du dimanche" ou programmeur "avancé". Je comprend que Klaus ou Nardo et d'autres ne discutent pas le fait que MARK_ON ou OFF puisse déclencher un évènement s'il y a eu une déclaration ON_CLICK, mais il faut aussi admettre que pour un "programmeur moins avancé" ce n'est pas aussi évident. Moi même j'ai douté, jusqu’à ce que Nardo me convainque de la chose.

Et là je rejoins Cosmos sur le fait que la doc ne nous averti pas sur la possibilité d'un déclenchement d'évènement (dans ce cas précis). Mais on sait aussi que Jack ne peut pas être sur tout les fronts.

Ma conclusion: c'est que le forum sert à ces échanges instructifs et que rien n'est parfait dans le meilleur des mondes...

A+

Belle conclusion.

Cette discussion est pour moi très instructive.
Elle montre que la documentation n'est jamais assez détaillée.

A moi aussi, il me parait évident qu'un MARK_ON déclenche un événement "clic" sur cet objet. Et je me rends compte que ce n'est pas évident pour tous.
Le développement de PANORAMIC a peut-être été trop rapide par rapport à la documentation et aux tutoriels.
Pour le moment, et vous l'avez sans doute remarqué, j'ai mis le développement de Panoramic en sommeil et je réfléchis au futur de ce langage et à une autre forme.

Merci Jack pour ton intervention. Mais là, j'ai l'allure d'un terroriste pour l'effet de bombe que cela peut provoquer.

Je ne sais pas comment Panoramic est codé, mais je pense qu'il doit y avoir une liste des évènements à contrôler. Si c'est le cas, est-ce qu'il ne serait pas possible d'avoir un instruction: EVENTS_OFF qui permettrait d’arrêter les évènements provisoirement, lors de la lecture du code, qu'on remettrait à EVENTS_ON, afin de pouvoir modifier les edits ou tout autre objet, le temps de les mettre à jour, sans changer leurs états, et de remettre les évènements après la chose faite. Si c'est une liste cela devrait être possible, sinon je pense que cela serait trop complexe.
je ne veux pas refaire des ajouts de poste, aussi je mets ici

Citation :

je réfléchis au futur de ce langage et à une autre forme.

c'est à ça que je pensais à l'effet d'une bombe. Vu le travail qu'il y a encore à faire, sans compter sur la 2D et 3D que Jack voudraient faire ses commandes, recommencer Panoramic, j'ai l'impression que Jack ne verra jamais le bout!

Bonsoir,

Cosmos terroriste ! v'la autre chose...

Non. Tu dis ce que tu penses et c'est bien ainsi.

@Jack
Je ne crois pas que le développement de Panoramic est été trop rapide. Il y a eu à certains moments des changements importants, comme récemment avec les procédures, et c'est à ce moment là qu'on a besoin de "souffler" (pour les moins doués). Mais globalement on a tous réclamés des nouvelles fonctions, commandes, etc. et c'était à mon avis nécessaire, ce qui fait que aujourd'hui Panoramic permet de faire des bons programmes.

L'urgence (s'il y en a une) est plus dans la correction des bugs connus (certains sont bloquants) et une version à jour.
Bien sur, c'est ma façon de voir, je n'impose rien (manquerait plus que çà), je propose...

Pour ce qui est de la doc, c'est vrai qu'il y des choses à faire, mais globalement elle est bien faite. Il commence a y avoir des tutos diffusés par les Panoramiciens et c'est une bonne chose. Le partage des codes est enseignant, le forum se porte bien....

Bref que des raison d'être satisfait et impatient (celui là je le retire ).

Quant au devenir de Panoramic nous attendrons le résultat de tes réflexions (avec un poil d'angoisse ).

Merci pour ton intervention. A+

@Jack:
Globalement, je pense un peu comme Jean-Claude. Je suis très satisfait de l'évolution de Panoramic, et la doc est déjà très bien, bien qu'on puisse toujours y apporter plus d'infos, plus de détails, plus d'exemples.

Panoramic est toujours le langage facile et rapide à mettre en oeuvre. Il y a des possibilités plus pointues maintenant, mais personne n'est obligé de les utiliser pour faire un programme fonctionnel. On peut même toujours utiliser l'ancienne façon de programmer, sans utiliser les objets visuels. Et pour ceux qui ont des difficultés avec INPUT dans ces conditions, il y a les fonctions MESSAGE_INPUT et MESSAGE_INPUT$ qui permettent de faire des saisies sûres et, en même temps, glisser lentement vers une gestion visuelle avec objets.

J'aurais deux suggestions à faire.
1. tu pourrais peut-être structurer la documentation en trois volets: niveau basique, niveau avancé et niveau 2D/3D. Cela permettrait déjà de scinder la masse des commandes et fonctionnalités de Panoramic en trois domaines bien distincts. Ainsi, un nouveau Panoramiciens, s'il est un peu cartésien, pourrait d'abord apprendre à maîtriser le niveau basique, avant de bifurquer, soit vers le niveau 2D/3D, soit vers le niveau avancé.
2. tu pourrais ouvrir une ligne de discussion spécifique qui nous permettrait de déposer des suggestions de compléments, modifs ou corrections de la documentation. Libre à toi bien spur d'en tenir compte ou non. Pour le moment, on signale une information incomplète, manquante ou erronée au fil des diverses discussion, et forcément, cela se perd un peu dans la masse. Ce serait une ligne similaire à celle dans laquelle nous pouvons suggérer des modifications ou nouvelles fonctionnalités de Panoramic, sauf qu'elle serait dédiée à la documentation et éventuellement aux tutos.

Je ne me pleins pas de Panoramic, d'ailleurs j'avais escamoté ce problème il y a une semaine, et c'est seulement cette discutions provoqué par Jean-Claude qui me fait intervenir ici (c'est pas un reproche à Jean-Claude).
J'ai remarqué au fil du temps et de la programmation, que la majorité des problèmes venait des évènements. Sans ceux-là il y aurait moins de bugs dans l'exécution du code. Mais la force de Panoramic, vient justement ce cette programmation, tel quelle est conçu. Cela a été les problèmes avec les timers mal compris, les détournements, la queue de file, etc...
C'est pour cela que je pense dans le cas où ces évènements serait dans une pile, l'ajout de ces deux instructions: events_off, et events_on me paraîtrait la bien venu. Ainsi, on pourrait bloquer tous les évènements pour finir un code, ou pour modifier les états de certains d'entre-eux, et une fois que le travail de la routine fait, on réactive les évènements. Il n'y aurait plus de mauvais clics sur un bouton ou autre, et je crois qu'on aurait un basic formidable dans la conception. Si c'est la lecture d'une liste, pour les évènements, il pourrait y avoir un détour sur une liste vide dans le cas elle doit exister. Là je rentre dans un domaine qui m'échappe.

Moi personnellement, je propose, je discute, mais n'impose rien. Je fais avec ce que j'ai. Je détourne le problème chaque fois que j'ai une solution. Mais c'est pas toujours évident, surtout pour ceux qui commencent à programmer, ou découvrir le langage.

Ben, je ne vais pas dire comme tout le monde, désolé ...
Je pense que Jack a raison sur le fait que le reste n'a pas suivi.
Je m'explique: Panoramic était jeune. Il avait un environnement modeste et des possibilités limitées. Jack a rajouté plein de choses et d'autres arriveront sans doute prochainement dans le monde de la 2D et de la 3D pour faciliter la création de jeu.
Maintenant, le langage permet de faire de vrais applications (entre les include et les procédures).
Je pense (c'est mon avis) que développer l'environnement de programmation serait en effet une bonne idée. Un bon éditeur, la possibilité native d'afficher ou non les includes dans le source (voir dans ce cas de pouvoir les modifier directement...), compléter et enrichir l'aide, moderniser un peu l'affichage, faire une interface plus conviviale pour placer les objets 2D ou 3D pour faciliter le développement des jeux pour les programmeurs du dimanche. Pouvoir gérer les timer et événements depuis cette interface graphique de sorte que les programmes simples puissent se faire sans avoir à taper une ligne de code ...
Je pousse volontairement le bouchon un peu loin, mais je pense que c'est dans l'esprit de Panoramic et ça ne veut pas dire que ça puisse être fait en 2 jours ... C'est juste ma vision d'un développement possible de Panoramic. Je n'ai pas dit non plus que c'était facile à faire ...

Finalement, Jicehel, tu n'est pas aussi éloigné que tu le penses car, plus que le développement du langage, tu souhaites une amélioration de l’environnement (Editeur, doc, interface graphique).

Par contre je pense que Jack se pose des questions qui vont bien plus loin que çà.

C'est pour cela que je souhaite une version de l'état actuel de Panoramic avec correction des bugs et mise à jour de la doc, bref pas une instantanée, et ensuite la pose que Jack souhaite.

A+