Discussion :

[agh]

Bonjour à tous,

je débute en wxWidgets, qui me semble pas mal du tout.
Je vous expose la situation :

j'ai une classe qui s'appelle Com et qui s'occupe de communiquer avec le port prallèle du PC.
Dans cette classe, je forme des "paquets" que j'envoie au port //.
Bon bref, tout ça pour dire que dans ces méthodes, j'ai besoin de faire de courtes pauses (environ 100 µs), grâce à la fonction wxMicroSleep () : en gros, un "0" dure plus longtemps qu'un "1".
Bref, toute cette petite cuisine fonctionne parfaitement.

Mais, les soucis arrivent :
je souhaite maintenant intégrer cette classe Com à une interface graphique.
Disons, la classe Fenetre.
Cette classe Fenetre est toute simple : une fenêtre et un bouton.
Quand je clique sur le bouton, j'appelle la méthode

Code :

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

Com.envoyerPaquet () ;

Ca marche, mais ça freeze l'interface durant l'envoi du paquet au port //.

Ma question : comment éviter ça ?

je sens bien qu'il faut utiliser les Threads, mais je n'arrive pas à voir comment.
Je me suis documenté du mieux que j'ai pu sur wxThread, mais je n'y pas.

Merci de votre aide, je nage !

Alexis

[wxXav]

Salut.

Pour le principe, voici ce qu'il faut faire :

• Quand tu cliques sur le bouton, ça appelle une méthode membre de la classe "fenetre"
• Dans cette méthode membre, tu vas créer une instance d'un classe dérivée de wxThread, et tu vas en lancer l'exécution
• C'est lors de l'éxécution du thread que tu vas appeler "com.envoyerPaquet()"
• Il faut penser, lorsque le paquet est envoyé, à prévenir la fenêtre que le thread est terminé (en utilisant un event personnalisé, par exemple).

Voilà pour ce qui est du principe.
Si tu as besoin de plus d'infos, n'hésites pas

@+
Xav'

[agh]

Bonjour,

Merci de votre réponse.
J'ai du mal.
j'ai essayé de mettre en place ce que vous me dites.

En fait, l'objet COM et la fenêtre vont "vivre" pendant toute l'execution du programme, puisque durant toute l'execution des paquets vont être envoyés en continu sur le port //.

Je viens de Java (et oui !) et, en Java, en créant l'objet fenêtre dans un thread "Runnable", et bien tous les traitements lourds, qui sont appelés directement depuis l'IHM n'interfèrent pas sur la fluidité de cette dernière.

Pourriez-vous me donner un petite exemple ?

Je vous remercie

[wxXav]

Je viens de penser à un truc plus simple qui peut éventuellement résoudre ton problème.
Si j'ai bien compris, tu as toi même créé la classe COM, et donc la méthode d'envoi/réception des données.
Tu peux peut-être tout simplement essayer d'insérer un petit wxTheApp->Yield() dans la boucle de traitement des données, ce qui permettra à la frame de se refraichir de temps en temps.

@+
Xav'

[agh]

Je vais essayer ça et vous tiens au courant !

Alexis

[agh]

C'est mieux, mais c'est pas encore ça.
J'explique :

Quand je clique sur le bouton, le code de l'évenement déclenché est celui là :

Code :

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

1
2
3
4
5
void Fenetre::OnClick (wxCommandEvent& evt)
{
   this->com.paquetVide () ;
   wxMessageBox (wxT("Envoi d'un paquet idle"), wxT("Info"), wxOK | wxICON_INFORMATION, this) ;
}

Donc, quand je clique, l'application ne freeze plus, le paquet part, mais, mais... le wxMessageBox n'apparaît qu'après l'envoi du paquet.
C'est qui est logique en fait.
Il faudrait que :
1) le paquet partent et vive sa vie (en vrai, il y aura en permanence des paquets qui partiront (soit ils seront vides, soit ils contiendront de l'info)
2) en même temps, au même moment, le MessageBox doit apparaître...

Je nage vraiment.
Autant je trouvais les Thread pas trop complexe en Java, autant là... j'avoue, je n'y comprends rien

[wxXav]

Effectivement, c'est tout à fait normal que la MessageBox s'affiche quand le paquet est envoyé.

Il va donc falloir passer par les threads.

Voici donc le principe de fonctionnement :
Lorsque tu démarres ton application, elle est éxécutée par un seul thread : le thread principal.
Il ne peut donc effectuer qu'une seule action à la fois.
Dans ton cas, il te faut donc un thread secondaire qui va se charger d'envoyer/recevoir les paquets.

Pour le créer, il faut :

• Créer une classer dérivée de wxThread. Cette classe devra au minimum surcharger la méthode "Entry" qui est la méthode appelée quand on demande l'exécution du thread. Et si j'ai bien compris ce que tu veux faire, cette fonction contiendra une boucle qui enverra en continu des paquets (vides ou non).
• Ensuite, il faut pouvoir indiquer au thread secondaire qu'un paquet est disponible à l'envoi. A mon avis, il faut faire l'inverse : il faut que le thread secondaire demande au thread principal s'il n'y a pas quelque chose à envoyer, et si ce n'est pas le cas, il envoie un paquet vide. Pour cette "demande", tu peux par exemple utiliser un wxArray.
• Si un paquet est disponible, le thread secondaire se l'approprie, et l'enlève du wxArray.
• Quand tu veux envoyer un paquet (clic sur ton bouton) : tu ajoutes ce paquet au wxArray, et le tour est joué.

Le seul point à ne pas oublier avec cette méthode (deux threads qui utilisent une zone mémoire "commune", c'est d'utiliser wxMutexGuiEnter et wxMutexGuiLeave depuis le thread secondaire lorsqu'il récupère les données, de façon à supprimer le risque de modifier le wxArray depuis les deux threads en même temps.

Je vais essayer de te faire un petit exemple assez simple pour que tu puisse voir le principe.

@+
Xav'