Message d'erreur 'La fenêtre ne comporte pas de barre de...'

Bonjour,
Quand j'exécute le code ci-dessous, j'obtiens le message d'erreur 'La fenêtre ne comporte pas de barre de défilement' qui ne semble pas venir de Panoramic. Pour reproduire le message d'erreur, il faut mettre le pointeur de la souris à gauche de carré blanc de manière à le faire défiler. Une fois qu'il a disparu, j'obtiens le message d'erreur. Parfois, il y a aussi le message d'erreur 'Out of system ressources' qui s'affiche.

Code:

label scroll
dim i,a,b,pos

width 0,550:height 0,300

picture 1:left 1,50

timer 100:on_timer 100,scroll
timer_interval 100,20

end

scroll:
a=mouse_x_position(0):b=mouse_y_position(0)

if b<100
  if a<100 then left 1,left(1)+3:pos=pos+3
  if a>400 then left 1,left(1)-3:pos=pos-3

  if left(1)>=400 then show 1:width 1,500-left(1)-3
  if left(1)>=500 then hide 1
end_if
return

Merci de votre aide,
Atom

Je pense que tu devrais mettre un arrêt à 0 pour ta fonction.

Je n'ai pas réussi à reproduire l'erreur dont tu parles,

Mais je peux te dire que, à chaque clic, le délai d’exécution est long.

A+

Bon je ne veux pas faire d'essai sur ma machine. J'ai des programmes ouverts, et je ne veux pas avoir un blocage qui pose problème.
Mais il faut faire gaffe avec un timer, et dans certains cas aussi avec on_change.
Essais de voir avec en mettant TIMER_OFF 100, à l'entrée de scroll, et tu remets TIMER_ON 100 à la sortie avant RETURN.
Car si le traitement est dans la boucle lorsque le timer réagit de nouveau pendant le traitement, il reprend à scroll.

bonjour a tous.
si cela peu aider .
je lance le code par l'éclair et je laisse faire.
lorsque le carré arrive en butée a droite,il devient rectangle et disparait, ensuite j'ai 2 messages d'erreurs.
1 - de panoramic -->parametre incorrect. ( au singulier)
2- de panoramic --> 27 trop de gosub ou d'événements imbriqués ( plus de 1000).
c'est tout

C'est typique d'une mauvaise gestion du timer comme a dit cosmos.

Tout est dit, le truc c'est d’arrêter le timer pendant le traitement et de le remettre en route en fin de sous programme de traitement.

Bon, je vais mettre en veilleuse mon programme, histoire de changer d'air.
Un TIMER est un objet évènementielle périodique. La différence entre un clique sur un bouton, ou autre, est qu'il déclenche un évènement lorsque le temps défini lors de la déclaration est atteint. Et il agit de suite, quelque soit la circonstance.
Un click sur un bouton agit différemment. Il est mis dans une "queue de file", c'est à dire qu'il est ajouté à une pile, et l'évènement sera traité, lorsque ce sera son tour. Dans ce cas, tout se synchronise. Un évènement se termine proprement, et c'est le suivant qui est pris en compte.

Avec un timer, admettons qu'on est le programme suivant:

Code:

dim a
label teste , periodiq
button 1:on_click 1, teste
timer 2:timer_interval 2,100: on_timer 2,periodiq
END

teste:
for a=1 to 50000
  print a
next a
return

periodic:
  message "je fou le bordel":  ' et c'est pas peu dire
return

Voila: le timer tel qu'il est réglé, agit 10 fois par secondes, mais celui de la procédure va mettre énormément de temps s'exécuter avec le nombre de boucle.
Lorsqu'on va cliquer sur le bouton, on enclenche à la procédure: teste.
Donc on commence à compter, le timer va 10 fois par seconde faire son travail. Et là il y a vraiment un problème, car le timer n'est pas mis en queue de file, mais détourne complètement la procédure teste.
Lorsque le timer aura terminé sa propre procédure (periodic), il n'y a pas de retour à teste, l'adresse où se trouvait le programme au moment du détournement, n'a pas été sauvegardé. C'est pour cela qu'on reçoit un message du genre: pas de repeat ou autre. Et généralement la suite des évènements est corrompu.

