Discussion :

[Louis Griffont]

Bonjour,

Tout est dans le titre, ou presque. Voilà, dans un logiciel, j'ai une fenêtre qui est «autonome» et j'aimerais qu'elle s'exécute dans un thread différent de celui du programme.

Est-ce possible ? Et, si oui, comment ?

Merci de m'éclairer de vos lumières,

Louis

[mail.spam]

Bonjour,

Dans l'aide il y a un exemple pour ouvrir une fenêtre à partir d'un thread
gerer-ouverture-une-fenetre-dans-thread-secondaire

Mais je pense que tu l'avais déjà vu.

Quand tu dis "autonome" tu veux dire que ta fenêtre est à considérer comme un programme à part entière ou il faut juste quelle soit dans un thread secondaire mais rattacher à ton programme principale?

[Louis Griffont]

Merci de ta réponse,

l'exemple ne me convient pas car la fenêtre est finalement gérer par le process principal.

Ce que je voudrais c'est effectivement que la fenêtre soit partie intégrante de l'appli, mais que ses traitements se fassent dans un process secondaire.

Peut-être que ce n'est pas possible avec cette version de Windev ?

[mogwai162]

Normalement il y a juste une case a cocher dans la description de la fenêtre:

onglet détail, case contexte hyperfile indépendant. et ensuite tu fais les traitements par threads...

[vmolines]

Merci de ta réponse,

l'exemple ne me convient pas car la fenêtre est finalement gérer par le process principal.

Ce que je voudrais c'est effectivement que la fenêtre soit partie intégrante de l'appli, mais que ses traitements se fassent dans un process secondaire.

Peut-être que ce n'est pas possible avec cette version de Windev ?

Seul le thread principal peut ouvrir des fenêtres.

Le seul moyen serait d'utiliser un autre executable windev et de le faire communiquer avec votre executable principal.

[Louis Griffont]

Normalement il y a juste une case a cocher dans la description de la fenêtre:

onglet détail, case contexte hyperfile indépendant. et ensuite tu fais les traitements par threads...

Je ne gère pas de fichiers Hyper File, donc, ça ne me concerne pas !

Seul le thread principal peut ouvrir des fenêtres.

Le seul moyen serait d'utiliser un autre executable windev et de le faire communiquer avec votre executable principal.

Je veux que l'exécutable principal ouvre la fenêtre, mais que les traitements de cette dernière aient lieu dans un autre thread.

[vmolines]

Dans ce cas toutes les modification d'interface de cette fenêtre doivent se faire depuis le thread principal. Pour se faire, il faudra que le thread secondaire lui communique les informations nécessaires.

Ainsi vous avez bien tous les traitements qui sont faits le thread secondaire et la le thread principal traite la mise à jour de cette fenêtre.

[Louis Griffont]

Okay, je vois ce que tu veux dire. Je gère cela par des "PostMessage" et des évènements, je suppose ?

[vmolines]

Je ne suis pas spécialiste mais les messages windows ne sont pas destinés à envoyer n'importe quelle information. Ce sont des messages bien définis non ?

Je voyais plus une communication par socket qui transporterait les informations structurées sérialisées.

[klbsjpolp]

Bonjour,

Moi je ne comprends pas ce que tu veux?! En programmation d'interface (tous les systèmes que je connaisse du moins) on doit utiliser le thread des messages pour communiquer avec l'interface. C'est une contrainte de base qui permet d'accélérer énormément le traitement en ayant pas besoin de valider les accès concurrent. Tu ne peux donc pas gérer les messages dans un autres threads sans risquer des gros problèmes. Windev utilise les api win32 qui sont gentils et qui te laisse quand même faire mais certain framework plante quand tu essais de gérer un message d'un autre thread.

Je ne comprend pas le but puisqu'aucun système ne le permet. Tu peux toujours ouvrir ta fenêtre avec un OuvreSoeur depuis ta fenêtre principale pour qu'elle semble être autonome mais pour avoir une vrai autonomie, tu dois utiliser un exécutable séparé.

[Louis Griffont]

La fenêtre en question contient des stats en «temps réel». Donc elle doit lire des données dans une base et les afficher à la demande. Comme l'initialisation est assez longue, je veux faire un ouvresoeur ou ouvrefille et que les traitements de chargements des données aient lieu dans un autre thread afin de permettre au reste du programme de fonctionner normalement et de préparer la fenêtre de stats.
Voilà.

[klbsjpolp]

Dans ce cas, tu peux exécuter ces traitements dans un thread mais l'affichage de la fenêtre devra tout de même se faire dans le thread principal.

[Louis Griffont]

Si je fais des tableajoute dans le thread secondaire ça peut marcher ?
Et le dessin de graphes ?

[vmolines]

J'ai déjà donné mon avis sur cette question plus haut :

... toutes les modification d'interface de cette fenêtre doivent se faire depuis le thread principal.

Ce n'est que mon avis donc si vous voulez vous en assurer, faites le test vous même.

[Louis Griffont]

C'était pour confirmation.

La mise en place de la solution par thread secondaire prendrait du temps, alors, je préfère être sûr avant de me lancer... Si on ne peut pas, alors tant pis !

[vmolines]

Dans ce cas, faites un test pour la solution qui me semble ne pas fonctionner. C'est très vite fait et si ça marche tant mieux. Vous pourrez vous diriger vers les threads (couteuse en temps en effet) le cas échéant.

[=JBO=]

Bonjour,

Je crois qu'il y a méconnaissance du fonctionnement de WinDev avec les Threads.

A partir d'un thread secondaire, il est possible d'agir directement sur les champs affichés dans une fenêtre.

Ce sujet avait déjà été traité dans la discussion [WD14] Gestion des threads pour gérer l'affichage de la progression d'un champ jauge.

Donc TableAJoute() à partir d'un thread secondaire est possible.

De même, le thread secondaire peut exécuter une procédure locale de la fenêtre.

Il peut aussi accéder en lecture/écriture aux variables publiques de la fenêtre.

Quant à exécuter des fonctions qui impliquent le contexte HyperFile (FichierVersEcran(), TableAffiche() sur un champ table fichier...) je pense que c'est assez délicat, car si c'est le thread secondaire qui les exécute, alors il le fait avec son propre contexte HyperFile indépendant, ce qui pourrait créer des "perturbations".

Je ne gère pas de fichiers Hyper File, donc, ça ne me concerne pas !

Mais tu es concerné si tu utilises le moteur HyperFile, c-à-d si tu utilises les fonctions H* ou SQL*.

Je ne suis pas spécialiste mais les messages windows ne sont pas destinés à envoyer n'importe quelle information. Ce sont des messages bien définis non ?

Je voyais plus une communication par socket qui transporterait les informations structurées sérialisées.

Les messages Windows sont aussi utilisables en interne par une application avec ses propres messages ou n° de message.

Sujet résolu dans la discussion Champ HTML et multi thread où le thread secondaire exécute la fonction PostMessage() vers la fenêtre ou le champ.

Avec les threads il est aussi possible de communiquer au moyen de signaux.
http://doc.pcsoft.fr/fr-FR/?3077018&...s-aide-signaux

Entre les messages Windows, les signaux, l'accès partagé aux variables, l'accès aux procédures locales de la fenêtre... tout ça dans le même processus.
Alors pourquoi mettre en place une communication par sockets !

Si je fais des tableajoute dans le thread secondaire ça peut marcher ?
Et le dessin de graphes ?

Sur le principe, rien ne s'y oppose. Mais prudence sur la façon d'alimenter le graphe avec les données à afficher.
_

[vmolines]

Merci pour l'éclaircissement, c'était nécessaire. Concernant l'envoi de message, la taille d'un message est limitée ?

Pour l'accès aux variables et aux contrôles dans des threads différents, il faut quand même faire attention aux conflits possibles.

[=JBO=]

Concernant l'envoi de message, la taille d'un message est limitée ?

Là il s'agit de messages Windows, donc un identifiant de message, et les deux entiers systèmes habituels wParam et lParam.
http://doc.pcsoft.fr/fr-FR/?3015001&...ssage-fonction

Mais on peut stocker toutes les données qu'on veut dans une ou plusieurs variables partagées (dans un tableau par exemple) et peut être passer dans wParam la position de ces données dans le tableau, par exemple.

Concernant l'envoi de message, la taille d'un message est limitée ?

Pour l'accès aux variables et aux contrôles dans des threads différents, il faut quand même faire attention aux conflits possibles.

En principe, s'il y a des accès concurrents, alors on utilise un sémaphore, ou bien on passe par une procédure unique avec section critique.

WinDev permet tout ça.
_

[Louis Griffont]

Merci ces précisions =JBO=