Problème d'affichage de signaux à l'écran

Version imprimable

20/03/2013, 15h53
kurul1

Problème d'affichage de signaux à l'écran

Bonjour à tous

Je doit concevoir un logiciel chargé d'afficher une séquence de signaux à l'écran (Textes et sigles)

Mon souci est le suivant

Quand j'effectue un test de mon logiciel dans XE3 directement (Exécution), aucun souci d'affichage
Lorsque j'exécute le logiciel directement en lançant l'exécutable il y a des signaux qui n'apparaissent pas.

Est-ce que quelqu'un aurait une idée.

Mes signaux je les dessine sur le Canvas avec la fonction TextOut
La form est en double Buffer
Le temps d'affichage de mes signaux est déterminé par un Thread qui calcule le temps (QUERY_PERFORMENCE COUNTER) et qui renvoit un booléen à true au programme quand le temps impartit au Signal est terminé pour qu'il passe au suivant.
Je ne voulais pas utiliser un Timer car trop imprécis et je ne voulais pas non plus que le programme soit bloquant pendant un Signal pour pouvoir interrompre une séquence.

Merci d'avance pour votre aide
20/03/2013, 16h18
totoche76

Citation:

Envoyé par kurul1

Quand j'effectue un test de mon logiciel dans XE3 directement (Exécution), aucun souci d'affichage
Lorsque j'exécute le logiciel directement en lançant l'exécutable il y a des signaux qui n'apparaissent pas.

Quand tu lances l'exécutable directement, est-ce qu'il y a une différence de mode de compilation (DEBUG/RELEASE) ?
Exécution dans l'IDE en compilant en debug ou en release...
Exécution en dehors en compilant en debug ou en release...
(Comportement différent en debug et en release: présomption de variable non initialisée)

Citation:

Envoyé par kurul1

Est-ce que quelqu'un aurait une idée.

Mes signaux je les dessine sur le Canvas avec la fonction TextOut
La form est en double Buffer
Le temps d'affichage de mes signaux est déterminé par un Thread qui calcule le temps (QUERY_PERFORMENCE COUNTER) et qui renvoit un booléen à true au programme quand le temps impartit au Signal est terminé pour qu'il passe au suivant.

Comment se fait la comm entre ton thread de gestion des signaux et le thread principal de l'appli ? Comment le thread principal est-il prévenu qu'il doit mettre à jour l'affichage ?
Tu parles d'un booléen... C'est une variable ? Si c'est le cas est-ce que tu as fait gaffe à bien gérer les accès concurrents sur cette variable (section critique par exemple) ?

Merci pour ta réponse totoche76

Alors après les différents tests que tu m'as conseillé
Exécution dans l'IDE identique entre Debug et Release cela fonctionne normalement
Exécution extérieure identique entre Debug et Release il y a certains signaux qui n'apparaissent pas.

Concernant la gestion du Thread

J'ai déclaré dans le Thread 2 variables

Code:

1
2
3
4
5
6
 
	// Booléen pour savoir si le Thread à terminé
	bool Termine;
 
	// Temps
	int Temps;

Le Constructeur de mon Thread a des paramètres

Code:

1
2
3
4
5
6
7
8
 
// Constructeur avec paramètres
__fastcall MonThread::MonThread(bool CreateSuspended, int Tps)
	: TThread(CreateSuspended), Temps(Tps)
{
	// On met le booléen pour marquer la fin du Thread à false
	Termine = false;
}

Voilà ce que je fait dans la fonction Execute du Thread

Code:

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
 
void __fastcall MonThread::Execute()
{
	static __int64 FrequenceHorloge;
	static __int64 Debut;
	static __int64 Fin;
 
	// On initialise le tempsCourant à 0
	double TempsCourant = 0;
 
	// booléen pour la sortie de boucle
	bool Sortie = false;
 
	// On calcule la fréquence de l'horloge
	QueryPerformanceFrequency((LARGE_INTEGER*)&FrequenceHorloge);
 
	// On calcule le temps de départ
	QueryPerformanceCounter((LARGE_INTEGER*)&Debut);
 
	do
	{
		Application->ProcessMessages();
 
		// On calcule la Fin
		QueryPerformanceCounter((LARGE_INTEGER*)&Fin);
 
		// On calcule le Temps Courant
		TempsCourant = (1000 * ((Fin - Debut) / (double)FrequenceHorloge));
 
		// Si l'on à atteint le Temps ou que l'on doit terminé le Thread
		if(Termine || (TempsCourant >= double(Temps)))
		{
			// On sort de la boucle
			Sortie = true;
		}
	}
	// Tant que l'on ne doit pas sortir de la boucle
	while(!Sortie);
 
	// On marque que l'on à terminé
	Termine = true;
}

