cs_elbok
Messages postés12Date d'inscriptionmardi 4 mars 2008StatutMembreDernière intervention28 avril 2008
-
6 avril 2008 à 16:43
cs_jfrancois
Messages postés482Date d'inscriptionvendredi 26 août 2005StatutMembreDernière intervention 5 décembre 2009
-
7 avril 2008 à 16:03
j'ai essayé d'écrir ce code(j'utilise Visual C++ mais jécris en C application Win32)
//je veux créer un thread qui fait appele à une procédure(verifier_connexion(cli,&v);)
DWORD __stdcall threadroutine ((void *param)
{
BOOL bEnd = FALSE;
// Tant que bEnd est à FALSE, on continue
while(!bEnd) {
//ce tread doit appeler une fonction qui est la suivante
verifier_connexion(cli,&v);
printf("\n");
Sleep(100);
}
return 0;
}
mais le problème que si je change l'appele de la procédure par un simple affiche c'est bon, mais pour l'appele de procédure il existe tjrs un problème
je n'es pas compris ou est le problème.
je veux savoir comment faire un appel d'une procédure verifier_connexion(cli,&v); à travers un thread
aidez moi S.V.P c'est trés trés urgent
merçi d'avance.
SAKingdom
Messages postés3212Date d'inscriptionlundi 7 novembre 2005StatutMembreDernière intervention16 février 200915 6 avril 2008 à 17:00
"mais pour l'appele de procédure il existe tjrs un problème".
Quel est ce problème ?
Déjà:
BOOL bEnd = FALSE;
// Tant que bEnd est à FALSE, on continue
while(!bEnd) {
Tu ne sortiras jamais de la boucle ainsi, car bEnd n'est jamais mit à TRUE.
verifier_connexion(cli,&v);
cli et v sont des variables globales j'imagine. Ça signifie donc que rien ne garantis que leur valeurs seront différente lors du prochain appel à verifier_connexion. Ainsi donc, rien ne garantis non plus au thread modifiant ces valeurs qu'elles seront bien traitées.
cs_elbok
Messages postés12Date d'inscriptionmardi 4 mars 2008StatutMembreDernière intervention28 avril 2008 7 avril 2008 à 09:52
merci j'ai pu au moins localiser ou est le problème. mais savez vous S.V.P une autre méthode pour appeler cette procédure par exemple toute les 100 ms sans passer par les threads en utilisant les timers. je n'est aucune idée mais j'entend parler et j'ai même effectuer un recherche mais je n'est pas trouvé ce que je cherche.
merçi bien
cs_jfrancois
Messages postés482Date d'inscriptionvendredi 26 août 2005StatutMembreDernière intervention 5 décembre 20092 7 avril 2008 à 13:07
Il y a 2 méthodes d'utilisation des timers de Windows :
- Avec gestion du message WM_TIMER dans la fenêtre propriétaire.
- Avec appel direct d'une fonction.
Voici les 2 méthodes d'utilisation avec 2 timers à chaque fois :
1) Méthode avec gestion du message Windows
#define ID_TIMER_1 1000 // identificateur du timer 1
#define ID_TIMER_2 1001 // identificateur du timer 2
// --- Fonction de gestion des messages de la fenêtre
LRESULT CALLBACK WinProc
(
HWND hWnd // I:handle to the window
,UINT uiMsg // I:message to process
,WPARAM wParam // I:WPARAM parameter
,LPARAM lParam // I:LPARAM parameter
) // O:return code
{
switch (uiMsg)
{
// ----------------
// Créer la fenêtre
// ----------------
case WM_CREATE : // si c'est une fenêtre classique
case WM_INITDIALOG : // si c'est une boîte de dialogue
{
...
// --- Lancer les timers
SetTimer(hWnd,ID_TIMER_1,1000,NULL);// toutes les 1s
SetTimer(hWnd,ID_TIMER_2,2000,NULL);// toutes les 2s
}
return 0;
// ------------------
// Traiter les timers
// ------------------
case WM_TIMER :
{
if (wParam = = ID_TIMER_1)
{
...
Traitement du timer 1 ...
}
else if (wParam == ID_TIMER_2)
{
...
Traitement du timer 2 ...
}
}
return 0;
// ---------------------
// Quitter l'application
// ---------------------
case WM_DESTROY : // si c'est une fenêtre classique
case "quitter" dans WM_COMMAND : // si c'est une boîte de dialogue
{
...
// --- Retour du traitement par défaut
return DefWindowProc(hWnd,uiMsg,wParam,lParam);
}
2) Méthode avec appel direct d'une fonction
// --- Fonction de traitement du premier timer
VOID CALLBACK Fonction1
(
HWND hWnd // I:handle to the window
,UINT uiMsg // I:WM_TIMER message
,UINT uiEvent // I:timer identifier
,DWORD dwTime // I:current system time
)
{
... Traitement du timer 1 ... }
// --- Fonction de traitement du second timer
VOID CALLBACK Fonction2
(
HWND hWnd // I:handle to the window
,UINT uiMsg // I:WM_TIMER message
,UINT uiEvent // I:timer identifier
,DWORD dwTime // I:current system time
)
{
... Traitement du timer 2 ... }
// --- Fonction de gestion des messages de la fenêtre
LRESULT CALLBACK WinProc
(
HWND hWnd // I:handle to the window
,UINT uiMsg // I:message to process
,WPARAM wParam // I:WPARAM parameter
,LPARAM lParam // I:LPARAM parameter
) // O:return code
{
static int iIDTimer1; // ID du timer 1
static int iIDTimer2; // ID du timer 2
switch (uiMsg)
{
// ----------------
// Créer la fenêtre
// ----------------
case WM_CREATE : // si c'est une fenêtre classique
case WM_INITDIALOG : // si c'est une boîte de dialogue
{
...
// --- Set the timers
iIDTimer1 = SetTimer(NULL,0,1000,Beep1); // toutes les 1s
iIDTimer2 = SetTimer(NULL,0,2000,Beep2); // toutes les 2s
}
return 0;
// ---------------------
// Quitter l'application
// ---------------------
case WM_DESTROY : // si c'est une fenêtre classique
case "quitter" dans WM_COMMAND : // si c'est une boîte de dialogue
{
...
SAKingdom
Messages postés3212Date d'inscriptionlundi 7 novembre 2005StatutMembreDernière intervention16 février 200915 7 avril 2008 à 15:21
Le problème est que son application est de type console (d'après un post précédent). Utiliser les timers demande absolument une boucle à messages qui bloquera par conséquence le thread principal.
Cependant, dans une application console, bloquer le thread principal n'est, en général, pas très recommandé du fait que le déroulement de l'application ne dépend pas de messages interceptables par cette boucle à messages (à l'inverse d'une application GUI).
La seule solution donc, pour ne pas bloquer le thread principal (dans la probabilité qu'il en ai encore besoin) est de créer un second thread.
cs_jfrancois
Messages postés482Date d'inscriptionvendredi 26 août 2005StatutMembreDernière intervention 5 décembre 20092 7 avril 2008 à 16:03
En effet si c'est une application console tout ça n'est pas terrible !
Mon cher elbok, il serait temps de passer à une "vraie" application win32 ! C'est pas si compliqué que ça en à l'air, surtout passé la rédaction de la première "carcasse" de programme (ça sera quasiment toujours le même point de départ pour tous les programmes). Ensuite on passe en revue, petit à petit, toutes les possibilités offertes par Windows via l'API Win32 ... et il y en a !