Discussion :

[Djsven]

Bonsoir,

J’ouvre cette discussion car j’ai un souci avec les thread lorsque j’ouvre une fenêtre avec la fonction ouvre()


Contexte : j’ai une fenêtre d’accueil où j’ai plusieurs boutons permettant d’ouvrir d’autres fenêtres (contact, société etc.). J’ouvre toutes ces fenêtres avec ouvresoeur() uniquement car je souhaite pouvoir accéder à la fois à une fenêtre société et une fenêtre contact en même temps. Par contre dans ces fenêtres j’ouvre d’autres fenêtres de gestion du contact/société avec la fonction ouvre() car j’ai besoin des valeurs de retour pour mettre à jour ma fenêtre contact ou société. La fenêtre accueil ne peut pas être fermée tant qu’une autre fenêtre est ouverte, c’est la fenêtre mère.

Maintenant le problème, j’ai des rappels à afficher quand ils doivent être déclenchés. J’ai donc créer dans ma fenêtre accueil une fonction locale que j’ai paramétré comme étant un «*thread*» qui s’exécute à l’infini et toute les 5 minutes. Ce thread récupère les rappels à déclencher et s’il y en a, appelle une autre fonction local que j’ai paramétré comme «*thread principal*» et qui ouvre une fenêtre affichant dans une table les rappels déclenchés.

Cela fonctionne bien tant que je suis sur la fenêtre accueil ou sur une fenêtre ouverte avec ouvresoeur().
Par contre quand j’ouvre ensuite une fenêtre avec ouvre(), on dirait que le thread est mis en pause et attend que je ferme la fenêtre ouverte avec ouvre() avant de reprendre. En effet, ma fenêtre d’affichage des rappels apparaît pile quand je ferme la fenêtre et en mode debug, le code de mon thread est bien exécuté que quand je ferme la fenêtre.

Moi je souhaiterais que ma fenêtre affichant mes rappels s’ouvrent quoi qu’il arrive et non pas après la fermeture d’une fenêtre ouverte avec ouvre().


Ce que je comprend pas c’est que dans ma fenêtre accueil où j’ai lancé mon thread, toutes les fenêtres sont ouvertes avec ouvresoeur(), donc pourquoi la fonction ouvre() ensuite dans ces fenêtres sœurs ne bloque pas uniquement la fenêtre soeur appelante au lieu de tout le programme ?


J’ai aussi remarqué que si je suis sur une fenêtre soeur contact et une fenêtre soeur societe, si j’ouvre une fenêtre sur ces deux fenêtres en même temps (avec ouvre()), et que je ferme la première, la suite du code n’est pas exécuté tant que la seconde fenêtre n’est pas fermée.



Moi je souhaiterais que les fenêtres ouvertes avec ouvre() soient bloquantes uniquement pour la fenêtre appelante, et non pas pour tout le programme. Et du coup que mon thread qui tourne sur ma fenêtre d’accueil puisse bien appelé mon thread principal pour ouvrir ma fenêtre de rappel peu importe où je me trouve dans le logiciel. Je précise aussi que l’ouverture de la fenêtre des rappels se fait via ouvresoeur() comme pour l’ouverture des fenêtres contacts et sociétés.


J’espère avoir été assez clair, je découvre les threads donc peut être que j’ai mal fait quelque chose.


Si quelqu’un peut m’éclaircir et m’aider pour que mon thread puisse continuellement tourner sans interruption, que ma fenêtre de rappel puisse bien s’ouvrir automatiquement peu importe où je me trouve, et que les fenêtres ouvertes avec ouvre() bloquent uniquement la fenêtre appelante et pas les autres fenêtres sœurs, ça serait cool car je ne comprends pas et je n’ai plus de solution à tester là...


D’avance merci,

Bonne soirée

Cordialement

[Voroltinquo]

Bonjour,
Il faut que ta procédure soit globale.
Dans ton cas, le thread est propre à ta fenêtre, si elle perd le focus dans le cas de l'ouverture d'une fenêtre modale, le thread est suspendu.
OuvreSoeur ouvre une fenêtre non modale donc le problème ne se pose pas.