Et donc voilà comment j'appelle et communique avec le Thread dans le programme principal

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
	// On lance le Thread
	Thread = new MonThread(false, Temps);
 
	// On marque qu'il faut nettoyé à la sortie du Thread
	Thread->FreeOnTerminate = true;
 
	// Tant que le Thread n'est pas terminé
	while(!Thread->Termine)
	{
		// Si l'on doit quitter l'application
                // La variable QuitterApplication est mise à true lorsque l'on tape echap au clavier (OnKeyPress)
		if(QuitterApplication)
		{
			// On termine le Thread
			Thread->Termine = true;
		}
 
		Application->ProcessMessages();
	}

L'affichage est géré dans le programme principal, il est fait avant l'appel du Thread et lorsque le Thread est terminé, on passe a l'affichage du Signal suivant

21/03/2013, 11h57
totoche76
Code:

1 2 3 4 5 6 void __fastcall MonThread::Execute() { .... do { Application->ProcessMessages();
Houlaaaaaa.....
Déjà, gros mélange des genres: Application->ProcessMessages() c'est pour gérer la boucle des messages associée au thread principal, donc quand tu es dans un autre thread, c'est "pas touche".

Comment est géré l'affichage dans le thread principal ?? Tu dessines directement sur le Canvas du form ??? Tu géres bien l’évènement OnPaint du form ??
~~Si le but du thread est juste de faire une tempo, un Sleep suffit.... Pas besoin de compteurs de performance pour ça.~~
EDIT-
(bon ok Sleep n'est pas très précis, admettons...)
Remplaces Application->ProcessMessages() par un Sleep(1) ou Sleep(10) (quelques ms de décalage pour ta affichage, ça devrait aller, non ?)
-EDIT
Et tes signaux ? tu as une liste de signaux à afficher, chacun avec un temps d'affichage associé, c'est ça ?? Cette liste évolue au cours de l'exécution de l'appli ?
21/03/2013, 12h09
kurul1

Pour le Process Message je l'enlève sans souci petite erreur

Sinon concernant l'affichage, oui je dessine directement sur le Canvas mais je n'utilise pas le OnPaint je le fait directement dans une fonction qui dessine sur l'écran, surement une autre erreur de ma part, je vais essayer de modifier mon programme pour voir si cela fonctionne mieux.

Concernant le Sleep que tu me propose, il est bloquant c'est à dire que tant qu'il n'est pas terminé les évènements clavier ne sont pas pris en compte et ce n'est pas ce qui m'intéresse et connaissant la précision des Timer, j'ai opté pour cette solution pour avoir un temps plus précis

Concernant les Signaux, c'est une liste qui est fixe pour un Protocole donné elle n'évolue pas pendant le cycle d'affichage.

Un Signal est en fait un texte à afficher avec un arrière-plan, une couleur, une taille et une police déterminée.
21/03/2013, 13h52
totoche76

Citation:

Envoyé par kurul1

Sinon concernant l'affichage, oui je dessine directement sur le Canvas mais je n'utilise pas le OnPaint je le fait directement dans une fonction qui dessine sur l'écran, surement une autre erreur de ma part, je vais essayer de modifier mon programme pour voir si cela fonctionne mieux.

Je suppose que si tu faisais passer une autre fenêtre par dessus ton appli, les choses que tu avais dessinées sur le Canvas avaient disparues quand la fenêtre de ton appli redevenait visible, non ?

Citation:

Envoyé par kurul1

Concernant le Sleep que tu me propose, il est bloquant c'est à dire que tant qu'il n'est pas terminé les évènements clavier ne sont pas pris en compte et ce n'est pas ce qui m'intéresse et connaissant la précision des Timer, j'ai opté pour cette solution pour avoir un temps plus précis

??? Ok, si tu fais un sleep dans le thread principal, celui-ci est bloqué le temps du sleep et c'est normal que rien ne soit pris en compte. Maintenant, c'est l'intérêt d'un thread secondaire: tu y fais un sleep, il n'a pas d'impact sur ce qui se passe dans le thread principal... Tes évènements clavier ne sont pas gênés (à moins d'une autre bourde dans le thread principal) par ton thread secondaire.
21/03/2013, 16h36
kurul1

Ok je vais essayé le Sleep dans le thread secondaire mais je n'ai pas de problème pourtant avec mon Thread c'est bien dans l'affichage que cela se passe car le déroulement des Protocole se passe correctement.

Pour l'affichage non je n'utilise pas d'autre fenêtre je n'ai pas été assez claire dans mes explications.

Je ne réalise pas les affichages dans la méthode OnPaint, j'ai mes fonctions propre dans lesquelles Je dessine mes Signaux

LancerProtocole
pour chaque élément du Protocole
LancerSequence ou LancerPause
Dans LancerSequence
Pour chaque élément de la séquence
LancerSignal ou LancerPause
et donc dans LancerSignal je réalise les affichages en dessinant sur le Canvas de la Form

En aucun cas je fait de Repaint pour raffraichir l'écran et c'est peut être là mon problème.
21/03/2013, 16h43
kurul1

Je viens de voir un truc, je ne peux pas mettre de Sleep dans mon Thread car justement mon évènement clavier dans mon Thread principal permet d'interrompre tout les Threads vu que la touche Echap fait quitter le logiciel.

Lorsque l'utilisateur presse Echap, je met le booléen justement permettant de savoir que le Thread est terminé à true et cela interrompt justement le Thread d'attente avant de quitter l'application
21/03/2013, 16h47
ShaiLeTroll

Sans toucher trop ton code, dessine sur le Canvas d'un TImage.Bitmap au lieu de celui de la TForm

La TForm n'a pas de mémoire du dessin sur son Canvas, lorsque Windows lui demande de dessiner, la fenêtre commence par un EraseBackGround puis appel le dessin des TLabel (TGraphicControl) et les messages vont propager la demande de dessin aux TPanel, TButton, les TWinControl ...

Idéalement, faudrait repenser tes fonctions
Utilise un TBitmap dans lequel tu dessines, une fois le dessin complet, tu invoques le Invalidate de la TForm
tu recopie ce Bitmap dans le OnPaint de la TForm (tu peux avoir plusieurs invalidate très rapprochés (en ms) qui ne provoqueront pas tous un OnPaint)

tu peux même déporter le dessin dans un thread (un autre que celui du protocol), et en jouant sur DEUX ou TROIS TBitmap que tu permutes, c'est ce que l'on appel de double ou triple buffering évitant les effets de clipping (scintillement)
21/03/2013, 17h54
totoche76

Citation:

Envoyé par kurul1

Je ne réalise pas les affichages dans la méthode OnPaint, j'ai mes fonctions propre dans lesquelles Je dessine mes Signaux

Il faudra de toute façon à un moment ou à un autre passer par le OnPaint....

Citation:

Je viens de voir un truc, je ne peux pas mettre de Sleep dans mon Thread car justement mon évènement clavier dans mon Thread principal permet d'interrompre tout les Threads vu que la touche Echap fait quitter le logiciel.

La boucle de ton thread est celle indiquée dans le message de 11h32, mais sans le Application->ProcessMessages(), et sans Sleep, c'est bien ça ? Quelle est l'occupation CPU de ton process ?? Idem si tu rajoutes un Sleep(1) dans ta boucle ?
22/03/2013, 09h44
kurul1

Bon alors

J'ai modifié mon programme en faisant exclusivement les affichages dans le OnPaint tout en gardant mes fonctions qui déroule mon Protocole et dans celles-ci à la place des affichages je fait des Invalidate et cela fonctionne parfaitement maintenant aussi bien dans l'IDE qu'en externe.

La boucle de ton thread est bien celle indiquée dans le message de 11h32, et j'ai enlevé Application->ProcessMessages() comme tu me l'a conseillé totoche76

Pour t'expliquer pourquoi je ne peux pas mettre un Sleep, j'ai également dans mon Thread la gestion d'un envoi de Signal via une Carte d'ES pour une synchronisation avec un autre appareil mais je l'avais volontairement enlevé dans le code que j'ai présenté pour ne pas le surcharger.

Il ne me reste plus qu'a tester sur l'ordinateur sur lequel doit tourner le Logiciel et je valide dans la foulée

Merci à vous 2 pour votre aide en tout cas
22/03/2013, 10h24
ShaiLeTroll

Citation:

Envoyé par kurul1

peux pas mettre un Sleep

Tu peux utiliser un TEvent pour gérer de la signalisation, surveille la conso CPU, un thread sans même un Sleep(0) c'est 100% d'activité sur un CORE !
22/03/2013, 10h45
yarp

Pour synchroniser mon application et les threads, j'utilise PostMessage et SendMessage (~à un Synchronize mais en plus souple).
Il suffit de passer le Handle de la fenêtre au thread et celui-ci envoie ensuite des Messages à l'application qui les traite dans la boucle normale des messages de Windows.

Ce fonctionnement est bien entendu à sens unique, du Thread vers l'application.
Dans l'autre sens j'utilise Synchronize mais de manière très limitée, et le tout donne une application très fluide.
22/03/2013, 11h14
kurul1

Effectivement j'ai vérifié l'activitée CPU et là ca bouffe

Je vais voir si je ne peux pas faire uniquement un seul Thread pour gérer les envoi au lieu d'en ouvrir un d'envoyer et ensuite de le terminer

Concernant l'envoi de signal de Synchronisation pour l'autre appareil, j'utilise une carte National Instrument.
22/03/2013, 12h06
totoche76

Citation:

Envoyé par yarp

Ce fonctionnement est bien entendu à sens unique, du Thread vers l'application.
Dans l'autre sens j'utilise Synchronize mais de manière très limitée, et le tout donne une application très fluide.

????!!!????
Synchronize ne sert que dans le sens thread secondaire -> thread principal (appli)
Rien ne t’empêche de gérer toi-même une boucle de message dans ton thread (PostThreadMessage depuis le thread principal, PeekMessage dans le secondaire - ou MsgWaitForMultipleObjects)
Ou de gérer des Events windows, avec WaitForMultipleObjects (très partique)
22/03/2013, 12h10
PocoYote

Désolé mais je n'arrive pas à comprendre ce que tu cherches à faire avec ce thread. Peut être que je passe à coté de qqchose mais voilà mon avis :

Dans tous les cas (à moins que quelqu'un me contredise ;)), le dessin sur Canvas doit être fait dans le thread principal et dans la fonction OnPaint du composant, sinon explosion ou problèmes visuels (Canvas verrouillé) garanties.

Si tu mets un Timer à 25ms et que l'affichage suit (temps d'affichage < 25ms), tu fais déjà du 40 images par seconde.

Je ne sais pas quelle vitesse d'affichage tu veux atteindre, mais je pense que le Timer est largement suffisant. Ce ThreadTimer que tu veux faire est limité par le le thread principal et le PostMessage ou Synchronize => du coup c'est les mêmes limites que le Timer... Après faut passer par DirectX / OpenGL.
22/03/2013, 13h21
kurul1

Justement non un Timer n'est pas suffisamment précis et peut fluctuer suivant la charge Système.
L'affichage doit être synchronisé très précisément avec le Signal envoyé à l'autre appareil car on teste des temps de réaction.

Voilà pourquoi j'utilise un Thread ce Thread se charge seulement du calcul du temps d'affichage et de l'envoi du Signal à l'autre appareil. L'affichage se fait bien dans le Thread Principal. Jusqu'a présent je ne le faisait pas dans le OnPaint mais dans une méthode perso qui gèrait l'affichage voilà pourquoi cela ne fonctionnait pas correctement.

Par contre maintenant j'essaye donc d'alléger la charge Système en n'ouvrant pas un Thread pour chaque Signal mais en en ayant un seul qui gère cela
22/03/2013, 14h09
totoche76

Une idée à 2 cents...

Si j'ai bien compris, c'est la partie gérée par le thread qui est critique, et l'affichage sert finalement à donner une idée de l'avancement des choses, non ?

Si c'est le cas, pourquoi ne pas gérer les envois et les attentes intégralement dans le thread, et laisser le thread principal se débrouiller comme il peut pour faire son affichage ?

Je m'explique: tu peux gérer pour chacun des éléments à envoyer un statut A Faire/Fait/Erreur. Ton thread d'envoi modifie ces statuts au fur et à mesure.
Ton thread principal a un moyen pour détecter un changement dans cette liste (un timer, un message particulier posté par le tread - cf. le message de yarp -, ...), et fait un Invalidate en cas de modif.

L'accès à la liste doit être protégé évidement (section critique, InterlockedExchange,...).

Pour l'arrêt du thread, un PostThreadMessage/PeekMessage, ou SetEvent/WaitForSingleObjet avec un timeout de 0...

Le tout sans faire appel à Synchronize, qui rendrait ton thread dépendant du thread principal.

L'idée étant de réduire au possible l'interaction et les attentes entre les 2 threads...
22/03/2013, 14h22
kurul1

Alors là tu commences à me causer Chinois j'ai du mal

Pour l'instant pour résumer, j'affiche mon Stimulus visuel à l'écran et je crée un Thread qui gère l'attente et l'envoi du Signal à l'autre Appareil et quand le temps d'affichage est dépassé (calcul dans le Thread), le Thread se termine et par le booléen le programme sait qu'il doit passer à l'élément suivant de mon protocole. ce qui fait que je crée un Thread différent à chaque affichage.

Là j'essaye de créer un seul Thread secondaire avec plusieurs mode
Mode Fin, il se termine
Mode Attente, il attend et ne fait rien
Mode Signal, il gère le temps d'affichage et l'envoi et dès que le temps d'affichage est dépassé il repasse en Mode Attente.

Ainsi un seul Thread secondaire et ainsi peut être que le Taux de charge sera moindre mais a voir
22/03/2013, 15h15
PocoYote

Ok je vois à peu près le truc.

Pour la charge du thread, tu ne pourras pas l'alléger si ton thread n'est pas en mode attente de temps en temps (sleep). Si tu es à plus de X ms du temps de fin, tu pourrais faire un sleep(X - 5). Ça diminuera fortement la charge.

Alors voilà mon Thread après modification

Dans le .h en public

Code:

1
2
3
4
5
6
7
8
9
 
// Mode
int Mode;
 
// Temps de stim
int TempsStim;
 
// Temps
int Temps;

Mode peut avoir comme valeur les constantes

Code:

1
2
3
4
5
 
// Constante pour le Mode
#define FIN 0
#define ATTENTE 1
#define SIGNAL 2

Fonction Execute et la fonction ModeSignal que je lance pour lancer une attente

Code:

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
 
// Méthode qui met le Thread en Mode SIGNAL
void __fastcall MonThread::ModeSignal(int TpsStim, int Tps)
{
	// On renseigne les valeur de TempsStim et de Temps
	TempsStim = TpsStim;
	Temps = Tps;
 
	// On passe le Thread en Mode Signal
	Mode = SIGNAL;
}
 
//---------------------------------------------------------------------------
 
// Méthode qui gère l'exécution du Thread
void __fastcall MonThread::Execute()
{
	// Tant que le Thread n'est pas en Mode Fin
	while(Mode != FIN)
	{
		// Selon le Mode
		switch(Mode)
		{
			// Si l'on est en Mode Attente
			case ATTENTE :
			{
				// On ne fait rien
				Sleep(0);
 
				break;
			}
 
			// Mode SIGNAL
			case SIGNAL :
			{
				// S'il y a une Stim
				if(TempsStim != -1)
				{
					// Si le temps de Stim est supérieur à 0
					if(TempsStim > 0)
					{
						Sleep(TempsStim);
					}
 
					// On envoi le Signal à la Caret E/S
				}
 
				// Si Le Mode n'est pas passé à Fin
				if(Mode != FIN)
				{
					// On va calculer le temps restant pour l'attente
					int TempsRestant;
 
					// S'il y a eu une Stim
					if(TempsStim != -1)
					{
						// On calcule le Temps qu'il reste avant la Fin
						TempsRestant = Temps - TempsStim;
					}
					// Sinon il n'y a pas eu de Stim
					else
					{
						// Le Temps restant correspondant au Temps
						TempsRestant = Temps;
					}
 
					// On se met en attente
					Sleep(TempsRestant);
 
					// On passe en Mode ATTENTE
					Mode = ATTENTE;
				}
			}
 
			break;
		}
	}
}

Le Thread au départ est initialisé avec le Mode ATTENTE.

Là j'ai une charge beaucoup moins importante par contre lorsque je veux interrompre (appuie sur Echap qui fait passer le Mode à FIn), le Thread ne s'arrête pas immédiatement mais à la fin de l'attente en cours. J'aurais préférer pouvoir effectuer l'interruption immédiatement

Ta gestion du temps restant aurait peu être simplifié en jouant sur un Sleep(TempsAttente)

Code:

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
// Méthode qui gère l'exécution du Thread
void __fastcall MonThread::Execute()
{
  int TempsAttente = 0;
    // Tant que le Thread n'est pas en Mode Fin
  while(Mode != FIN)
  {
    // Selon le Mode
    switch(Mode)
    {
      // Si l'on est en Mode Attente
      case ATTENTE :
      {
        // On ne fait rien
        Sleep(TempsAttente);
        TempsAttente = 0;
 
        break;
      }
 
      // Mode SIGNAL
      case SIGNAL :
      {
        // S'il y a une Stim
        if(TempsStim != -1)
        {
          // Si le temps de Stim est supérieur à 0
          if(TempsStim > 0)
          {
            Sleep(TempsStim);
          }
 
          // On envoi le Signal à la Caret E/S
        }
 
        // Si Le Mode n'est pas passé à Fin
        if(Mode != FIN)
        {
          // On va calculer le temps restant pour l'attente
          // S'il y a eu une Stim
          if(TempsStim != -1)
          {
            // On calcule le Temps qu'il reste avant la Fin
            TempsAttente = Temps - TempsStim;
          }
          // Sinon il n'y a pas eu de Stim
          else
          {
            // Le Temps restant correspondant au Temps
            TempsAttente = Temps;
          }
 
          // On passe en Mode ATTENTE
          Mode = ATTENTE;
        }
      }
 
      break;
    }
  }
}

Citation:

Envoyé par kurul1

(appuie sur Echap qui fait passer le Mode à FIn), le Thread ne s'arrête pas immédiatement mais à la fin de l'attente en cours. J'aurais préférer pouvoir effectuer l'interruption immédiatement

Remplace Sleep par un TEvent.WaitFor (objet encapsulant API CreateEvent\WaitForSingleObject)
Tu pourras ainsi faire un SetEvent pour arrêter le WaitFor pour un arrêt plus rapide !
D'ailleurs aucune gestion de TThread.Terminate() ni Terminated !
Étrangement codé tout ça !

D'ailleurs, une gestion totale par TEvent pour signaler une "Stim" serait bien plus élégant
ModeSignal faisant un SetEvent pour "réveiller" le thread

Je suppose que tu as retire beaucoup de code lié à ton dialogue, cela difficile de comprendre comment fonctionne réellement ton thread !

Code:

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
46
47
48
49
50
51
52
53
54
55
56
57
58
59
//---------------------------------------------------------------------------
/*constructor*/__fastcall MonThread::MonThread(...)
  : TThread(?), 
    ...
{
  FEvent = new TEvent(NULL, false, false, "", false); // AutoReset !
}
 
 
//---------------------------------------------------------------------------
// Méthode qui met le Thread en Mode SIGNAL
void __fastcall MonThread::ModeSignal(int TpsStim, int Tps)
{
  // On renseigne les valeur de TempsStim et de Temps
  TempsStim = TpsStim;
  Temps = Tps;
 
  // On passe le Thread en Mode Signal
  FEvent.SetEvent();
  Mode = SIGNAL;
}
 
//---------------------------------------------------------------------------
// Méthode qui met le Thread en Mode FIN
void __fastcall MonThread::ModeFin()
{
  // On passe le Thread en Mode Fin
  Terminate();
  FEvent.SetEvent();
}
 
//---------------------------------------------------------------------------
// Méthode qui gère l'exécution du Thread
void __fastcall MonThread::Execute()
{
  // Tant que le Thread n'est pas en Mode Fin
  while( ! Terminated)
  {
    TWaitResult wr = FEvent.WaitFor(INFINITE);
 
    if ( ! Terminated && (wr == wrSignaled))
    {
      // S'il y a une Stim
      if(TempsStim != -1)
      {
        // ???? Tu es obligé d'attendre, un temps précis pour répondre !
 
        // Si le temps de Stim est supérieur à 0
        if(TempsStim > 0)
          Sleep(TempsStim);
 
        // On envoi le Signal à la Carte E/S
        ... là je suppose que tu as un objet qui dialogue !
      }
 
      break;
    }
  }
}

25/03/2013, 14h19
kurul1
Je n'ai pas mis de Terminate() car quand je crée mon Thread je met ceci après la ligne du New
Code:

1 2 Thread->FreeOnTerminate = true;
Je pensais que cette ligne faisait le nettoyage dès que la méthode Execute se termine. Je me trompe ?

Pour le dialogue avec la Carte d'E/S, j'ai une classe que j'ai écrite qui gère l'envoi et la réception de données de la carte, je n'ai pas jugé nécessaire de faire apparaitre le code ici vu que ce n'était pas le sujet de ma question.
26/03/2013, 10h42
ShaiLeTroll
Citation:
Envoyé par kurul1

Je n'ai pas mis de Terminate() car quand je crée mon Thread je met ceci après la ligne du New

Code:

1 2 Thread->FreeOnTerminate = true;
Je ne vois pas le rapport, c'est justement Terminate() qui permet de contrôler la boucle du Execute(), une fois sortie de la boucle, en fonction de FreeOnTerminate cela va libérer le thread automatiquement

FreeOnTerminate t'évite l'appel d'un delete mais en aucun cas cela t'évite l'appel à Terminate() ! :aie:

Citation:

Envoyé par kurul1

Je pensais que cette ligne faisait le nettoyage dès que la méthode Execute se termine. Je me trompe ?

Non, tu as compris mais c'est juste que ta boucle Execute() ne respectent pas conventions d'implémentation du TThread qui DOIT tester Terminated !
Ne confond pas Terminate() appelé de l'extérieur qui passe à false la valeur de la propriété Terminated.

Extrait de l'aide :

Citation:

Surchargez Execute et insérez le code à exécuter quand le thread commence. Execute doit tester la valeur de la propriété Terminated afin de déterminer s'il faut sortir du thread.

Tu utilises FreeOnTerminate alors qu'à tout moment on peut appeler MonThread::ModeSignal sur l'objet thread libéré, ce n'est pas prudent, tu pourrais donc avoir un thread libéré automatiquement et un appel à ModeSignal !
Tu conserves dans ton programme une référence sur l'instance TThread, cette référence à un moment donné peut pointer sur une zone mémoire libérée
Tu peux gérer un OnDestroy pour "effacer" la référence en lui affectant NULL pour protéger l'appel à MonThread::ModeSignal mais le mieux c'est de faire un delete explicite après une séquence genre Mode Fin\Terminate\WaitFor

Peut-être que ton code ne le permet pas actuellement mais c'est encore une fois en contradiction avec les bonnes pratiques :

Extrait de l'aide :

Citation:

Quand FreeOnTerminate a la valeur true, la méthode Execute doit exécuter puis libérer le thread avant que votre application puisse exécuter la ligne de code suivante. Donc, vous ne devez appeler aucune méthode de l'objet thread quand FreeOnTerminate a la valeur true sauf si vous créez le thread dans un état suspendu

...

Dans l'éventualité où vous voudriez communiquer avec les threads ou interagir avec eux de toute autre manière, y compris leur dire quand s'achever, FreeOnTerminate ne doit jamais être utilisée.

Citation:

Envoyé par kurul1

je n'ai pas jugé nécessaire de faire apparaitre le code ici vu que ce n'était pas le sujet de ma question.

un pseudo code genre TDialogue.Send() ou TDialogue.Recv() aurait permis de mieux cerné ton problème, tu nous fourni un code tronqué qui ne fait rien, cela complique la compréhension car l'on doit deviner comment ton code fonctionne

Par exemple, on ignore comment fonctionne objet dialogue, bloquant ou asynchrone, dans une approche thread, les détails comme cela comptent !
26/03/2013, 10h59
kurul1

Merci pour les explications pour FreeOnTerminate et Terminate, je n'avais pas compris cela comme ca donc pas étonnant que dans mon ancienne version cela explose la mémoire vu que je ne les terminait pas.

J'ai un peu de mal avec les Threads et je m'aperçoit que je ne fait pas correctement. Je vais corriger tout ca

Par contre avec les TEvent j'ai pas tout saisit.

Sinon concernant mon envoi de Signal, je met juste certaines sorties d'une carte Nationnal Instrument à 1 pour avoir un Front montant qui doit faire déclencher l'enregistrement d'un autre appareil, en aucun cas c'est bloquant.