Comment éviter de perturber un timer?

Vous débutez et vous avez besoin d'aide ? N'hésitez pas à poser vos questions
Torp
Messages : 360
Inscription : lun. 22/nov./2004 13:05

Message par Torp »

Merci Chris, c'est vrai qu'avec un WindowEvent() avec un delay ca marche nickel...
Le WaitWindowEvent est donc à proscrire dans mon cas? Moi qui croyais bien faire.
L'emploi de l'un ou l'autre dépends donc du type d'appli que l'on developpe.. c'est ca?
Avatar de l’utilisateur
Chris
Messages : 3731
Inscription : sam. 24/janv./2004 14:54
Contact :

Message par Chris »

Bien sûr, mais tu fais ta boucle uniquement pour fermer ton prog, pas pour gérer les timers.

D'ailleurs, je serais Fred, j'empecherai la gestion des timers dans la boucle. Ca met le bordel plus qu'autre chose.

Bon, ça c'était la réponse à Régis :lol:
Avatar de l’utilisateur
Chris
Messages : 3731
Inscription : sam. 24/janv./2004 14:54
Contact :

Message par Chris »

@Torp

Voir l'aide:
WaitWindowEvent()
Bloque l'exécution du programme jusqu'à ce qu'un événement intervienne. Cette fonction est identique à WindowEvent(), mais le blocage de l'exécution est très important dans un environnement multi-tâches. Une application devrait, si possible, toujours utiliser cette fonction en préférence à WindowEvent(). Pour plus d'informations sur les evenements supportés, voir WindowEvent().
Dans ton cas, il faut justement eviter de bloquer l'application
Le Soldat Inconnu
Messages : 4312
Inscription : mer. 28/janv./2004 20:58
Localisation : Clermont ferrand OU Olsztyn
Contact :

Message par Le Soldat Inconnu »

moi, je gère aucun Timer par procedure, toujours par l'évènement #WM_Timer par habitude et je trouve ça plus pratique :)

De toute façon, il faut séparer la boucle de gestion des évènements et la boucle d'affichage sans quoi le tampon qui reçoit les évènement se rempli plus vide qu'il n'est vidé à cause du temps d'affichage qui est très long (à cause du flipbuffers qui attend la synchro avec l'écran)
et ça, c'est la cause de ce problème :roll: :mrgreen:

Quand on déplace la souris en continu dans ton code d'origine, on rempli le tampon des évènements avec des #WM_MouseMove
et pour le vider, ça met 10 ans car à chaque lecture d'un évènement, il faut affiché ensuite
500 pixels de déplacement de la souris donc 500 #WM_MouseMove à 85hz pour le flipbuffer donne 500/85=5.8 secondes pour purger le tampon des évènements.
bon, j'exagère mais c'est à peu près ce qui se passe.

et la, il y a plusieurs solutions :
- rafraichir l'affichage uniquement quand on en a besoin
- purger les évènements en priorité puis faire l'affichage ensuite

voir mes 2 codes, c'est exactement ce que j'ai fais :wink:


Message édité
Dernière modification par Le Soldat Inconnu le jeu. 16/déc./2004 0:26, modifié 2 fois.
Je ne suis pas à moitié Polonais mais ma moitié est polonaise ... Vous avez suivi ?

[Intel quad core Q9400 2.66mhz, ATI 4870, 4Go Ram, XP (x86) / 7 (x64)]
Torp
Messages : 360
Inscription : lun. 22/nov./2004 13:05

Message par Torp »

ouaow! C'est :x-mas:
Merci à tous pour vos explications... vais étudier tout ca!
Il est vraiment trop bon ce forum... :10:

++
nico
Messages : 3702
Inscription : ven. 13/févr./2004 0:57

Message par nico »

J'étais comme le Soldat, j'utilisais le messsage #wm_timer mais je me suis rendu compte que ça causait d'énorme problème (des blocages).J'utilise et je recommande les procédures.
Le Soldat Inconnu
Messages : 4312
Inscription : mer. 28/janv./2004 20:58
Localisation : Clermont ferrand OU Olsztyn
Contact :

Message par Le Soldat Inconnu »

oui, enfin, ici, il était dans une procedure et ça n'a pas empêché le blocage du au fait que j'ai cité ci-dessus :lol:
donc argument non valable, votre honneur :jesors:
Je ne suis pas à moitié Polonais mais ma moitié est polonaise ... Vous avez suivi ?

[Intel quad core Q9400 2.66mhz, ATI 4870, 4Go Ram, XP (x86) / 7 (x64)]
Avatar de l’utilisateur
Chris
Messages : 3731
Inscription : sam. 24/janv./2004 14:54
Contact :

Message par Chris »

Pfff
De toute façon, on sait très bien que tu n'aimes pas avoir tort
Alors...
Le Soldat Inconnu
Messages : 4312
Inscription : mer. 28/janv./2004 20:58
Localisation : Clermont ferrand OU Olsztyn
Contact :

Message par Le Soldat Inconnu »

:lol:

je sais pas lequel est le mieux et franchement, n'ayant jamais de prob avec #Wm_Timer, pourquoi que je me fatiguerai avec une procedure, hein ? :0:

de toute façon, ici, le timer n'a rien à voir avec le problème, c'est juste une histoire d'agencement de la gestion des évènement
Je ne suis pas à moitié Polonais mais ma moitié est polonaise ... Vous avez suivi ?

[Intel quad core Q9400 2.66mhz, ATI 4870, 4Go Ram, XP (x86) / 7 (x64)]
nico
Messages : 3702
Inscription : ven. 13/févr./2004 0:57

Message par nico »

Peu importe de le prendre en compte ou pas, l'essentiel est de connaître l'info.

:)
hardy
Messages : 333
Inscription : mer. 02/juin/2004 13:19
Localisation : Tours

