Discussion :

[r0d]

Bonjour à tous,

Le timer de la classe CWnd est très pratique. Malheureusement pas très précis, mais d'une facilité d'utilisation vraiment agréable. Mais son comportement n'est pas précisé dans la msdn, et notamment que ce passe-t-il dans le cas ci-dessous:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
void MaDlg::OnTimer(UINT nIDEvent)
{
	switch (nIDEvent)
	{
	case 1:
		maFonction();
	break;
 
	...
	}
}

Dans ce cas, on a une fonction appelée à chaque fois que OnTimer est appelé. La fréquence à laquelle est appelée OnTimer() dépend des paramètres de SetTimer().

Question: que se passe-t-il si maFonction() n'a pas fini d'être exécutée quand OnTimer() est apellé à nouveau?

merci.

[lenouvo]

et bien soit le programme instancie ta fonction une 2eme fois, soit ca plante.

[Brouzouf]

Salut,
Ta fonction sera appelée deux fois par le même thread, ce qui peut être dangereux.
On peut avoir le même problème lors d'un clique sur un bouton, deux cliques appelant une fonction qui rend la main mais qui n'a pas terminée sont traitement lors du deuxième clique.

[r0d]

En fait, je viens de faire le test suivant:
Je lance simultanément 2 timers, tous les 2 avec un timeout de 500 ms chacun.
A l'appel de OnTimer, chacun écrit, dans une list box (mclbMain), le temps écoulé depuis le début.

Voici le code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
BOOL CTestTimerDlg::OnInitDialog()
{
...
	muiTimer1 = (UINT) SetTimer(0, 500, NULL); 
	muiTimer2 = (UINT) SetTimer(1, 500, NULL);
	mbTimeSet = FALSE;
...
}
 
void CTestTimerDlg::OnTimer(UINT nIDEvent)
{
	DWORD dwNewTime;
	CString csTemp, csTemp2;
 
	if (!mbTimeSet)
	{
		mdwInitTime = GetTickCount();
		mbTimeSet = TRUE;
	}
	dwNewTime = GetTickCount();
	csTemp.Format("%d",(int) dwNewTime-mdwInitTime);
 
	switch (nIDEvent)
	{
	case 0:
		csTemp2.Format("%s%s","Timer 1 :  ",csTemp);
		mclbMain.AddString(csTemp2);
		fnWait();
		break;
 
	case 1:
		csTemp2.Format("%s%s","Timer 2 :  ",csTemp);
		mclbMain.AddString(csTemp2);
		break;
	}
 
	CDialog::OnTimer(nIDEvent);
}
 
void CTestTimerDlg::fnWait()
{
	mclbMain.AddString("wait 1");
	Sleep(1000);
	mclbMain.AddString("wait 2");
}

Et le résultat:

timer2 : 0
timer 1: 0
wait 1
wait 2
Timer 2 : 1000
Timer 1 : 1000
wait 1
wait 2
Timer 2 : 2000
Timer 1 : 2000
etc...

Ce qui prouve que:

Un seul thread gère tout ça, même s'il y a plusieurs timers. Le Timer2 aurait dû être exécuté toute les 500 ms, or on voit ici qu'il attend que le Timer1 ait terminé son travail. Idem pour Timer1, il attend que lui-même ait fini son job avant de continuer.

Maintenant, je n'ai pas l'impression que ce soit dangereux (alors que l'exemple de 2 clics sur un bouton peut l'être, c'est pour cette raison que j'"encadre" mes fonction OnBnClickMachin avec des locks (de simples booleens) ). En effet:

A time-out value is specified, and every time a time-out occurs, the system posts a WM_TIMER message to the installing application's message queue

Ce qui signifie (je crois) que le timer fonctionne ainsi:
1/ Il lance le message WM_TIMER
2/ Le message est traité.
3/ x millisecondes (time_out) après, WM_TIMER est lancé (mis dans la file des messages)
4/ quand le message peut-être traité, il l'est.
5/ retour au 3/

Donc en fait, pas de risque d'overflow ou de choses dans ce goût. Enfin si j'ai bien compris.