|
Accueil → WINDEV 2024 → Fenêtres qui deviennent noires, boutons qui n'apparaissent plus... |
Fenêtres qui deviennent noires, boutons qui n'apparaissent plus... |
Débuté par GM Services, 09 fév. 2015 20:05 - 5 réponses |
| |
| | | |
|
| |
Posté le 09 février 2015 - 20:05 |
Bonsoir
J’ai une application dans laquelle j’ai besoin de lancer un « robot » qui exécute un cycle de trois fenêtres jusqu’à une certaine heure… Les 3 fenêtres : - Connexion à un serveur POP pour récupérer des mails de commandes Génération des commandes dans la base HFSQL Envoi de mails de confirmation de commande via SMTP
- Connexion à un Agenda Google pour récupérer des infos de livraison des commandes Maj des commandes de la base HFSQL - Envoi de mails de confirmation de livraison via SMTP
Les trois traitements ci-dessus fonctionnent parfaitement en « live » : lancement par l’utilisateur.
Les trois fenêtres sont configurées pour pouvoir fonctionner en « batch » : fenêtre invisible, boutons minuterie activés, etc… Quand je lance le robot qui enchaine les 3 fenêtres en boucle, tout fonctionne bien pendant une quarantaine de cycles (le nombre parait assez aléatoire), mais au bout de ce délai, les fenêtres commencent à apparaitre de plus en plus sombres, les boutons des fenêtres disparaissent les uns après les autres, les fenêtres deviennent complètement noires, jusqu’à ce que mon application se fige…
Quelqu’un aurait-il une idée ?
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posté le 10 février 2015 - 10:28 |
Bonjour
sans voir le code du robot, c'est difficile à dire, mais ce genre de problème vient souvent du fait que certaines ressources ne sont pas refermées correctement...
Cordialement
-- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International
NOUVEAU: WXReplication, votre système de réplication open source est disponible sur mon site web !!! WXShowroom.com : Montrez vos projets ! Plus d'information sur http://fabriceharari.com
On 2/9/2015 2:05 PM, GM Services wrote:
Bonsoir
J’ai une application dans laquelle j’ai besoin de lancer un « robot » qui exécute un cycle de trois fenêtres jusqu’à une certaine heure… Les 3 fenêtres : - Connexion à un serveur POP pour récupérer des mails de commandes Génération des commandes dans la base HFSQL Envoi de mails de confirmation de commande via SMTP
- Connexion à un Agenda Google pour récupérer des infos de livraison des commandes Maj des commandes de la base HFSQL
- Envoi de mails de confirmation de livraison via SMTP
Les trois traitements ci-dessus fonctionnent parfaitement en « live » : lancement par l’utilisateur.
Les trois fenêtres sont configurées pour pouvoir fonctionner en « batch » : fenêtre invisible, boutons minuterie activés, etc… Quand je lance le robot qui enchaine les 3 fenêtres en boucle, tout fonctionne bien pendant une quarantaine de cycles (le nombre parait assez aléatoire), mais au bout de ce délai, les fenêtres commencent à apparaitre de plus en plus sombres, les boutons des fenêtres disparaissent les uns après les autres, les fenêtres deviennent complètement noires, jusqu’à ce que mon application se fige…
Quelqu’un aurait-il une idée ?
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posté le 10 février 2015 - 18:48 |
Bonsoir Fabrice,
Ci-dessous le code du Robot ... Je ne peux pas mettre le code des 3 fenêtres ! Cependant, j'ai été très attentif à bien clôturer proprement les différentes fenêtre (mais j'ai bien sûr pu oublier quelque chose...)
J'ai aussi rajouté une procédure trouvée sur ce forum qui est censée libérer la mémoire utilisée par l'exécutable, avec l'API EmptyWorkingSet. De fait mon exécutable conserve la même taille dans le gestionnaire des tâches de Windows, au fur et à mesure de l''incrémentation des cycles. // Le champ TB_SDParam[85] contient l'heure d'arrêt du robot : 220000 pour 22h.
Clic sur BTN_Start : SI HeureSys() > Tb_SDParam[85] ALORS Erreur("L'heure prévue d'arrêt de ce programme est déjà dépassée...", "Il est impossible de poursuivre !"); Ferme(MaFenêtre)
LOCAL nHDL est entier RetourFonction est un entier wCpt est un entier = 0 wBcl est un entier = 0 DHDémarrer est un DateHeure = DateHeureSys() HeureLim est une Heure = Tb_SDParam[85] BTN_Start ..Etat = Grisé bBatch = Vrai Info("Le robot est lancé...")
MaFenêtre..Visible = Faux Iconise(MaFenêtre)
BOUCLE wCpt ++ wBcl ++ SI INT_ROBOT[1] = Vrai ALORS Ouvre(FEN_SD_Mails_Réservations, bBatch, 0, INT_MAIL_RESAS) SI INT_ROBOT[2] = Vrai ALORS Ouvre(FEN_SD_Confirm_Google, bBatch, 0, INT_MAIL_CONFIR) SI INT_ROBOT[3] = Vrai ALORS Ouvre(FEN_SD_Suivi_Rappels, bBatch, 0, INT_MAIL_RAPPEL) // Procédure libération mémoire SI SysVersionWindows(sysVersionPlateForme)="NT" ALORS nHDL = API("Kernel32", "GetCurrentProcess") RetourFonction = API("psapi", "EmptyWorkingSet", nHDL) SI RetourFonction = 0 ALORS ErreurAvecDélai(200, ErreurInfo()); RETOUR FIN // On affiche la fenêtre d'interruption tous les 10 cycles... SI wBcl = 10 ALORS SI PAS Ouvre(FEN_SD_Robot_Poursuivre, DHDémarrer, wCpt) ALORS HeureLim = "000000"; RETOUR wBcl = 0 FIN A FAIRE TANTQUE HeureSys() < HeureLim
Ferme(MaFenêtre)
Merci de vos remarques.
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posté le 10 février 2015 - 20:19 |
Rebonjour
perso, comme source de problème, je vois une boucle sans multitache(-1) pour redonner la main au système, histoire qu'il puisse faire sa salade interne (gestion de pile, en particulier)
Maintenant, il est possible que les multitaches soient dans le code batch des fenêtres, mais bon... Si les traitements dans les fenêtres sont complexes et qu'ils n'incluent pas de multitache, il est possible que -1 ne soit pas suffisant...
Une chose que beaucoup de gens oublient est que windows fait du multitache COOPERATIF... C'est donc à chaque code de rendre la main au système
Cordialement
-- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International
NOUVEAU: WXReplication, votre système de réplication open source est disponible sur mon site web !!! WXShowroom.com : Montrez vos projets ! Plus d'information sur http://fabriceharari.com
On 2/10/2015 12:48 PM, GM Services wrote:
Bonsoir Fabrice, Ci-dessous le code du Robot ... Je ne peux pas mettre le code des 3 fenêtres ! Cependant, j'ai été très attentif à bien clôturer proprement les différentes fenêtre (mais j'ai bien sûr pu oublier quelque chose...)
J'ai aussi rajouté une procédure trouvée sur ce forum qui est censée libérer la mémoire utilisée par l'exécutable, avec l'API EmptyWorkingSet. De fait mon exécutable conserve la même taille dans le gestionnaire des tâches de Windows, au fur et à mesure de l''incrémentation des cycles.
// Le champ TB_SDParam[85] contient l'heure d'arrêt du robot : 220000 pour 22h.
Clic sur BTN_Start : SI HeureSys() > Tb_SDParam[85] ALORS Erreur("L'heure prévue d'arrêt de ce programme est déjà dépassée...", "Il est impossible de poursuivre !"); Ferme(MaFenêtre)
LOCAL nHDL est entier RetourFonction est un entier
wCpt est un entier = 0 wBcl est un entier = 0
DHDémarrer est un DateHeure = DateHeureSys() HeureLim est une Heure = Tb_SDParam[85]
BTN_Start ..Etat = Grisé bBatch = Vrai Info("Le robot est lancé...")
MaFenêtre..Visible = Faux Iconise(MaFenêtre)
BOUCLE wCpt ++ wBcl ++ SI INT_ROBOT[1] = Vrai ALORS Ouvre(FEN_SD_Mails_Réservations, bBatch, 0, INT_MAIL_RESAS) SI INT_ROBOT[2] = Vrai ALORS Ouvre(FEN_SD_Confirm_Google, bBatch, 0, INT_MAIL_CONFIR) SI INT_ROBOT[3] = Vrai ALORS Ouvre(FEN_SD_Suivi_Rappels, bBatch, 0, INT_MAIL_RAPPEL)
// Procédure libération mémoire SI SysVersionWindows(sysVersionPlateForme)="NT" ALORS nHDL = API("Kernel32", "GetCurrentProcess") RetourFonction = API("psapi", "EmptyWorkingSet", nHDL) SI RetourFonction = 0 ALORS ErreurAvecDélai(200, ErreurInfo()); RETOUR FIN
// On affiche la fenêtre d'interruption tous les 10 cycles... SI wBcl = 10 ALORS SI PAS Ouvre(FEN_SD_Robot_Poursuivre, DHDémarrer, wCpt) ALORS HeureLim = "000000"; RETOUR wBcl = 0 FIN
A FAIRE TANTQUE HeureSys() < HeureLim
Ferme(MaFenêtre)
Merci de vos remarques.
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posté le 11 février 2015 - 07:41 |
Bonjour " Une chose que beaucoup de gens oublient est que windows fait du multitache COOPERATIF... C'est donc à chaque code de rendre la main au système" Ca c'était du temps de Windows 98, depuis XP et la "fusion" des noyaux avec celui de la branche NT c'est du multitâche préemptif: une application qui ne répond pas ne bloque plus le système, et ce dernier peut à tout moment mettre fin à un process. Sans la fonction multitâche() l'application ne rend pas la main au moteur d'affichage, mais le noyau de Windows reprend lui la main pour les autres applications.
Frédéric.
"Fabrice Harari" a écrit dans le message de groupe de discussion : 2015f95bac596763812ac2a89565ddebf59a@news.pcsoft.fr...
Rebonjour
perso, comme source de problème, je vois une boucle sans multitache(-1) pour redonner la main au système, histoire qu'il puisse faire sa salade interne (gestion de pile, en particulier)
Maintenant, il est possible que les multitaches soient dans le code batch des fenêtres, mais bon... Si les traitements dans les fenêtres sont complexes et qu'ils n'incluent pas de multitache, il est possible que -1 ne soit pas suffisant...
Une chose que beaucoup de gens oublient est que windows fait du multitache COOPERATIF... C'est donc à chaque code de rendre la main au système
Cordialement
-- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International
NOUVEAU: WXReplication, votre système de réplication open source est disponible sur mon site web !!! WXShowroom.com : Montrez vos projets ! Plus d'information sur http://fabriceharari.com
On 2/10/2015 12:48 PM, GM Services wrote:
Bonsoir Fabrice, Ci-dessous le code du Robot ... Je ne peux pas mettre le code des 3 fenêtres ! Cependant, j'ai été très attentif à bien clôturer proprement les différentes fenêtre (mais j'ai bien sûr pu oublier quelque chose...)
J'ai aussi rajouté une procédure trouvée sur ce forum qui est censée libérer la mémoire utilisée par l'exécutable, avec l'API EmptyWorkingSet. De fait mon exécutable conserve la même taille dans le gestionnaire des tâches de Windows, au fur et à mesure de l''incrémentation des cycles.
// Le champ TB_SDParam[85] contient l'heure d'arrêt du robot : 220000 pour 22h.
Clic sur BTN_Start : SI HeureSys() > Tb_SDParam[85] ALORS Erreur("L'heure prévue d'arrêt de ce programme est déjà dépassée...", "Il est impossible de poursuivre !"); Ferme(MaFenêtre)
LOCAL nHDL est entier RetourFonction est un entier
wCpt est un entier = 0 wBcl est un entier = 0
DHDémarrer est un DateHeure = DateHeureSys() HeureLim est une Heure = Tb_SDParam[85]
BTN_Start ..Etat = Grisé bBatch = Vrai Info("Le robot est lancé...")
MaFenêtre..Visible = Faux Iconise(MaFenêtre)
BOUCLE wCpt ++ wBcl ++ SI INT_ROBOT[1] = Vrai ALORS Ouvre(FEN_SD_Mails_Réservations, bBatch, 0, INT_MAIL_RESAS) SI INT_ROBOT[2] = Vrai ALORS Ouvre(FEN_SD_Confirm_Google, bBatch, 0, INT_MAIL_CONFIR) SI INT_ROBOT[3] = Vrai ALORS Ouvre(FEN_SD_Suivi_Rappels, bBatch, 0, INT_MAIL_RAPPEL)
// Procédure libération mémoire SI SysVersionWindows(sysVersionPlateForme)="NT" ALORS nHDL = API("Kernel32", "GetCurrentProcess") RetourFonction = API("psapi", "EmptyWorkingSet", nHDL) SI RetourFonction = 0 ALORS ErreurAvecDélai(200, ErreurInfo()); RETOUR FIN
// On affiche la fenêtre d'interruption tous les 10 cycles... SI wBcl = 10 ALORS SI PAS Ouvre(FEN_SD_Robot_Poursuivre, DHDémarrer, wCpt) ALORS HeureLim = "000000"; RETOUR wBcl = 0 FIN
A FAIRE TANTQUE HeureSys() < HeureLim
Ferme(MaFenêtre)
Merci de vos remarques.
Cordialement |
| |
| |
| | | |
|
| | |
| |
Posté le 11 février 2015 - 13:03 |
Bonjour Frédéric,
Ca c'était du temps de Windows 98, depuis XP et la "fusion" des noyaux avec celui de la branche NT c'est du multitâche préemptif: une application qui ne répond pas ne bloque plus le système, et ce dernier peut à tout moment mettre fin à un process.
Si tu le dis... moi je vois toujours des applications qui bloquent complètement le système... On va se mettre d'accord sur du multitache préemptif qui ne fonctionne pas correctement, peut être ?
je dis ca parceque j'ai connu du VRAI multitache préemptif bien avant windows, sous Prologue, et la, même avec une boucle d'enfer sans aucune interruption dans le code, les autres taches répondaient toujours sans problème (ralenties, bien sur, mais c'est tout) ce qui est loin d'être le cas sous windows ou n'importe quelle appli peut récupérer 100% d'un cpu
Sans la fonction multitâche() l'application ne rend pas la main au moteur d'affichage, mais le noyau de Windows reprend lui la main pour les autres applications.
Toujours est il que le problème courant est bien un problème d'affichage, donc mon idée semble toujours valide
Cordialement
-- Fabrice Harari Consultant WinDev, WebDev et WinDev Mobile International
NOUVEAU: WXReplication, votre système de réplication open source est disponible sur mon site web !!! WXShowroom.com : Montrez vos projets ! Plus d'information sur http://fabriceharari.com
Frédéric.
"Fabrice Harari" a écrit dans le message de groupe de discussion : 2015f95bac596763812ac2a89565ddebf59a@news.pcsoft.fr...
Rebonjour
perso, comme source de problème, je vois une boucle sans multitache(-1) pour redonner la main au système, histoire qu'il puisse faire sa salade interne (gestion de pile, en particulier)
Maintenant, il est possible que les multitaches soient dans le code batch des fenêtres, mais bon... Si les traitements dans les fenêtres sont complexes et qu'ils n'incluent pas de multitache, il est possible que -1 ne soit pas suffisant...
Une chose que beaucoup de gens oublient est que windows fait du multitache COOPERATIF... C'est donc à chaque code de rendre la main au système
Cordialement
|
| |
| |
| | | |
|
| | | | |
| | |
|