Une option qui se coche automatiquement ?

Je n'arrive pas à comprendre pourquoi, entre deux messages sans autre code, l'état des options cochées change:

Code:: dim n%
n% = 5

container_option 3 : top 3,90 : width 3,130 : height 3,40 : left 3,5
caption 3,"Options"
option 31 : parent 31,3 : top 31,15 : left 31,5 : width 31,20 : ' on_click 31,clickOctave
option 32 : parent 32,3 : top 32,15 : left 32,20 : width 32,20 : ' on_click 32,clickOctave
option 33 : parent 33,3 : top 33,15 : left 33,35 : width 33,20 : ' on_click 33,clickOctave
option 34 : parent 34,3 : top 34,15 : left 34,50 : width 34,20 : ' on_click 34,clickOctave
option 35 : parent 35,3 : top 35,15 : left 35,65 : width 35,20 : ' on_click 35,clickOctave
option 36 : parent 36,3 : top 36,15 : left 36,80 : width 36,20 : ' on_click 36,clickOctave
option 37 : parent 37,3 : top 37,15 : left 37,95 : width 37,20 : ' on_click 37,clickOctave
option 38 : parent 38,3 : top 38,15 : left 38,110 : width 38,15: ' on_click 38,clickOctave
mark_on 30+n%

display
message "a1"

n% = 6
mark_on 30+n%
display
message "a2 ici, la 6ème option est cochée- ok"

display
message "a3 ici, la 5ème option réapparaît - pourquoi ?"
end
display
message "a4"

end

J'utilise la toute dernière version du 2/2/2018. Mais j'ai essayé avec la version précédente et c'est identique. Quelqu'un a une idée lumineuse ? Je sèche...

Je crois avoir compris ce qui se passe, et je pense avoir découvert un bug qui traîne depuis un moment, puisque dans la version précédente, c'est identique. Si je remplace les messages a2 et a3 par "pause 500", l'option 6 reste bien cochée. Puis je fais un autre message et boum ! Rebelote:

Code:: dim n%
n% = 5

container_option 3 : top 3,90 : width 3,130 : height 3,40 : left 3,5
caption 3,"Options"
option 31 : parent 31,3 : top 31,15 : left 31,5 : width 31,20 : ' on_click 31,clickOctave
option 32 : parent 32,3 : top 32,15 : left 32,20 : width 32,20 : ' on_click 32,clickOctave
option 33 : parent 33,3 : top 33,15 : left 33,35 : width 33,20 : ' on_click 33,clickOctave
option 34 : parent 34,3 : top 34,15 : left 34,50 : width 34,20 : ' on_click 34,clickOctave
option 35 : parent 35,3 : top 35,15 : left 35,65 : width 35,20 : ' on_click 35,clickOctave
option 36 : parent 36,3 : top 36,15 : left 36,80 : width 36,20 : ' on_click 36,clickOctave
option 37 : parent 37,3 : top 37,15 : left 37,95 : width 37,20 : ' on_click 37,clickOctave
option 38 : parent 38,3 : top 38,15 : left 38,110 : width 38,15: ' on_click 38,clickOctave
mark_on 30+n%

display
message "a1"

n% = 6
mark_on 30+n%
display
' message "a2 ici, la 6ème option est cochée- ok"
pause 500

display
' message "a3 ici, la 5ème option réapparaît - pourquoi ?"
pause 500

message "a4 et maintenant ?"

end

Je pense que Panoramic ne gère plus correctement le focus sur ses objets. Le fait de cliquer sur le bouton de la fenêtre de message est capté également comme un clic sur une des options, comme si l'objet gardait le focus et "captait" le clic.

Ca me fait penser à un problème que j'ai depuis longtemps avec l'objet RichEdit généré par KGF.dll. Il est clair que cet objet n'est pas géré par Panoramic. Normal. Je peux cliquer dedans et saisir du texte sans problème, utiliser les flèches, retour charriot etc. Si, ensuite, je clique sur un objet Panoramic normal, mon RichEdit perd le focus au profit de l'objet Panoramic. Normal encore. Ensuite, je reclique dans le RichEdit et je lui donne explicitement le focus par l'API de Windows (SetFocus). Le peux alors saisir du texte à l'endroit cliqué, mais je ne peux plus du tout utiliser le retour charriot, les flèches ou d'autres touches fonction. Tout cela est intercepté par l'objet Panoramic que j'avais utilisé juste avant. Comme si Panoramic ne comprenait pas que cet objet n'a plus le focus.