Je ne sais pas comment est construit Panoramic, mais c'est de cette façon que que je constate le mécanisme.

Pour éviter cette situation, on procède ainsi:

Code:

teste:
timer_off 2
for a=1 to 50000
  print a
next a
timer_on 2
return

Le timer est stoppé le temps d'exécuter la procédure teste.

Mais ce problème peut aussi se produire avec on_change (ou on_key...)
Si vous modifiez le contenu d'un edit ou d'un memo auquel est inclut un Evénement on_change, celui-ci aussi provoque un déclenchement direct. Ici on utilise: OFF_CHANGE et ON_CHANGE. Il y a quand même un problème: c'est que si on bloque le déclenchement d'un on_change, les modifications faite pour cet EDIT ou autre ne sont pas connues. Et dans certains cas cela peut-être un problème.
Pour le cas d'un edit, ou pourrait par exemple mettre en mémoire le contenu de celui-ci avant le blocage, et le comparer après le déblocage, et voir la différence. Mais pour un memo, c'est pas vraiment concevable de mettre en mémoire tout le contenu, et le comparer avec celui du retour.

Il faudrait avoir une commande du genre: flag = Is_Modifie N, avec un retour de 0 et 1, vu que les valeurs booléennes n'existent pas ici.

( mille pardon, un petit écart dans le sujet )

@ Cosmos70,

Tu vois..., tu prends 10 minutes pour te relire et corriger les quelques fautes dues à la précipitation
pour répondre et au fait de penser prog.
Et tu as un petit article sur la gestion d' un timer...

...comme quoi, toi aussi tu es capable d' être un auteur du mag.

Bonjour.
Avant de penser à publier systématiquement un article sur ce que j'écris, il faudrait plutôt valider ou non, ce que j'affirme.
Je me suis demandé après coup si j'étais sur la bonne piste. Je m'explique:
Une déclaration sur le comportement d'une commande est d'abord subjective. Elle correspond à ce que l'on croit reconnaitre. Les calculs d'un ordinateur vont tellement vite, qu'il est difficile de discerner ce qui se passe vraiment.

Depuis je me pose une autre question. N'y aurait-il pas un bug sur timer. A de ce qui me reste lorsque je programmais en assembleur, mais peut-être une fois seulement, j'ai pas fait de programme d'interruption.
Mais normalement un programme d'interruption, il prend les données, sauvegarde des registres et autre, et une fois que le traitement est fait, il rétabli ceux-ci. Est-ce que c'est normal que le timer ne remette pas tout à sa place ce qu'il a trouvé avant? Je pense que c'est une vrai question.

Cosmos, si je me rappelle bien de l'interruption en assembleur (C'est vieux pour moi aussi) il fallait que le programmeur pousse dans la pile ce qu'il voulait sauvegarder et qu'il le dépile avant de rendre la main.

En fait, Jicehel, cela dépend de l'OS et du niveau de profondeur auquel on se situe.

Il y a des cas où l'OS se charge de sauvegarder, quelque fois même par firmware, l'ensemble des registres sur une pile avant de passer la main à la routine gérant l'interruption. Dans d'autres cas, toute ces travaux d'intendance sont à la charge du programmeur.

Dans le cas où le système d'en charge, le problème est juste déplacé d'un niveau: en fait, la vraie interrruption déroute le cours normal du programme vers une routine interne au noyau du système. Celle-ci se charge de la sauvegarde, détermine la nature de l'interruption et dispatche vers la routine d'interruption spécifique qui peut alors utiliser librement les registres.

Tout est une question de convention au départ. Et cela dépend aussi de la nature générale du système: un système multi-tâche en temps partagé n'utilise pas les mêmes conventions qu'un système temps-réel.

Dans notre cas, l'OS est une des multiples versions de Windows. C'est un système multi-tâche en temps partagé, mais nullement temps réel. A notre niveau, on n'a jamais, mais alors jamais, affaire à une interruption. Tout est géré de façon interne à Windows, avec un module de prise en charge extrêmement succinct qui passe l'interruption directement aux drivers de Windows, Ce sont eux qui se chargent de la sauvegarde et restitution des registres.

