Salut,
Je suis actuellement en train de développer une application Palm qui permet d'établir une communication (infrarouge) avec une montre d'un certain type. Le fonctionnement de la communication est le suivant:

J'envoie des requêtes à la montre (ex:demande de connexion) et la montre répond par le biais d'événements qu'elle décleclenche et que je récupère dans mon application. Le problème c'est que je n'ai pas le droit d'envoyer une requête, tant que la requête précédente n'a pas été traitée et donc que l'événement soit arrivé. Et c'est là que je rencontre beaucoup de problème. Comment récupérer ces événements ? Il s'agit d'une libraire et je n'ai donc qu'un vulgaire .h et .cpp. J'ai écrit une fonction de callback et ça fonctionne à peu près, mais seulement avec les Palm de la famille m500. Avec la Clié ou un Palm Vx ça ne marche plus ! D'ou mes questions :

1) Qu'est-ce qui diffère dans la gestion des événements entre un Clié , un Vx et un m500 ? (même OS bien sûr)

2) Comment écrire une fonction qui me permette d'attendre l'arrivée d'un événement infrarouge spécifique, sachant que je n'ai qu'un seul fichier .cpp et donc pas d'event loop ?

Merci pour toutes les remarques et lse commentaires qui me seront utils.

Quand tu dis que la montre répond par des événements, il s'agit d'événements du même genre que penDown, etc. ? ou bien c'est indépendant?

Je pense que c'est différent. Cela doit être des événements d'un autre type mais je n'en suis pas sûr. En tous cas ils sont définis dans la librairie infrarouge de l'API Palm. J'ai fait une fonction de callback dont voici la structure:

void CPPCL::Callback(IrConnect * _con, IrCallBackParms * _parms)
{
switch(_parms->event)
{
case LEVENT_DISCOVERY_CNF: //Evenement lié à la connexion
...

Les événements générés par la montre appellent cette fonction et sont traités dans un grand switch qui exécute certaines actions en fonction du type d'événement qui est arrivé. Les noms qu'il y a dans les case sont simplement des define sur des numéro de 0 à 14. Ils sont définis dans la libraire IR de l'API Palm mais je ne sais pas à quoi ils correspondent.

Mais cette fonction n'est pas mon problème parce qu'elle fonctionne. Le problème c'est que avant d'envoyer une requête à la montre, je dois m'assurer qu'elle ait répondu à la requête précédente en ayant déclenché un événement (et donc m'assurer que je passe dans cette fonction de callback). Simplement je ne sais pas comment permettre à mon application d'attendre que ces événements soit arrivés ! Comment lui dire : attend jusqu'à ce que l'événement que j'attend soit arrivé !

Je faisais des EvtGetEvent mais ça ne fonctionne pas bien et même pas du tout avec le Sony Clié ou le Palm VX !

Tu as une idée de la manière dont je pourrais écrire cette fonction d'attente ??? Tu me sauverais la vie !

Il te suffit d'avoir un flag global, qui est positionné par ta fonction de callback, non?

Tu peux préciser ?

Pour l'instant quand je passe dans ma fonction de callback, je met une variable (iWaitEvent) pour signifier quel événement est apparu. Et ensuite dans la fonction qui permet d'attendre que l'événement soit arrivé, je fais comme ça:

Boolean CPPCL::waitForResult(int _eventType)
{
//_envenType est l'évenement que je demande d'attendre...

int i=0;
EventType event;

//Tant que l'évenement que je demande d'attendre n'est pas
// l'évenement qu'il est arrivé dans la fonction de callback j'attend...
//Et c'est la manière d'attendre qui est complètement fausse parce que
//si j'affiche simplement une fenêtre avec un bouton ok, le prgramme
//fonctionne parce qu'apparemment le temps que je presse sur le
//bouton, l'événement a le temps d'arriver.
//Mais de cette manière ça ne marche pas. Je pense que GetEvent
//n'attend pas le même type d'événement. T'as une idée ?

while(iWaitEvent != _eventType)
{
EvtGetEvent(&event, 100); //Simplement une manière d'attendre
}

return true:
}

C'est très mauvais de faire une boucle qui consomme tous les événements comme ça sans même les traiter !
Ton programme a une boucle principale de traitement des événements; il est déconseillé d'en créer une autre ailleurs, sauf pour de très bonnes raisons... ton test doit donc se faire à l'intérieur de cette boucle principale de traitement des événements, et non pas dans une fonction bloquante comme celle que tu proposes.

Oui c'est vrai que cette fonction n'est pas de la bonne programmation, j'en suis conscient, mais c'est en essayant de trouver des solutions et de comprendre le fonctionnent que je l'ai écrite !

Tu proposerais quoi alors ? Je dois dire que je suis assez dépité !

Ton programme doit avoir une fonction MainHandleEvent ou un truc dans le genre, c'est là-dedans qu'il faut regarder si le flag signifiant que la montre a répondu est positionné, et en fonction de ça faire ce que tu veux faire. L'important est de ne pas rester bloqué dans une fonction en attendant...

Je crois que je ne peux pas avoir de fonction de ce genre puisque j'écris une librairie. Ma librairie est complètement indépendante des programmes qui l'utiliseront. Donc je n'ai pas de fonction EventLoop ou MainHandleEvent ou des fonctions de ce genre qui s'occupe de traiter les événements. C'est pour ça que j'ai une fonction de CALLBACK. Enfin je crois...

Alors il faut prévoir dans l'API de ta bibliothèque une fonction qui retourne true si l'application peut envoyer une requête, et c'est alors à l'application de gérer cette attente...

D'accord mais comment fera l'utilisateur de l'application pour traiter ces événements ? Ca reporte le problème plus loin non ?

Je ne sais d'où ils tombent ces événements infrarouges, je n'arrive pas à les localiser.

ben c'est le problème de l'application... elle n'a qu'à le faire proprement dans la boucle principale des événements, et c'est tout

ouais...
Je me vois mal expliquer ça à mon chef de projet...
De toute façon il faut que je documente ma librairie alorsje dois comprendre le problème. Si tu as d'autres idées... Merci en tous cas pour tes réponses.