[Djsven]

Bonjour,
Il faut que ta procédure soit globale.
Dans ton cas, le thread est propre à ta fenêtre, si elle perd le focus dans le cas de l'ouverture d'une fenêtre modale, le thread est suspendu.
OuvreSoeur ouvre une fenêtre non modale donc le problème ne se pose pas.

Salut Voroltinquo,

J’ai également essayé avec une procédure globale parametré en thread, infini toute les 5min qui appelle une autre procédure globale paramétré en «*thread principale*» qui ouvre avec ouvresoeur la fenêtre des rappels et j’ai exactement le même problème qu’avec les fonctions locales.
Par contre je lance la première fois la procédure globale du thread à partir de ma fenêtre accueil, dois-je la lancer autrement peut être pour que cela fonctionne et que mon thread ne soit pas suspendu ?

Merci !

[Voroltinquo]

A priori, tu utilises les procédures automatiques.
As tu essayé de lancer la procédure à l'issue de l'initialisation du projet et/ou d'utiliser tout bêtement de passer le thread en timer ?

[Djsven]

A priori, tu utilises les procédures automatiques.
As tu essayé de lancer la procédure à l'issue de l'initialisation du projet et/ou d'utiliser tout bêtement un timer ?

Non je n’ai pas essayé à l’initialisation du projet car à ce moment là l’utilisateur ne s’est pas encore log, donc le premier appel ne va rien retourner puisque ma recherche de rappel se fait par rapport à l’utilisateur connecté (ID user).
Lorsque je lance le logiciel la fenêtre de login apparaît, puis une fois l’utilisateur connecté je conserve l’id de l’utilisateur qui me servira pour la procédure et j’ouvre la fenêtre accueil. Après peut être qu’il y a un moyen de suspendre le thread tant que l’utilisateur ne s’est pas encore connecté pour pas que ça tourne dans le vent ? J’essayerais quand même voir si les autres appels se font bien une fois l’utilisateur connecté

Oui sinon j’utilise les procédures automatiques car c’est la première fois que j’utilise les threads et je n’ai pas l’habitude avec les fonctions pour les threads, j’ai vu qu’il y avait les fonctions ExécuteThread, ExécuteThreadPrincipal et Timer mais pour mixer le tout pour avoir une recherche en arrière plan qui va rechercher mes rappels toutes les 5mn puis ensuite redonner la main au thread principal pour ouvrir ma fenêtre (vu que j’ai vu qu’on ne devait pas ouvrir une fenêtre avec le thread secondaire), je suis un peu perdu, c’est pour ça que j’ai directement utilisé les procédures automatiques. Après si cela peut provenir de ça, je regarderais pour le faire manuellement mais ça serait étonnant que ça change quelque chose non ?


Je regarde dès que je peux

Merci

[tbc92]

1. Ce n'est pas en relation directe avec ta question, mais si tu considères que la fenêtre d'accueil est comme une fenêtre mère, je pense que tu devrais utiliser OuvreFille(), plutôt que OuvreSoeur().
2. Je crois comprendre que tu passes par une procédure déclarée dans ta fenêtre d'accueil, et que tu utilises les 'options' accessibles via le clic-droit pour demander que cette fonction s'exécute à intervalles réguliers. Dans ce cas, c'est sain que la fonction ne s'exécute pas quand une fenêtre modale est ouverte.
Le principe d'une fenêtre modale est de figer tout ce qui se passe. La fenêtre modale la plus courante, c'est la fenêtre qui s'affiche quand on utilise la fonction OuiNon(). Avec ce type de fenêtre, on comprend bien que la fenêtre mère stoppe toute action, tant qu'on n'a pas répondu Oui ou Non.
Si on veut outrepasser cette logique, il faut que le thread ne soit pas dans la fenêtre mère, mais plus haut dans la hiérarchie, dans le projet.

C'est ma compréhension un peu intuitive. Ce n'est pas forcément exact à 100%.

[Voroltinquo]

