Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Gestion d'un fenêtre dans un thread différent
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
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?
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 ?
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...
Seul le thread principal peut ouvrir des fenêtres.Envoyé par Louis Griffont
Le seul moyen serait d'utiliser un autre executable windev et de le faire communiquer avec votre executable principal.
Je ne gère pas de fichiers Hyper File, donc, ça ne me concerne pas !
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.
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.
Okay, je vois ce que tu veux dire. Je gère cela par des "PostMessage" et des évènements, je suppose ?
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.
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é.
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à.
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.
Si je fais des tableajoute dans le thread secondaire ça peut marcher ?
Et le dessin de graphes ?
J'ai déjà donné mon avis sur cette question plus haut :
Ce n'est que mon avis donc si vous voulez vous en assurer, faites le test vous même.... toutes les modification d'interface de cette fenêtre doivent se faire depuis le thread principal.
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 !
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.
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".
Mais tu es concerné si tu utilises le moteur HyperFile, c-à-d si tu utilises les fonctions H* ou SQL*.
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 !
Sur le principe, rien ne s'y oppose. Mais prudence sur la façon d'alimenter le graphe avec les données à afficher.
_
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.
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.
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.
_
Merci ces précisions =JBO=
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager