PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

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