Message par hardy »

Je suis comme nico : procedures. Gérer un timer dans une boucle événementielle, c'est le B...
Avatar de l’utilisateur
Chris
Messages : 3731
Inscription : sam. 24/janv./2004 14:54
Contact :

Message par Chris »

Pour l'instant, on est trois contre toi!

T'est mal, là :lol:
nico
Messages : 3702
Inscription : ven. 13/févr./2004 0:57

Message par nico »

Je poste un code, le code n'ayant un sens que pour la démonstration:
la procédure est nettement plus stable, de plus lorsque l'on déplace la fenêtre, le timer ne se bloque pas! En gros ça se passe de commentaires.

Code : Tout sélectionner

Procedure TimerProc(Hwnd.l, uMsg.l, idEvent.l, dwTime.l) 
  Select uMsg 
    Case #wm_timer 
      Select idEvent 
        Case 1 
          Debug "procedure"
      EndSelect 
  EndSelect 
EndProcedure 


If OpenWindow(0,0,0,600,300,#PB_Window_SystemMenu|#PB_Window_ScreenCentered,"WebGadget") And CreateGadgetList(WindowID(0)) 
  WebGadget(0,10,10,580,280,"file://c:\PureBasic  Index.htm") 
  ;/choix 1
  settimer_(WindowID(0),1, 1000, @TimerProc())
  
  ;/choix 2
  ;settimer_(WindowID(0),1, 1000, #Null)
  Repeat
    Event=WaitWindowEvent()
    Select Event
      ;/choix 2
      ;Case #wm_timer
        ;Debug "#wm_timer"
    EndSelect
    
    Until WaitWindowEvent()=#PB_Event_CloseWindow 
EndIf 
Avatar de l’utilisateur
Chris
Messages : 3731
Inscription : sam. 24/janv./2004 14:54
Contact :

Message par Chris »

Vlan...!
Dans les dents :mrgreen:
Le Soldat Inconnu
Messages : 4312
Inscription : mer. 28/janv./2004 20:58
Localisation : Clermont ferrand OU Olsztyn
Contact :

Message par Le Soldat Inconnu »

PB bloque les évènements vers WindowEvent() quand on déplace la fenêtre :? 8O

voir ce code qui passe pas par une procedure mais qui récupère le #WM_Timer dans un callback

Code : Tout sélectionner

Procedure WinCallback(WindowID, Message, wParam, lParam)
  Result.l = #PB_ProcessPureBasicEvents
  If Message = #WM_TIMER
      Select wParam
        Case 2
          Debug "Timer callback"
      EndSelect
  EndIf
  ProcedureReturn Result
EndProcedure


If OpenWindow(0,0,0,600,300,#PB_Window_SystemMenu|#PB_Window_ScreenCentered,"WebGadget") And CreateGadgetList(WindowID(0)) 

  ;/choix 2 
  SetTimer_(WindowID(0),2, 1000, #Null) 
  
  SetWindowCallback(@WinCallback())
  
  Repeat 
    Event = WaitWindowEvent() 
    
    If Event = #WM_TIMER
      Select EventwParam()
        Case 2
          Debug "Timer boucle"
      EndSelect
    EndIf
    
    Until Event =#PB_Event_CloseWindow 
EndIf 
comme quoi, c'est pas le timer mais le WindowEvent()

En tous cas, j'avais pas du tout songé à ça.

C'est un bug de PB, ça pour vous ?
Je ne suis pas à moitié Polonais mais ma moitié est polonaise ... Vous avez suivi ?

[Intel quad core Q9400 2.66mhz, ATI 4870, 4Go Ram, XP (x86) / 7 (x64)]
Répondre