PureBasic

Non, pour moi, c'est un comportement normal.
Le message WM_Timer a une priorité basse, par rapport aux autres messages. Il est donc traité dans les derniers quand il passe par la boucle.

Par contre, à moins que je ne dise une connerie, (je ne suis pas à une près

), les callbacks, (et une procédure appelée directement par le timer en est une), tournent dans un thread différent, et sont donc indépendantes de la boucle.

Il faudrait l'avis d'un VRAI programmeur, là.

Pour moi, ça vient de la fonction Waitwindowevent, mais ça reste normal vu que c'est Pure qui gère la boucle.

Suis de l'avis de chris.
De toute façon, un message WM_Timer "fait la queue" comme tous les messages envoyés à une fenêtre.
Et si la queue des messages est encombrée...
Le mieux est, non seulement de créer une procédure à part, mais de créer un timer non attaché à une fenêtre (setttimer_(0,...))

hardy a écrit :Le mieux est, non seulement de créer une procédure à part, mais de créer un timer non attaché à une fenêtre (setttimer_(0,...))

Oui, mais c'est peut-être pas toujours possible.
Si il y a la possibilité de passer le handle d'une fenêtre, c'est sans doute que ça a une utilité, quelque part. (Me demandez pas laquelle, par contre)

Détruire le timer quand on quitte le programme, je pense

Le Soldat Inconnu a écrit :Détruire le timer quand on quitte le programme, je pense

Non pas du tout, la différence de déclaration d'un timer avec ou non le handle de fenêtre se situe au niveau du message wm_timer ; dans le deuxième cas la procédure de fenêtre ne traiteras pas ce message et donc il n'y a plus de traitement de ce message même dans la procédure du timer.

Donc, comme le dit Hardy, il n'y a plus de problème de file d'attente.

Si je suis le raisonnement d'Hardy, il n'est pas forcé d'attacher un timer à une fenetre. J'ai donc déclaré mes Settimer avec 0 <Timer1=SetTimer_(0, 1, 1000, @Sablier())>, mais du coup ils ne demarrent plus...

Dans ce cas, il ne faut pas donner de n° au timer, il faut récupérer son identifiant quand tu le crée, et tu testes cet identifiant dans la procédure pour savoir quel timer à envoyé le message.

Code : Tout sélectionner

;/Constantes Window
Enumeration
  #Window_0
EndEnumeration

;/Constantes Gadget
Enumeration
  #Btn_Quit
EndEnumeration

Global T1,T2

Procedure TimerProc(hwnd.l, uMsg.l, idEvent.l, dwTime.l)
  Select uMsg
    Case #WM_TIMER
      Select idEvent
        Case T1
          Debug "timer 1"
        Case T2
          Debug "timer 2"
      EndSelect
  EndSelect
EndProcedure

If OpenWindow(#Window_0, 300, 300, 300, 200, #PB_Window_SystemMenu, "Fenêtre 1",0)
  If CreateGadgetList(WindowID(#Window_0))
    ButtonGadget(#Btn_Quit, 100, 170, 100, 25, "Quitter")
  EndIf
  
  T1 = SetTimer_(#Null, #Null, 1000, @TimerProc())
  T2 = SetTimer_(#Null, #Null, 2500, @TimerProc())
  
  Repeat
    Select WaitWindowEvent()
      Case #PB_EventGadget
        Select EventGadgetID()
          
          Case #Btn_Quit : quit = 1
        EndSelect
        
      Case #PB_EventCloseWindow : quit = 1
    EndSelect
  Until quit = 1
  End
EndIf

PS : Quand je dis "...il ne faut pas donner de n° au timer...", il faut lire "...tu n'as pas besoin de donner.....". De toute façon, si tu lui donnes un n°, il n'est pas pris en compte.

ou sinon, tu crée des procédures différentes pour les divers timers.

Bon ok ca fonctionne...
Alors je sais pas si c'es moi qui suis bouché..., mais il y a tout de meme un truc que j'ai pas pigé. Si le timer est exécuté dans thread différent et qu'en plus il n'est meme plus attaché à ma fenetre, je ne comprends pas pourquoi alors mon WaitWindowEvent de la boucle principale de mon prog, vient le perturber dans son déroulement. (toujours mon exemple lorsque je bouge la souris et que j'appuis sur le bouton). C'est moi qui suis débile ou quoi? (siou plait dites moi que non...

)

Moi, ce que je ne pige pas, c'est pourquoi tu t'acharnes à vouloir mettre un WaitWindowEvent, alors qu'il ne t'est pas utile

héhé suis tétu... Non c'est pas ce que depuis que j'uilise WindowEvent, mon prog est moins...euh... réactif. Je ne sais pas si tu te rappelles du prog que je suis entrain de faire, mais lorsque je déplace mes pions et lorsque je les lachent dans les cases, avec WaitWindowevent ca marche nickel, mais avec WindowEvent il y a des temps de latences qui font que parfois mon prog ne dérecte pas toujours que j'ai laché un pion ou il faut que j'insiste plus pour en prendre un. Ceci meme avec un delay dans la boucle principale.. C'est un peu mou quoi.

met un delay(1) ou (2) au lieu de (20) !!

Ah oui, c'est vrai qu'il faut lacher les pions

Alors essaye de gérer les évènements de la fenêtre dans une callback, ou utilise la librairie Mouse

Je commence à être à bout d'arguments, là

J'avais déjà essayé avec un delay de 1 c'étair pareil...
Mais je viens d'enlever ca :

Select WindowEvent()
Case 0
Delay(1)
EndSelect

et j'ai laissé juste le Delay(1)

et là ca marche nickel....

Voili voilou...

Et encore merci à tous !

Euh veut pas faire le casse bonbon, mais meme si maintenant ca marche bien avec WINDOWEVENT() (je vais d'ailleurs conserver cette solution!), mais j'ai toujours pas compris pourquoi un WaitWindowEvent() vient perturber un timer par procedure qui de plus n'est pas attaché à la fenetre...

PureBasic

Comment éviter de perturber un timer?