Page 2 sur 4

Publié : jeu. 16/déc./2004 0:10
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?

Publié : jeu. 16/déc./2004 0:11
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:

Publié : jeu. 16/déc./2004 0:14
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

Publié : jeu. 16/déc./2004 0:18
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é

Publié : jeu. 16/déc./2004 0:23
par Torp
ouaow! C'est :x-mas:
Merci à tous pour vos explications... vais étudier tout ca!
Il est vraiment trop bon ce forum... :10:

++

Publié : jeu. 16/déc./2004 0:28
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.

Publié : jeu. 16/déc./2004 0:35
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:

Publié : jeu. 16/déc./2004 0:37
par Chris
Pfff
De toute façon, on sait très bien que tu n'aimes pas avoir tort
Alors...

Publié : jeu. 16/déc./2004 0:37
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

Publié : jeu. 16/déc./2004 0:57
par nico
Peu importe de le prendre en compte ou pas, l'essentiel est de connaître l'info.

:)

Publié : jeu. 16/déc./2004 0:59
par hardy
Je suis comme nico : procedures. Gérer un timer dans une boucle événementielle, c'est le B...

Publié : jeu. 16/déc./2004 1:01
par Chris
Pour l'instant, on est trois contre toi!

T'est mal, là :lol:

Publié : jeu. 16/déc./2004 1:10
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 

Publié : jeu. 16/déc./2004 1:19
par Chris
Vlan...!
Dans les dents :mrgreen:

Publié : jeu. 16/déc./2004 9:56
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 ?