Pendant des mois, j'ai pensé que le problème vient de mon code. Ce n'est pas toujours évident, avec un tel monument en Delphi. Mais ici, j'ai mis le problème en évidence en Panoramic pur, en quelques lignes. Alors, bug ou pas bug, qu'est-ce que voius pensez ?

Dans FLTK (la bibliothèque utilisée par FBPano) il y a un mécanisme pour savoir si un événement a été "capté" par un objet : on associe à l'objet concerné une fonction qui retourne 1 si l'événement a été capté, 0 sinon. Si la fonction retourne 0 l'événement est automatiquement transmis à un autre objet.

Peut-être un tel mécanisme est-il concevable dans Panoramic, maintenant qu'il y a des fonctions ?

Si personnenne relève d'erreur de programmation dans mon code, alors il s'agirait vraiment d'un bug ? Dans ce cas, je vais republier tout ça dans la rubrique concnernée, dans la journée...

Nombre de messages : 1596 Date d'inscription : 19/01/2014

Bonjour.

Klaus, je confirme, après test, le problème soulevé.

La commande message provoque bien un dysfonctionnement des focus sur les boutons option.

Ouf ! Merci ! J'avais le nez tellement dans mon code que je redoutais de ne plus voir clair ! Tu me rassures.

J’ai posté (en 2014 ?) une SUB message_Auto_Close(msg$,duree) qui affichait un message et s’auto-referme tout seul après une durée de n secondes.
A l’époque personne n’y a prêté attention.
Je remets le code ici : ça pourrait peut-être servir.

Code:: rem ============================================================================
' Message autorefermable
' Afficher un message d'information qui se ferme automatiquement après n secondes
' Appel : message_Auto_Close(msg$, duree)
rem ============================================================================

message_Auto_Close("Cette fenêtre va se fermer toute seule !!!",5)

end
rem ============================================================================
' Script VBS pour afficher un message d'information qui se ferme automatiquement
' apès une durée de duree secondes si l'utilisateur ne ferme pas lui-même la
' fenêtre du message
SUB message_Auto_Close(msg$,duree)
   dim_local f$,g$,d$
   f$ = "c:\temp\Msg_Auto_Close.vbs" : ' Fichier temporaire contenant le script
   g$ = chr$(34) : ' guillemets
   d$ = str$(duree)
   FILE_OPEN_WRITE 9999, f$
   file_writeln 9999,"Set WshShell = WScript.CreateObject("+g$+"Wscript.Shell"+g$+")"
   file_writeln 9999,"ret = WshShell.popup("+g$+msg$+g$+" & vbcrlf &" +g$+" Autofermeture dans : "+d$+" secondes"+g$+","+d$+","+g$+"Information"+g$+")"
   FILE_CLOSE 9999 : ' Fin de l'enregistrement
   EXECUTE_WAIT f$ : ' Exécution du script
   FILE_DELETE f$ : ' supprimer le fichier du script
END_SUB
rem ============================================================================

J'ai posté mon problème dans la rubtique des bugs. Et oui, j'ai osé...

Je confirme qu'il y a bien un problème.
Tu peux le contourner en créant un nouveau form et en le plaçant en dehors de la zone d'affichage(le bug semble se produire lorsqu'il n'y a que le form 0), ou en plaçant un 'set_focus' juste après le mark_on, sur l'option qui vient d'être coché.

Exact, Silverman ! Un SET_FOCUS juste après le MARK_ON évite le problème !

Bien. Ca me permet de continuer, et je t'en remercie. Il reste qu'il s'agit bien d'un problème technique avac Panoramic. Et dans d'autres circonstances (voir ci-dessus avec RICH_EDIT), l'astuce de SET_FOCUS ne marche pas...

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

Il s'agit d'un bug.

Voici un code minimal qui montre le problème:

Code:: container_option 1
option 2 : parent 2,1 : top 2,15 : caption 2,"2"
option 3 : parent 3,1 : top 3,35 : caption 3,"3"
mark_on 2
message "mark_on sur 2"
mark_on 3
message "mark_on sur 3"
end

Après le deuxième message, l'OPTION n°2 se retrouve cochée, ce qui n'est pas normal.

_________________

Une option qui se coche automatiquement ? Webdav

username : panoramic@jack-panoramic password : panoramic123

Ah, tu me rassures, Jack ! Ca fait des mois que, dans un programme beaucoup plus complexe, je me bats avec de tels phénomères. J'ai toujours mis cela sur le compte d'une erreur de programmation de ma part, dans la partie KGF.dll. Alors, j'attends patiemment !

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