Ce qui nous concerne, ce sont les évènements Windows. C'est comme le Canada Dry: cela ressemble à une interruption, mais ce n'est est pas en réalité. Lorsque Windows a fini de prendre en charge une interruption via un driver, ce dernier envoie éventuellement un message au noyau de Windows.

En message est simplement une chaîne de caractères plus ou moins longue, avec un identifiant de l'expéditeur, un identifiant de la nature du message, puis des paramètres décrivant le message. En gros, tous ces messages sont mis dans une première file d'attente au sein même de Windows. Et, lorsque le noyeau de Windows a la main (dans le processus de partage de temps), il traite les messages en file d'attente, l'un après l'autre, pour le dispatcher vers le destinataire. C'est un peu comme un centre de tri: il prend le message, détecte sa nature et considère la situation actuelle de tous les processus dans la machine, puis l'expédie sous forme d'un nouveau message vers un destinataire (ce qui revient à le mettre dans une nouvelle file d'attente, dédiée à ce destinataire). Comme si l'on considérait le ou les premiers chiffres du code postal pour placer une lettre dans un panier destiné à un secteur géographique.

Lorsque ce destinataire a la main (dans le processus de temps partagé), il traite les messages de sa propre file d'attente, affine la détermination du destinataire et réexpédie le message par un mécanisme identique, et ce jusqu'au destinataire final (c'est le cheminement de la lettre jusqu'à la boite à lettres d'un particulier).

Mais pourquoi y a-t-il plusieurs destinataires ? Imaginons un list 3, placé dans un container 2, place à son tour dans une form 1, créée à son tour par la form 0 d'un programme demo. L'utilisateur clique sur le picture 3. La suite des évènements se présente alors comme suit:
- Windows reçoit une interruption hardware "évènement de souris"
- Windows dispatche vers le driver souris
- Le driver souris détermine la nature (clic gauche) et les coordonnées absolues x et y du clic
- Le driver souris envoie un message à Windows disant: "on a fait un clic gauche à (x,y)
- Windows reçoit ce message lorsque tous les autres messages en suspens sont traités. Windows détermine alors quel processus est propriétaire du pixel (x,y) de l'écran (on ne considère là que les fenêtres en avant-plan)
- Windows envoie alors un message au programme demo disant "il y a eu un clic droit en (x,y) pour toi"
- Le programme demo reçoit ce message lorsque tous les autres messages en suspens pour demo sont traites. Via un service système, le programme démo détermine alors quelle fenêtre contient les coordonnées absolues (x,y). Dans notre cas, c'est la form 1. On calcule les coordonnées (x1,y1) relatives à cette fenêtre.
- Le programme démo envoie alors un message à la form 1 disant "on a fait un clic gauche en (x1,y1) dans form 1"
- La form 1 reçoit le message... et détermine quel objet est concerné. Il découvre que c'est le container 2. On détermine les coordonnées (x2,y2) relatives au container 2. La form 1 envoie alors un message au container 2 disant "on a fait un clic gauche en (x2,y2) dans container 2".
-Le container 2 reçoit le message...et détermine quel objet est concerné. Il découvre que c'est le list 3. On détermine les coordonnées (x3,y3) relatives au list 3. Le container 2 envoie alors un message au list 3 disant "on a fait un clic gauche e, (x3,y3) dans list 3.
- Le list 3 reçoit le message...et appelle la routine évènement Windows du clic gauche du list 3. Conséquence: la ligne correspondant aux coordonnées (x3,y3) est sélectionnée. Et si Panoramic a déclaré une routine évènement utilisateur, celle-ci est appelée. Mais pas directement, car Windows n'a aucun moyen d'appeler directement une routine Panoramic ! L'objet list 3 appelle une routine interne à Panoramic qui à son tour, met un message dans une file d'attente interne à Panoramic, disant "on a fait un clic gauche sur le list 3".
- Lorsque le programme demo a la main (par le mécanisme de partage de temps), il traite ce message lorsque tous les autres messages internes à Panoramic sont traités. Et là, c'est Panoramic qui appelle la routine évènement de l'utilisateur, en simulant un GOSUB, raison pour laquelle une telle routine doit toujours se terminer par un RETURN, d'ailleurs.

On peut noter trois points importants:
1. La chaîne de traitement entre le fait déclenchant (clic gauche) et la conséquence finale (démarrage de la routine on-clic du list 3) est extrêmement longue et complexe. Et lorsqu'on sait que tout, mais alors absolument tout, génère des interruptions hardware, on imagine la charge cachée du système avant que le programmeur Panoramic ne puisse intervenir. Un simple déplacement de la souris génère littéralement des centaines d'interruptions qui sont toutes traitées par Windows par le mécanisme décrit ci-dessus, jusqu'au message final vers l'objet sous le curseur. Seulement, comme il n'y a pas d'évènement on_mouse_move en Panoramic, cela reste invisible pour le programmeur Panoramic.
2. La routine évènenent Panoramic appelée démarre à un instant t2 qui n'a pas de rapport direct avec l'instant t1 du fait initial (clic gauche). Il peut même arriver qu'une autre interruption hardware déclenchée à t2 après t1 arrive à son destinataire final en un temps t3 avant t2, par exemple si la chaîne des destinataires en cascade est plus courte (clic sur la croix rouge, par exemple). Il ne faut donc JAMAIS supposer que l'ordre dans lequel des routines évènement sont appelées, correspond à l'ordre dans lequel les faits déclenchants sont arrivés, même si en général c'est le cas. Mais ce n'est pas garanti.
3. Une routine évènement est un sous-programme Panoramic tout à fait normal. Il n'y a aucune notion de priorité, de protection ou quoi que ce soit de particulier. Et cela explique enfin de problème qui est à l'origine de ce fil de discussion. Une routine évènement s'exécute en "interrompant" le cours normal du programme Panoramic, suite à la simulation d'un GOSUB par le noyau de Panoramic. Mais une telle routine peut à son tout être interrompue par une autre, et ainsi de suite. Ce ne serait pas grave si les routines évènements étaient réentrantes. Or, ce n'est pas le cas: Panoramic ne connait pas cette notion. Conséquence: une routine évènement A utilise des variables. Elle est interrompue par la même routine A qui bien sûr utilise les mêmes variables. La routine A termine. Le retour se fait donc dans la routine A à l'endroit de l'interruption, mais les variables ont changé ! Et c'est le crash assuré.

Maintenant, j'en viens aux évènements des timers et des on_key_down etc. Il n'y a aucune différence de nature entre ces évènements et les autres. Seulement, dès qu'on active ces évènements, ils peuvent arriver à une fréquence beaucoup plus rapide, et surtout perpétuelle, que les évènements ponctuels tels qu'un clic sur un bouton. Conséquence: les routines évènement associés à ces évènements interrompent de façon répétée et fréquente, les routines évènement habituelles. Et si les précautions d'indépendance des environnements, variables etc ne sont pas prises, il y a forcément un problème. Si en plus, particulièrement pour un timer, le délai est si court qu'un nouvel évènement se déclenche avant que le précédent ne soit intégralement traité, les appels de sous-programmes s'empilent et saturent très rapidement la pile, ce qui conduit à un crash.

Lorsqu'on considère tout cela, on en vient à en déduire quelques règles simples:
- une routine d'évènement doit s'exécuter le plus rapidement possible
- si une routine évènement entraîne un temps de traitement significatif, il est impératif de bloquer, pendant le temps du traitement, absolument tous les évènements qui peuvent entrer en conflit avec le traitement en cours, et de réactiver tout cela à la fin du traitement.

Mille excuses d'avoir été si long, mais quelques fois, la précision s'impose.

Tu n'as pas a t'excuser mais si je peux me permettre un tout petit effort et quelques illustrations en plus et tu as un bon article pour le mag (Je pense notamment à une image qui illustre ton explication avec les temps t1, t2, t3)

En plus, je pense qu'en reprenant l'exemple de Cosmos et ces commentaires, ça peut servir beaucoup des personnes qui apprennent Panoramic à utiliser un Timer.

Je crois que l'on s'est tous fait avoir au début sur leur utilisation et on voit encore des gens qui utilisent un délai de 1 pour les timer (je ne citerais pas de nom Bignono, n'ait pas peur !! ;D). Quand on voit le mécanisme, on comprend que c'est un délai peu souhaitable, même si on arrête tout de suite le timer dans la procédure de traitement.

Dans l'article, je pense qu'il faudrait ajouter quelques références sur les délais de traitements moyens pour compléter l'article et les démos

Bonne idée. Je vais le retravailler un peu.

Bon sujet ! Très bon sujet !

Qui ne s' est pas fait piéger avec les "Timer" ? Pas grand monde je pense.


PS : En plus profitez en, On peut faire plein de fotes d' otographe Papydall est absent

Oui Papydall est absent, mais pas JL35

Il y a quand même un petit air de vacances pour l'écriture... JL35 rouspète moins souvent pour l'orthographe

bonjour a tous
merci c'est tres instructif et tres clair
encore merci
mindstorm

Merci Mindstorm, ça boost des commentaires comme ça pour continuer

Eh bien il y a de la lecture.
Klaus, les explications, c'est jamais de trop.
Tiens en relevant cela:

Code:

Dans l'article, je pense qu'il faudrait ajouter quelques références sur les délais de traitements moyens pour compléter l'article et les démos

Personnellement , je ne sais pas. Il y a plusieurs choses. Avec Pagiciel, j'ai vu que plus il y a d'objet, et certainement d'évènements, plus il faut un temps long sur un timer. Un intervalle de 200 par exemple sur un programme normal, avec Pagiciel, ça ne suffit pas. J'avais réglé je crois à 500.
En suite il y a la charge du processeur. Si par exemple l'anti-virus fonctionne en arrière plan, on peut doubler, tripler les délais. Je ne sais pas
Ensuite cela dépend du programme. Si tu as une procédure qui suit la souris, et ne fait rien d'autre avec le timer en arrière plan qui prend les paramètres, le temps peut être raccourcis, mais il faudra désactiver le timer, une fois qu'on quitte cette saisie. Je dirais que ce n'est pas mesurable dans l'absolu..

Maintenant pour aller au bout de cette discussion, J'ai oublié ma question. Il est temps que j'aille à la poubelle. (plaisanterie évidemment)
Entre parenthèse, il ne faut oublier qu'une procédure simple, peut en apeler une autre, beaucoup plus longue. Mais cela c'est pas la question que je voulais poser.

C'est exactement ça tu vois Cosmos qu'il faut expliquer pour les Timer

Justement, c'est le fruit de cette expérience qui manque au départ quand on met en place les timer en règle générale

Je reviens sur les deux erreurs signalées par RMont dans la page précédente, qui arrivent dans l'ordre:
1) paramètre incorrect
2) trop de gosub...
S'il y a un timer lancé, la deuxième erreur est inévitable, le programme s'arrête sur la première erreur mais le timer continue à tourner et à accumuler les appels au s/p, qui ne sont pas exécutés et qui s'empilent rapidement, donc la deuxième erreur est normale et à ignorer, corriger la première évitera la deuxième.

Cela dit le timer n'est pas toujours facile à maîtriser, ce truc invisible qui continue de tourner en arrière-plan.

Concernant l'orthographe, ne vous inquiétez pas, je surveille, mais je n'interviens certes pas à chaque fois, ça me ferait bien trop de boulot et je finirais par agacer tout le monde ! je laisse le plus gros à papydall qui a le dos large.

atom si tu veut des trucs sur les timers je peut t'en donné
par ce que grace a bignomo je commence a maitrisé le timer
et comprendre pas mal d'erreur a evité , avec cette commande
tu peut faire bcp de choses insolites
a+

Vous remarquerez que je me maîtrise, pour l'orthographe...

Wouai, il y a du favoritisme... je fais une faute ou deux, j'ai le droit à un message... Certains en font 10 en 4 lignes et à peine une remarque ... Je suis vert