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

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
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
Message édité
Publié : jeu. 16/déc./2004 0:23
par Torp
ouaow! C'est

Merci à tous pour vos explications... vais étudier tout ca!
Il est vraiment trop bon ce forum...
++
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
donc argument non valable, votre honneur

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
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 ?
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à

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

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
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 ?