|
FORUMS PROFESSIONNELS
WINDEV, WEBDEV et WINDEV Mobile |
| | | | | |
| Débuté par Thierry Lemal, 13 mai 2011 17:45 - 3 réponses |
| |
| | | |
|
| |
Posté le 13 mai 2011 - 17:45 |
Bonjour,
J'utilise Windev Mobile 15.
L'équipement est un LXE-MX7 tournant sous WinCE 5.0
J'ai développé une application qui est employée pour scanner des informations.
Etant donné que l'environnement ne comporte pas de bornes WIFI partout, j'ai mis en place un mécanisme qui enregistre les données dans des tables hyperfile Mobile.
Un thread de l'application vérifie si le réseau est présent, et si oui essaie d'envoyer les données (via un Web Service).
De temps en temps, l'application et/ou l'équipement se fige.
On s'en sort parfois en exécutant une séquence Ctrl Alt Del, mais parfois on est obligé de retirer la batterie, attendre "un certain temps", remettre celle-ci en place, et relancer l'équipement.
Je soupçonnais un problème lié à la mise en veille, mais j'ai mis en place ce qu'il faut pour que l'appareil ne se mette pas en veille tant que l'application est active.
Je soupçonne maintenant un problème lié au réseau.
La vérification de la présence réseau consiste à regarder quelle est l'adresse IP.
Est-ce dû à des déconnexions/connexions successives?
Quelqu'un a-t-il déjà rencontré ce phénomène?
Merci d'avance.
Thierry |
| |
| |
| | | |
|
| | |
| |
Posté le 07 juin 2011 - 14:44 |
Je travaille avec cet appareil aussi et j'ai aussi eu ce problème. En fait le problème vient d'Hyperfile.
Pour résoudre le problème il faut a chaque fois fermé les fichiers Hyperfile après leurs utilisation.
Étrange mais c'est comme ça.
Pour ma part j'ai abandonné Hyperfile et j’utilise des fichier XML et ça fonctionne très bien avec fChargeTexte et fSauveTexte pour l'enregistrement du flux XML. |
| |
| |
| | | |
|
| | |
| |
Posté le 21 juin 2011 - 13:41 |
Un thread permanent dans l'application n'est PE pas la meilleur solution.
N'oublions pas qu'on est sur du matériel avec une puissance de frappe
limité.
Utilise plutôt un timer (automatique si tu veut) pas trop agressif qui
démarre le thread de transfert lorsqu'il y a des données a transférer et
qu'il est a portée.
Bien sur, le timer ne doit rien contrôler quand le thread est en cours.
Le timer peut être a 5/10/30 secondes (tout dépend des contraintes de
temps réel demandé)
(le temps réel est relatif, voir
http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el )
A++
Goof
Le 13/05/2011 16:45, Thierry Lemal a écrit :
Bonjour,
J'utilise Windev Mobile 15.
L'équipement est un LXE-MX7 tournant sous WinCE 5.0
J'ai développé une application qui est employée pour scanner des informations.
Etant donné que l'environnement ne comporte pas de bornes WIFI partout, j'ai mis en place un mécanisme qui enregistre les données dans des tables hyperfile Mobile.
Un thread de l'application vérifie si le réseau est présent, et si oui essaie d'envoyer les données (via un Web Service).
De temps en temps, l'application et/ou l'équipement se fige.
On s'en sort parfois en exécutant une séquence Ctrl Alt Del, mais parfois on est obligé de retirer la batterie, attendre "un certain temps", remettre celle-ci en place, et relancer l'équipement.
Je soupçonnais un problème lié à la mise en veille, mais j'ai mis en place ce qu'il faut pour que l'appareil ne se mette pas en veille tant que l'application est active.
Je soupçonne maintenant un problème lié au réseau.
La vérification de la présence réseau consiste à regarder quelle est l'adresse IP.
Est-ce dû à des déconnexions/connexions successives?
Quelqu'un a-t-il déjà rencontré ce phénomène?
Merci d'avance.
Thierry |
| |
| |
| | | |
|
| | |
| |
Posté le 15 août 2011 - 02:52 |
Bonjour.
Problème résolu.
Je me suis rendu compte que les fonctions SoapExecute (ou bien les couches Windows sous-jacentes) ne ferment pas correctement les sockets.
Résultat : au bout d'un certain temps, on se retrouve avec une multitude de sockets. Assez logiquement, les ressources de WinCE arrivent leur limites, d'où blocage.
J'ai implémenté une solution où je gère complètement les sockets
SocketConnecte("Serveur", 8000)
SI SocketChangeModeTransmission("Serveur", SocketMarqueurFin) = Vrai ALORS
Info("Mode de transmission modifié")
FIN
SI SocketEcrit("Serveur", sMessageHTML) = Vrai ALORS
Message("message envoyé")
FIN
J'ai contrôlé (par un NETSTAT -n dans une fenêtre de commande), pas un seul socket ne subsiste.
J'ai effectué des tests massifs (envoi de centaines de message, aussi rapidement que possible). J'ai essayé toutes les manipulations de connexion/déconnexion du réseau, Wifi, Cradle, ... plus aucun blocage.
J'ai maintenu l'ouverture et la fermeture des fichiers Hyperfile au moment de leur utilisation, mais je ne suis pas convaincu que le problème se situe à ce niveau.
Merci à tous pour vos suggestions.
Thierry
Goof wrote in news message <4e00664b@news.pcsoft.fr>:
Un thread permanent dans l'application n'est PE pas la meilleur solution. N'oublions pas qu'on est sur du matériel avec une puissance de frappe limité. Utilise plutôt un timer (automatique si tu veut) pas trop agressif qui démarre le thread de transfert lorsqu'il y a des données a transférer et qu'il est a portée. Bien sur, le timer ne doit rien contrôler quand le thread est en cours. Le timer peut être a 5/10/30 secondes (tout dépend des contraintes de temps réel demandé) (le temps réel est relatif, voir http://fr.wikipedia.org/wiki/Syst%C3%A8me_temps_r%C3%A9el ) A++ Goof Le 13/05/2011 16:45, Thierry Lemal a écrit : Bonjour,
J'utilise Windev Mobile 15.
L'équipement est un LXE-MX7 tournant sous WinCE 5.0
J'ai développé une application qui est employée pour scanner des informations.
Etant donné que l'environnement ne comporte pas de bornes WIFI partout, j'ai mis en place un mécanisme qui enregistre les données dans des tables hyperfile Mobile.
Un thread de l'application vérifie si le réseau est présent, et si oui essaie d'envoyer les données (via un Web Service).
De temps en temps, l'application et/ou l'équipement se fige.
On s'en sort parfois en exécutant une séquence Ctrl Alt Del, mais parfois on est obligé de retirer la batterie, attendre "un certain temps", remettre celle-ci en place, et relancer l'équipement.
Je soupçonnais un problème lié à la mise en veille, mais j'ai mis en place ce qu'il faut pour que l'appareil ne se mette pas en veille tant que l'application est active.
Je soupçonne maintenant un problème lié au réseau.
La vérification de la présence réseau consiste à regarder quelle est l'adresse IP.
Est-ce dû à des déconnexions/connexions successives?
Quelqu'un a-t-il déjà rencontré ce phénomène?
Merci d'avance.
Thierry |
| |
| |
| | | |
|
| | | | |
| | |
| | |
| |
|
|
|