Bonjour,
J'ai developpé une classe qui se base sur L'API C# Notification Request
Broker, qui permet d'avoir du feedback sur des infos style niveau de
batterie, nouveaux réseaux disponibles ... Les API sont par nature
asynchrones et déclenchent un évènement dès qu'il y a un changeme nt,
classique quoi ;). J'ai pu tester sans problème dans une appli Windows. Form
(ça marche).
J'ai ensuite voulu tester tout cela dans un exe de type console (pour fai re
une sorte de démon/service), et là ça s'est gaté. Dans la mesure où c'est
asynchrone, j'ai mis une boucle d'attente avec un Sleep() à la fin de m on
Main(), mais rien, pas de feedback, du tout (quand bien même l'appli GU I qui
fonctionne en même temps loggue effectivement les feedbacks).
Comme mon composant fonctionne en GUI, je me suis donc dit que mon contex te
d'utilisation en "mode console" n'était pas adapté (je pense au sleep ()). Du
coup, je me demande comment faire en sorte que mon programme attende, quel
type d'attente utiliser ? Est-ce possible d'utiliser une API asynchrone d ans
ce mode console ?
Bonjour,
J'ai developpé une classe qui se base sur L'API C# Notification Request
Broker, qui permet d'avoir du feedback sur des infos style niveau de
batterie, nouveaux réseaux disponibles ... Les API sont par nature
asynchrones et déclenchent un évènement dès qu'il y a un changeme nt,
classique quoi ;). J'ai pu tester sans problème dans une appli Windows. Form
(ça marche).
J'ai ensuite voulu tester tout cela dans un exe de type console (pour fai re
une sorte de démon/service), et là ça s'est gaté. Dans la mesure où c'est
asynchrone, j'ai mis une boucle d'attente avec un Sleep() à la fin de m on
Main(), mais rien, pas de feedback, du tout (quand bien même l'appli GU I qui
fonctionne en même temps loggue effectivement les feedbacks).
Comme mon composant fonctionne en GUI, je me suis donc dit que mon contex te
d'utilisation en "mode console" n'était pas adapté (je pense au sleep ()). Du
coup, je me demande comment faire en sorte que mon programme attende, quel
type d'attente utiliser ? Est-ce possible d'utiliser une API asynchrone d ans
ce mode console ?
Bonjour,
J'ai developpé une classe qui se base sur L'API C# Notification Request
Broker, qui permet d'avoir du feedback sur des infos style niveau de
batterie, nouveaux réseaux disponibles ... Les API sont par nature
asynchrones et déclenchent un évènement dès qu'il y a un changeme nt,
classique quoi ;). J'ai pu tester sans problème dans une appli Windows. Form
(ça marche).
J'ai ensuite voulu tester tout cela dans un exe de type console (pour fai re
une sorte de démon/service), et là ça s'est gaté. Dans la mesure où c'est
asynchrone, j'ai mis une boucle d'attente avec un Sleep() à la fin de m on
Main(), mais rien, pas de feedback, du tout (quand bien même l'appli GU I qui
fonctionne en même temps loggue effectivement les feedbacks).
Comme mon composant fonctionne en GUI, je me suis donc dit que mon contex te
d'utilisation en "mode console" n'était pas adapté (je pense au sleep ()). Du
coup, je me demande comment faire en sorte que mon programme attende, quel
type d'attente utiliser ? Est-ce possible d'utiliser une API asynchrone d ans
ce mode console ?
Bonjour,
J'ai developpé une classe qui se base sur L'API C# Notification Request
Broker, qui permet d'avoir du feedback sur des infos style niveau de
batterie, nouveaux réseaux disponibles ... Les API sont par nature
asynchrones et déclenchent un évènement dès qu'il y a un changement,
classique quoi ;). J'ai pu tester sans problème dans une appli
Windows.Form
(ça marche).
J'ai ensuite voulu tester tout cela dans un exe de type console (pour
faire
une sorte de démon/service), et là ça s'est gaté. Dans la mesure où c'est
asynchrone, j'ai mis une boucle d'attente avec un Sleep() à la fin de mon
Main(), mais rien, pas de feedback, du tout (quand bien même l'appli GUI
qui
fonctionne en même temps loggue effectivement les feedbacks).
Comme mon composant fonctionne en GUI, je me suis donc dit que mon
contexte
d'utilisation en "mode console" n'était pas adapté (je pense au sleep()).
Du
coup, je me demande comment faire en sorte que mon programme attende, quel
type d'attente utiliser ? Est-ce possible d'utiliser une API asynchrone
dans
ce mode console ?
Bonjour,
J'ai developpé une classe qui se base sur L'API C# Notification Request
Broker, qui permet d'avoir du feedback sur des infos style niveau de
batterie, nouveaux réseaux disponibles ... Les API sont par nature
asynchrones et déclenchent un évènement dès qu'il y a un changement,
classique quoi ;). J'ai pu tester sans problème dans une appli
Windows.Form
(ça marche).
J'ai ensuite voulu tester tout cela dans un exe de type console (pour
faire
une sorte de démon/service), et là ça s'est gaté. Dans la mesure où c'est
asynchrone, j'ai mis une boucle d'attente avec un Sleep() à la fin de mon
Main(), mais rien, pas de feedback, du tout (quand bien même l'appli GUI
qui
fonctionne en même temps loggue effectivement les feedbacks).
Comme mon composant fonctionne en GUI, je me suis donc dit que mon
contexte
d'utilisation en "mode console" n'était pas adapté (je pense au sleep()).
Du
coup, je me demande comment faire en sorte que mon programme attende, quel
type d'attente utiliser ? Est-ce possible d'utiliser une API asynchrone
dans
ce mode console ?
Bonjour,
J'ai developpé une classe qui se base sur L'API C# Notification Request
Broker, qui permet d'avoir du feedback sur des infos style niveau de
batterie, nouveaux réseaux disponibles ... Les API sont par nature
asynchrones et déclenchent un évènement dès qu'il y a un changement,
classique quoi ;). J'ai pu tester sans problème dans une appli
Windows.Form
(ça marche).
J'ai ensuite voulu tester tout cela dans un exe de type console (pour
faire
une sorte de démon/service), et là ça s'est gaté. Dans la mesure où c'est
asynchrone, j'ai mis une boucle d'attente avec un Sleep() à la fin de mon
Main(), mais rien, pas de feedback, du tout (quand bien même l'appli GUI
qui
fonctionne en même temps loggue effectivement les feedbacks).
Comme mon composant fonctionne en GUI, je me suis donc dit que mon
contexte
d'utilisation en "mode console" n'était pas adapté (je pense au sleep()).
Du
coup, je me demande comment faire en sorte que mon programme attende, quel
type d'attente utiliser ? Est-ce possible d'utiliser une API asynchrone
dans
ce mode console ?
Bonjour M. Arnaud,
L'API sous-visée est dans Microsoft.WindowsMobile.Status, c'est un peu
spécifique WM 5.0 en fait, et si je ne m'abuse , tout est là:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce50constatstorpropertiesnotificationtypes.asp
Comme tu le verras, il suffit en fait de créer une isntance d'une
class SystemState à qui l'on donne un nom définissant la variable à
surveiller, un delegate et hop, c'est parti, dès que la variable
change, le delegate se fait invoquer... De fait (et sous réserve que
j'ai bien compris tout), je du mal à voir pourquoi il faudrait
synchroniser l'accès aux données manipulées dans mon delegate, vu
qu'un seul thread y accèdera (celui de chargé de déclencher la
notification) dans la mesure on j'ai pas de thread de GUI...
Je suis
d'accord pour l'attente clavier, ceci dit, je me demandais, l'état de
mon thread bloqué change de façon subtile suivant que je fais une
attente clavier et un while(true) {Sleep()} ??
Bonjour M. Arnaud,
L'API sous-visée est dans Microsoft.WindowsMobile.Status, c'est un peu
spécifique WM 5.0 en fait, et si je ne m'abuse , tout est là:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce50constatstorpropertiesnotificationtypes.asp
Comme tu le verras, il suffit en fait de créer une isntance d'une
class SystemState à qui l'on donne un nom définissant la variable à
surveiller, un delegate et hop, c'est parti, dès que la variable
change, le delegate se fait invoquer... De fait (et sous réserve que
j'ai bien compris tout), je du mal à voir pourquoi il faudrait
synchroniser l'accès aux données manipulées dans mon delegate, vu
qu'un seul thread y accèdera (celui de chargé de déclencher la
notification) dans la mesure on j'ai pas de thread de GUI...
Je suis
d'accord pour l'attente clavier, ceci dit, je me demandais, l'état de
mon thread bloqué change de façon subtile suivant que je fais une
attente clavier et un while(true) {Sleep()} ??
Bonjour M. Arnaud,
L'API sous-visée est dans Microsoft.WindowsMobile.Status, c'est un peu
spécifique WM 5.0 en fait, et si je ne m'abuse , tout est là:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce50constatstorpropertiesnotificationtypes.asp
Comme tu le verras, il suffit en fait de créer une isntance d'une
class SystemState à qui l'on donne un nom définissant la variable à
surveiller, un delegate et hop, c'est parti, dès que la variable
change, le delegate se fait invoquer... De fait (et sous réserve que
j'ai bien compris tout), je du mal à voir pourquoi il faudrait
synchroniser l'accès aux données manipulées dans mon delegate, vu
qu'un seul thread y accèdera (celui de chargé de déclencher la
notification) dans la mesure on j'ai pas de thread de GUI...
Je suis
d'accord pour l'attente clavier, ceci dit, je me demandais, l'état de
mon thread bloqué change de façon subtile suivant que je fais une
attente clavier et un while(true) {Sleep()} ??
Olivier Randria wrote:Bonjour M. Arnaud,
L'API sous-visée est dans Microsoft.WindowsMobile.Status, c'est un peu
spécifique WM 5.0 en fait, et si je ne m'abuse , tout est là:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce50constatstorpropertiesnotificationtypes.asp
Tu m'a indiqué la doc de l'API native. Ce qui nous intéresse, c'est plutôt
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/T_Microsoft_WindowsMobile_Status_SystemState.asp?frame=trueComme tu le verras, il suffit en fait de créer une isntance d'une
class SystemState à qui l'on donne un nom définissant la variable à
surveiller, un delegate et hop, c'est parti, dès que la variable
change, le delegate se fait invoquer... De fait (et sous réserve que
j'ai bien compris tout), je du mal à voir pourquoi il faudrait
synchroniser l'accès aux données manipulées dans mon delegate, vu
qu'un seul thread y accèdera (celui de chargé de déclencher la
notification) dans la mesure on j'ai pas de thread de GUI...
Effectivement, si tu fais tout ton traitement directement dans le handler
de notification (donc sur le thread de callback), tu n'as pas besoin de
synchroniser quoi que ce soit. Ceci-dit, il y a un certain nombre de
choses que tu n'as pas le droit de faire depuis ce thread de callback,
notamment manipuler le GUI si en as un (ce qui n'est pas le cas).Je suis
d'accord pour l'attente clavier, ceci dit, je me demandais, l'état de
mon thread bloqué change de façon subtile suivant que je fais une
attente clavier et un while(true) {Sleep()} ??
Dans le 2ème cas (attente active ou polling), tu manges de la ressource
processeur pour rien. Sur Pocket PC, c'est d'autant plus embêtant que ca
va vider sa batterie. Poses-toi aussi la question : comment tu fais pour
sortir de ton application?
Le plus probable, c'est que dans ton appli finale, le thread principal
(dans le main) sera en attente sur un mutex ou un event qui lui indiquera
qu'il doit sortir, et ce mutex ou event sera signalé dans un des callbacks
de notification de changement d'état, quand tu auras déterminé que tu
devras sortir de l'application.
Arnaud
MVP - VC
PS : Merci de ne pas top-poster, ca rend la lecture pénible...
Olivier Randria wrote:
Bonjour M. Arnaud,
L'API sous-visée est dans Microsoft.WindowsMobile.Status, c'est un peu
spécifique WM 5.0 en fait, et si je ne m'abuse , tout est là:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce50constatstorpropertiesnotificationtypes.asp
Tu m'a indiqué la doc de l'API native. Ce qui nous intéresse, c'est plutôt
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/T_Microsoft_WindowsMobile_Status_SystemState.asp?frame=true
Comme tu le verras, il suffit en fait de créer une isntance d'une
class SystemState à qui l'on donne un nom définissant la variable à
surveiller, un delegate et hop, c'est parti, dès que la variable
change, le delegate se fait invoquer... De fait (et sous réserve que
j'ai bien compris tout), je du mal à voir pourquoi il faudrait
synchroniser l'accès aux données manipulées dans mon delegate, vu
qu'un seul thread y accèdera (celui de chargé de déclencher la
notification) dans la mesure on j'ai pas de thread de GUI...
Effectivement, si tu fais tout ton traitement directement dans le handler
de notification (donc sur le thread de callback), tu n'as pas besoin de
synchroniser quoi que ce soit. Ceci-dit, il y a un certain nombre de
choses que tu n'as pas le droit de faire depuis ce thread de callback,
notamment manipuler le GUI si en as un (ce qui n'est pas le cas).
Je suis
d'accord pour l'attente clavier, ceci dit, je me demandais, l'état de
mon thread bloqué change de façon subtile suivant que je fais une
attente clavier et un while(true) {Sleep()} ??
Dans le 2ème cas (attente active ou polling), tu manges de la ressource
processeur pour rien. Sur Pocket PC, c'est d'autant plus embêtant que ca
va vider sa batterie. Poses-toi aussi la question : comment tu fais pour
sortir de ton application?
Le plus probable, c'est que dans ton appli finale, le thread principal
(dans le main) sera en attente sur un mutex ou un event qui lui indiquera
qu'il doit sortir, et ce mutex ou event sera signalé dans un des callbacks
de notification de changement d'état, quand tu auras déterminé que tu
devras sortir de l'application.
Arnaud
MVP - VC
PS : Merci de ne pas top-poster, ca rend la lecture pénible...
Olivier Randria wrote:Bonjour M. Arnaud,
L'API sous-visée est dans Microsoft.WindowsMobile.Status, c'est un peu
spécifique WM 5.0 en fait, et si je ne m'abuse , tout est là:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/wce50constatstorpropertiesnotificationtypes.asp
Tu m'a indiqué la doc de l'API native. Ce qui nous intéresse, c'est plutôt
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/mobilesdk5/html/T_Microsoft_WindowsMobile_Status_SystemState.asp?frame=trueComme tu le verras, il suffit en fait de créer une isntance d'une
class SystemState à qui l'on donne un nom définissant la variable à
surveiller, un delegate et hop, c'est parti, dès que la variable
change, le delegate se fait invoquer... De fait (et sous réserve que
j'ai bien compris tout), je du mal à voir pourquoi il faudrait
synchroniser l'accès aux données manipulées dans mon delegate, vu
qu'un seul thread y accèdera (celui de chargé de déclencher la
notification) dans la mesure on j'ai pas de thread de GUI...
Effectivement, si tu fais tout ton traitement directement dans le handler
de notification (donc sur le thread de callback), tu n'as pas besoin de
synchroniser quoi que ce soit. Ceci-dit, il y a un certain nombre de
choses que tu n'as pas le droit de faire depuis ce thread de callback,
notamment manipuler le GUI si en as un (ce qui n'est pas le cas).Je suis
d'accord pour l'attente clavier, ceci dit, je me demandais, l'état de
mon thread bloqué change de façon subtile suivant que je fais une
attente clavier et un while(true) {Sleep()} ??
Dans le 2ème cas (attente active ou polling), tu manges de la ressource
processeur pour rien. Sur Pocket PC, c'est d'autant plus embêtant que ca
va vider sa batterie. Poses-toi aussi la question : comment tu fais pour
sortir de ton application?
Le plus probable, c'est que dans ton appli finale, le thread principal
(dans le main) sera en attente sur un mutex ou un event qui lui indiquera
qu'il doit sortir, et ce mutex ou event sera signalé dans un des callbacks
de notification de changement d'état, quand tu auras déterminé que tu
devras sortir de l'application.
Arnaud
MVP - VC
PS : Merci de ne pas top-poster, ca rend la lecture pénible...
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching
aSynchroEvent.Set(); Utilities.Debug.Append("Main: Done");
}
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching
aSynchroEvent.Set(); Utilities.Debug.Append("Main: Done");
}
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching
aSynchroEvent.Set(); Utilities.Debug.Append("Main: Done");
}
Mon problème est donc que le delegate
OnSystemEventChange, n'est jamais appelé, quand bien même, je fais
une manip sur le device qui le produit un changement (activer Wifi
sur le device dans une environn. qui fourmille de réseaux Wifi pas
discrets) qui devrait causer l'appel (d'après la doc).:
static void OnSystemStateChange(object sender, ChangeEventArgs args)
{
Utilities.Debug.Append("OnSystemStateChange: new value
'"+args.NewValue+"'");
}
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching aSynchroEvent.Set();
Utilities.Debug.Append("Main: Done");
}
Mon problème est donc que le delegate
OnSystemEventChange, n'est jamais appelé, quand bien même, je fais
une manip sur le device qui le produit un changement (activer Wifi
sur le device dans une environn. qui fourmille de réseaux Wifi pas
discrets) qui devrait causer l'appel (d'après la doc).:
static void OnSystemStateChange(object sender, ChangeEventArgs args)
{
Utilities.Debug.Append("OnSystemStateChange: new value
'"+args.NewValue+"'");
}
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching aSynchroEvent.Set();
Utilities.Debug.Append("Main: Done");
}
Mon problème est donc que le delegate
OnSystemEventChange, n'est jamais appelé, quand bien même, je fais
une manip sur le device qui le produit un changement (activer Wifi
sur le device dans une environn. qui fourmille de réseaux Wifi pas
discrets) qui devrait causer l'appel (d'après la doc).:
static void OnSystemStateChange(object sender, ChangeEventArgs args)
{
Utilities.Debug.Append("OnSystemStateChange: new value
'"+args.NewValue+"'");
}
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching aSynchroEvent.Set();
Utilities.Debug.Append("Main: Done");
}
"Olivier Randria" wrote in
news:du244n$7q0$:static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching
aSynchroEvent.Set(); Utilities.Debug.Append("Main: Done");
}
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après tout)
puisse être traité ?
--
Cyrille Szymanski
"Olivier Randria" <olivier_randria@yahoo.com.NoSpamPlease> wrote in
news:du244n$7q0$1@news.rd.francetelecom.fr:
static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching
aSynchroEvent.Set(); Utilities.Debug.Append("Main: Done");
}
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après tout)
puisse être traité ?
--
Cyrille Szymanski
"Olivier Randria" wrote in
news:du244n$7q0$:static void Main(string[] args)
{
SystemState aState = new
SystemState(SystemProperty.ConnectionsNetworkDescriptions,false);
aState.Changed += new ChangeEventHandler(OnSystemStateChange);
AutoResetEvent aSynchroEvent = null;
aSynchroEvent = new AutoResetEvent(false);
Utilities.Debug.Append("Main: waiting");
aSynchroEvent.WaitOne();
//Should not go here since there is no matching
aSynchroEvent.Set(); Utilities.Debug.Append("Main: Done");
}
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après tout)
puisse être traité ?
--
Cyrille Szymanski
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après t out)
puisse être traité ?
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après t out)
puisse être traité ?
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après t out)
puisse être traité ?
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après tout)
puisse être traité ?
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après tout)
puisse être traité ?
Ne faut-il pas une vraie boucle de messages plutôt (GetMessage() +
DispatchMessage()) pour que l'événement (qui est un message après tout)
puisse être traité ?