Où est le problème si ta procédure tourne "à vide" s'il n'y a personne de connecté ? La requête ne renvoie aucun enregistrements, c'est tout. C'est la même chose qu'avec un utilisateur connecté qui n'a pas de rappels.
Travailles-tu en monoposte multiutilisateur ou en C/S ?

[Djsven]

@Tbc92
1. J’utilise ouvresoeur() plutôt que ouvrefille() car j’ai besoin d’avoir l’aperçu des fenêtres dans la barre des tâches Windows (au survol sur l’icône toutes les fenêtres en cours sont visibles). Avec ouvrefille, seule la fenêtre d’accueil apparaît et les autres sont réduits dans la fenêtre accueil, c’est moins propre.

2. Je comprend le principe mais ce que je ne comprends pas c’est que ma fenêtre d’accueil n’ouvre que des fenêtres non modales (avec ouvresoeur), aucune fenêtre modale (aucun ouvre()). Donc la fenêtre d’accueil est tout le temps accessible par l’utilisateur et ne devrait jamais être bloquée par quoi que ce soit ?
C’est à partir des fenêtres non modales ouvertes que j’ouvre des fenêtres modales, mais du coup théoriquement seule la fenêtre non modale est bloquée (grisée) quand j’ouvre une fenêtre modale à partir de celle ci.

Mais bien que ça fonctionne côté utilisateur, si j’ouvre une fenêtre modale à partir d’une fenêtre non modale ouverte par la fenêtre accueil, je peux très bien ouvrir une autre fenêtre non modale à partir de la fenêtre accueil et à partir de cette dernière ouvrir une autre fenêtre modale bloquante. Sauf que côté exécution de code y’a un problème :

Par exemple, je vais ouvrir 3 fenêtres non modales à partir de la fenêtre accueil, appelons les «*fen_A*» «*fen_B*» et «*fen_C*». Dans ces 3 fenêtres j’ouvre une fenêtre modale. Cela fonctionne. Sauf que quand je ferme la première fenêtre modale ouverte par fen_A, la suite du code de la fen_A ne s’exécute pas tant que je n’ai pas fermé les 2 autres fenêtres modales de fen_B et fen_C. Pourquoi ?? C’est pas logique.

Pour moi la fenêtre modale ouverte par fen_A devrait être bloquante uniquement pour la fen_A, et visuellement c’est le cas puisque seule la fen_A est grisée. Pourtant les fenêtres modales ouvertes par fen_B et fen_C bloquent l’exécution de la suite du code de fen_A (quand je ferme la fenêtre modale ouverte par fen_A). Pourtant j’ai bien de nouveau la main sur la fen_A. Quand je ferme les deux autres fenêtres modales de fen_B et fen_C, la suite du code de fen_A s’exécute seulement. Illogique ?


@Voroltinquo
C’est pas le soucis que la requête s’exécute dans le vent et retourne aucun résultat tant que l’utilisateur ne s’est pas connecté, le problème c’est que vu qu’elle s’exécute au lancement, le timer de 5min va se déclencher, et donc quand l’utilisateur va se connecter quelques secondes après, il va devoir attendre presque 5mn avant de recevoir ces rappels. Peut être existe t-il un moyen de forcer la reexecution du thread avant les 5mn? Dire de pouvoir lancer le thread à l’initialisation du projet et forcer la reexecution à la connexion de l’utilisateur ?
Dans tout les cas je testerais le lancement à l’init du projet afin de voir déjà si cela corrige mon problème

Je suis en C/S


Bonne soirée

[Voroltinquo]

Dans la mesure ou tu es en C/S, il faut que le traitement soit exécuté au niveau du serveur. Il n'y aura qu'une requête toute les 5 min. A toi de créer le routage (via un socket par exemple) pour envoyer régulièrement les rappels aux utilisateur.
Au niveau de l'utilisateur, il suffira, lors de l'ouverture du socket de récupérer les rappels, puis "d'écouter" le socket pour récupérer les rappels.
Il faut bien entendu 2 applications, une qui tourne sur le serveur, chargée de la récupération des rappels, et l'application que tu es en train de développer. Avant le lancement de la surveillance du socket se fait avant l'ouverture de ta fenêtre principale.