Tout d'abord, pour analyser un problème, je remonte les versions pour voir à partir de quand il apparaît.
Or, ce problème existe depuis l'apparition de l'objet CONTAINER_OPTION dans la V 0.9.17 du 18 février 2010.
Il est donc "congénital".
Ca va donc être un peu plus difficile à corriger, car ce problème ne vient pas d'une modification de quelque chose, mais c'est en quelle que sorte un problème de conception.

_________________

username : panoramic@jack-panoramic password : panoramic123

C'est un peu ce que j'avais en tête... Car un phénomène simlaire se produit si j'utilise l'objet RichEdit créé par KGF.dll, et ce également depuis la version précédente, au moins. Description:
- je crée l'objet dans KGF.dll et je l'injecte dans une form - ça marche bien, je peux saisir, utiliser les flèches pour déplacer le curseur dans le texte saisi, ainsi que Return pour passer à la ligne
- je clique sur un objet Panoramic quelconque (un bouton, par exemple, un edit ou un mémo)
- je reclique dans le RichEdit - le curseur le place bien, et je peux saisir du texte. Mais maintenant, les touches fonction (flèches, Return, ...) sont "captées" par le dernier objet Panoramic cliqué (le bouton qu se réactive automatiquement lors d'une frappe de Return, le texte du edit ou du mémo lors de la frappe de touches fonction, etc). Et ce, malgré l'emploi de l'API SetFocus de Window pour redonner le focus à mon RichEdit.

Lorsque tu auras corrigé le problème dont on parle, je verrai bien si c'est corrigé en même temps. En cas de doute, je pourrai produire une petite démo mettant le problème en évidence. D'ailleurs, lorsque j'appelle KGF.dll pour créer un RichEdit à partir d'un programme purement Delphi, tout fonctionne normalement. Il n'y a pas de phénomène de "captation".

Je suis patient - il n'y a aucune urgence.

Bonsoir à tous,

Je profite de l'occasion pour attirer l'attention sur un sujet déjà discuté.

Code:: label Off2,Off3
container_option 1
option 2 : parent 2,1 : top 2,15 : caption 2,"2" : on_click 2,Off2
option 3 : parent 3,1 : top 3,35 : caption 3,"3" : on_click 3,Off3
mark_on 2
message "mark_on sur 2"
mark_on 3
message "mark_on sur 3"
end

Off2:
mark_off 2
return

Off3:
mark_off 3
return

On voit dans ce code que MARK_ON (par programmation) déclenche un événement. C'est aussi le cas de MARK_OFF.

Pour moi, ce fonctionnement de MARK_OFF et MARK_ON, n'est pas normal. Mon avis c'est qu'un événement ne peut-être déclenché que par l'utilisateur (ou par le programmeur à condition qu'il utilise TRIGGER_CLICK)
MARK_OFF et MARK_ON devrait se contenter de cocher ou pas les OPTIONS, CHECK...

J'ignore si c'est possible ou pas, mais j'aimerai avoir un avis.

A+

C'est le fonctionnement normal de tout objet Panoramic (de Windows), en fait. Dès qu'on change son contenu, l'évènement est déclenché. Or, il se trouve que l'objet OPTION n'a pas d'évènement ON_CHANGE, et donc c'est ON_CLICK qui est autmatiquement déclenché, par Windows, pas par Panoramic.

Regarde ceci:

Code:: label change
edit 1 : on_change 1,change
text 1,"coucou"
end
change:
message "Evènement reçu :"
return

Pour éviter cela, un seul moyen: désactiver l'évènement par OFF_xxx, modifier le contenu, puis refaire ON_xxx.

Merci pour ta réponse Klaus,

C'est bien ce que je craignais, "c'est normal". Il va falloir que je sois vigilant avec "les objets à cocher", car ce n'est pas la première fois que j'ai des soucis avec leur programmation.
Le plus simple pour éviter ~~des~~ mes erreurs de codage, c'est de ne pas utiliser MARK_ON pour OPTION et CHECK.
Curieusement, Chaque fois je les ais utilisés sur un MAIN_MENU, je n'ai pas eu de problème, ils agissent comme un indicateur d'état d'un SUB_MENU.

Bref ! quand Jack aura réparé, il sera temps de tester à nouveau.

A+

» Sauvegarder le programme automatiquement
» Comment sélectionner du texte automatiquement ?
» option DTP de kgf
» Check et Option
» option et focus