J'utilise le multi threading
J'ai besoin de faire des actions sur un dataset déclaré dans mon thread
principal alors que la manipulation se fait via un thread.
Je veux donc utiliser invoke pour faire toutes les manipulations du dataset
Ma question est la suivante:
Est ce que le fait de faire un invoke fait que la thread qui effectue
l'invoke prend la main sur le thread principale pour effectuer la
manipulation de l'invoke?
Par ex, je veux créer une datarow avec des valeurs dans mon dataset, je fait
un invoke sur le thread principal pour faire cette action. Est ce que
l'invoke, au moment de l'exécution, va ralentir (ou même prendre toute la
ressource) du thread principal ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jérémy Jeanson
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de l'instanciation... genre invocation de l'esprit défunt du thread (mais non il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là, ou on se glisse dans sa peau si tu veux.
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp
que j'utilise ce principe : la méthode invoke, fais un appel d'une
méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de
l'instanciation... genre invocation de l'esprit défunt du thread (mais
non il n'est pas mort :), c'est de la magie noire)... bon je sais que je
délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est
plus là, ou on se glisse dans sa peau si tu veux.
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de l'instanciation... genre invocation de l'esprit défunt du thread (mais non il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là, ou on se glisse dans sa peau si tu veux.
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Sylo
Salut Jeremy,
Effectivement de retour sur les threads et content de voir que tu invoke toujours notre dieu commun framework .net :) Depuis la dernière fois, j'ai un peu avancé, grâce entre autre à ton aide qui me fut précisieuse. Mais au final, j'ai utiliser une autres façon de faire plus efficace... Hélas, le problème me revient dans la figure ce jour pour un autre truc et là, pour le coup, je n'y couperais pas, cela sera du threading.
Pour être sur d'avoir bien compris ce que tu m'as dit, je vais t'expliquer le truc avec un exemple concret de ma problèmatique. Je suis sur une appli genre outllook avec une grille bindé sur une datatable. Quand je clicke sur recevoir, j'ai un traitement qui me remonte les mails du serveur. il tourne dans le thread principale et donc l'utilisateur doit attendre que cela se finisse pour pouvoir travailler. Le traitement rajoute des datarow dans le datatable bindé.
Si je fait un thread, il faut que je fasse un invoke pour créer le datarow, le remplir et le rajouter au datatable.
Je voudrais savoir si ce invoke a une incidence sur le temps d'exécution de la thread principale (par exemple, au moment de l'invoke, le thread appelle le thread principale, attend que celui-ci ne fasse rien pour prendre la main, faire son truc et redonne la main). Si cela se passe comme dans mon exemple, cela voudra dire que l'utilisateur ne pourra rien faire au moment de l'exécution du invoke (et on perd un peu l'intérêt du thread).
Est ce que c'est ca ???
J'espère avoir été clair, merci pour ton aide Sylo
"Jérémy Jeanson" a écrit dans le message de news:
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de l'instanciation... genre invocation de l'esprit défunt du thread (mais non il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là, ou on se glisse dans sa peau si tu veux.
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Salut Jeremy,
Effectivement de retour sur les threads et content de voir que tu invoke
toujours notre dieu commun framework .net :)
Depuis la dernière fois, j'ai un peu avancé, grâce entre autre à ton aide
qui me fut précisieuse. Mais au final, j'ai utiliser une autres façon de
faire plus efficace...
Hélas, le problème me revient dans la figure ce jour pour un autre truc et
là, pour le coup, je n'y couperais pas, cela sera du threading.
Pour être sur d'avoir bien compris ce que tu m'as dit, je vais t'expliquer
le truc avec un exemple concret de ma problèmatique.
Je suis sur une appli genre outllook avec une grille bindé sur une
datatable. Quand je clicke sur recevoir, j'ai un traitement qui me remonte
les mails du serveur. il tourne dans le thread principale et donc
l'utilisateur doit attendre que cela se finisse pour pouvoir travailler. Le
traitement rajoute des datarow dans le datatable bindé.
Si je fait un thread, il faut que je fasse un invoke pour créer le datarow,
le remplir et le rajouter au datatable.
Je voudrais savoir si ce invoke a une incidence sur le temps d'exécution de
la thread principale (par exemple, au moment de l'invoke, le thread appelle
le thread principale, attend que celui-ci ne fasse rien pour prendre la
main, faire son truc et redonne la main). Si cela se passe comme dans mon
exemple, cela voudra dire que l'utilisateur ne pourra rien faire au moment
de l'exécution du invoke (et on perd un peu l'intérêt du thread).
Est ce que c'est ca ???
J'espère avoir été clair, merci pour ton aide
Sylo
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de news:
OBFj1LZcJHA.4660@TK2MSFTNGP04.phx.gbl...
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp
que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode
dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de
l'instanciation... genre invocation de l'esprit défunt du thread (mais non
il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir
un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là,
ou on se glisse dans sa peau si tu veux.
Effectivement de retour sur les threads et content de voir que tu invoke toujours notre dieu commun framework .net :) Depuis la dernière fois, j'ai un peu avancé, grâce entre autre à ton aide qui me fut précisieuse. Mais au final, j'ai utiliser une autres façon de faire plus efficace... Hélas, le problème me revient dans la figure ce jour pour un autre truc et là, pour le coup, je n'y couperais pas, cela sera du threading.
Pour être sur d'avoir bien compris ce que tu m'as dit, je vais t'expliquer le truc avec un exemple concret de ma problèmatique. Je suis sur une appli genre outllook avec une grille bindé sur une datatable. Quand je clicke sur recevoir, j'ai un traitement qui me remonte les mails du serveur. il tourne dans le thread principale et donc l'utilisateur doit attendre que cela se finisse pour pouvoir travailler. Le traitement rajoute des datarow dans le datatable bindé.
Si je fait un thread, il faut que je fasse un invoke pour créer le datarow, le remplir et le rajouter au datatable.
Je voudrais savoir si ce invoke a une incidence sur le temps d'exécution de la thread principale (par exemple, au moment de l'invoke, le thread appelle le thread principale, attend que celui-ci ne fasse rien pour prendre la main, faire son truc et redonne la main). Si cela se passe comme dans mon exemple, cela voudra dire que l'utilisateur ne pourra rien faire au moment de l'exécution du invoke (et on perd un peu l'intérêt du thread).
Est ce que c'est ca ???
J'espère avoir été clair, merci pour ton aide Sylo
"Jérémy Jeanson" a écrit dans le message de news:
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de l'instanciation... genre invocation de l'esprit défunt du thread (mais non il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là, ou on se glisse dans sa peau si tu veux.
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Sylo
Pour être encore plus précis, A la limite, je lance mon thread et celui-ci se contente de faire un invoke ou tout le traitement de mon thread s'y trouve. Est ce que dans ce cas là, cela fonctionne ou est ce que cela empêchera mon utilisateur de travailler ? Sylo
"Sylo" <sylvain.malleval[at]dotsoft.fr> a écrit dans le message de news:
Salut Jeremy,
Effectivement de retour sur les threads et content de voir que tu invoke toujours notre dieu commun framework .net :) Depuis la dernière fois, j'ai un peu avancé, grâce entre autre à ton aide qui me fut précisieuse. Mais au final, j'ai utiliser une autres façon de faire plus efficace... Hélas, le problème me revient dans la figure ce jour pour un autre truc et là, pour le coup, je n'y couperais pas, cela sera du threading.
Pour être sur d'avoir bien compris ce que tu m'as dit, je vais t'expliquer le truc avec un exemple concret de ma problèmatique. Je suis sur une appli genre outllook avec une grille bindé sur une datatable. Quand je clicke sur recevoir, j'ai un traitement qui me remonte les mails du serveur. il tourne dans le thread principale et donc l'utilisateur doit attendre que cela se finisse pour pouvoir travailler. Le traitement rajoute des datarow dans le datatable bindé.
Si je fait un thread, il faut que je fasse un invoke pour créer le datarow, le remplir et le rajouter au datatable.
Je voudrais savoir si ce invoke a une incidence sur le temps d'exécution de la thread principale (par exemple, au moment de l'invoke, le thread appelle le thread principale, attend que celui-ci ne fasse rien pour prendre la main, faire son truc et redonne la main). Si cela se passe comme dans mon exemple, cela voudra dire que l'utilisateur ne pourra rien faire au moment de l'exécution du invoke (et on perd un peu l'intérêt du thread).
Est ce que c'est ca ???
J'espère avoir été clair, merci pour ton aide Sylo
"Jérémy Jeanson" a écrit dans le message de news:
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de l'instanciation... genre invocation de l'esprit défunt du thread (mais non il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là, ou on se glisse dans sa peau si tu veux.
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Pour être encore plus précis,
A la limite, je lance mon thread et celui-ci se contente de faire un invoke
ou tout le traitement de mon thread s'y trouve.
Est ce que dans ce cas là, cela fonctionne ou est ce que cela empêchera mon
utilisateur de travailler ?
Sylo
"Sylo" <sylvain.malleval[at]dotsoft.fr> a écrit dans le message de news:
OUqPFfZcJHA.1732@TK2MSFTNGP05.phx.gbl...
Salut Jeremy,
Effectivement de retour sur les threads et content de voir que tu invoke
toujours notre dieu commun framework .net :)
Depuis la dernière fois, j'ai un peu avancé, grâce entre autre à ton aide
qui me fut précisieuse. Mais au final, j'ai utiliser une autres façon de
faire plus efficace...
Hélas, le problème me revient dans la figure ce jour pour un autre truc et
là, pour le coup, je n'y couperais pas, cela sera du threading.
Pour être sur d'avoir bien compris ce que tu m'as dit, je vais t'expliquer
le truc avec un exemple concret de ma problèmatique.
Je suis sur une appli genre outllook avec une grille bindé sur une
datatable. Quand je clicke sur recevoir, j'ai un traitement qui me remonte
les mails du serveur. il tourne dans le thread principale et donc
l'utilisateur doit attendre que cela se finisse pour pouvoir travailler.
Le traitement rajoute des datarow dans le datatable bindé.
Si je fait un thread, il faut que je fasse un invoke pour créer le
datarow, le remplir et le rajouter au datatable.
Je voudrais savoir si ce invoke a une incidence sur le temps d'exécution
de la thread principale (par exemple, au moment de l'invoke, le thread
appelle le thread principale, attend que celui-ci ne fasse rien pour
prendre la main, faire son truc et redonne la main). Si cela se passe
comme dans mon exemple, cela voudra dire que l'utilisateur ne pourra rien
faire au moment de l'exécution du invoke (et on perd un peu l'intérêt du
thread).
Est ce que c'est ca ???
J'espère avoir été clair, merci pour ton aide
Sylo
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de news:
OBFj1LZcJHA.4660@TK2MSFTNGP04.phx.gbl...
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp
que j'utilise ce principe : la méthode invoke, fais un appel d'une
méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de
l'instanciation... genre invocation de l'esprit défunt du thread (mais
non il n'est pas mort :), c'est de la magie noire)... bon je sais que je
délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est
plus là, ou on se glisse dans sa peau si tu veux.
Pour être encore plus précis, A la limite, je lance mon thread et celui-ci se contente de faire un invoke ou tout le traitement de mon thread s'y trouve. Est ce que dans ce cas là, cela fonctionne ou est ce que cela empêchera mon utilisateur de travailler ? Sylo
"Sylo" <sylvain.malleval[at]dotsoft.fr> a écrit dans le message de news:
Salut Jeremy,
Effectivement de retour sur les threads et content de voir que tu invoke toujours notre dieu commun framework .net :) Depuis la dernière fois, j'ai un peu avancé, grâce entre autre à ton aide qui me fut précisieuse. Mais au final, j'ai utiliser une autres façon de faire plus efficace... Hélas, le problème me revient dans la figure ce jour pour un autre truc et là, pour le coup, je n'y couperais pas, cela sera du threading.
Pour être sur d'avoir bien compris ce que tu m'as dit, je vais t'expliquer le truc avec un exemple concret de ma problèmatique. Je suis sur une appli genre outllook avec une grille bindé sur une datatable. Quand je clicke sur recevoir, j'ai un traitement qui me remonte les mails du serveur. il tourne dans le thread principale et donc l'utilisateur doit attendre que cela se finisse pour pouvoir travailler. Le traitement rajoute des datarow dans le datatable bindé.
Si je fait un thread, il faut que je fasse un invoke pour créer le datarow, le remplir et le rajouter au datatable.
Je voudrais savoir si ce invoke a une incidence sur le temps d'exécution de la thread principale (par exemple, au moment de l'invoke, le thread appelle le thread principale, attend que celui-ci ne fasse rien pour prendre la main, faire son truc et redonne la main). Si cela se passe comme dans mon exemple, cela voudra dire que l'utilisateur ne pourra rien faire au moment de l'exécution du invoke (et on perd un peu l'intérêt du thread).
Est ce que c'est ca ???
J'espère avoir été clair, merci pour ton aide Sylo
"Jérémy Jeanson" a écrit dans le message de news:
Bonjour Sylo,
...tu es de retour sur les thread à ce que je vois ;)
Si j'ai bien compris et ce serrait idiot que je me trompe depuisle temsp que j'utilise ce principe : la méthode invoke, fais un appel d'une méthode dans le context du thread qui a servit à instancier l'objet.
En traduisant en français mot à mot on invoque le thread de l'instanciation... genre invocation de l'esprit défunt du thread (mais non il n'est pas mort :), c'est de la magie noire)... bon je sais que je délir un peu, mais l'invocation ressemble à ça, on invoque ce qui n'est plus là, ou on se glisse dans sa peau si tu veux.
-- Jérémy JEANSON MCP http://www.jjeanson.fr
Jérémy Jeanson
Cela semble effectivement être ça, enfin c'est tel que j'ai compris la documentation.
Le petit truc sympathique c'est que le job demandé va invoqué le thread dont il a besoin et quand ton utilisateur demande un traitemetn il s'exécutera dans un nouveau thread ou un thread disponible, donc l'utilisateur peut travailler :)
Mais quand on recherche des information sur le net on trouver des documents qui font planer un léger doute, non pas sur la durée d'exécution, mais sur le délais qui peut exister entre le moment où l'on demande l'exécution et le lancement réelle de celle-ci... enfin cela fait parti des règle du jeux à mon sens car en utilisant invoke on demande à ce que l'action s'exécute dans un context particulier dès que celui-ci est disponible. Donc rien de grave, surtout qu'il n'existe aucune preuve que l'on allonge le temps d'exécution de l'action ou le délais avant début de celle-ci. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Cela semble effectivement être ça, enfin c'est tel que j'ai compris la
documentation.
Le petit truc sympathique c'est que le job demandé va invoqué le thread
dont il a besoin et quand ton utilisateur demande un traitemetn il
s'exécutera dans un nouveau thread ou un thread disponible, donc
l'utilisateur peut travailler :)
Mais quand on recherche des information sur le net on trouver des
documents qui font planer un léger doute, non pas sur la durée
d'exécution, mais sur le délais qui peut exister entre le moment où l'on
demande l'exécution et le lancement réelle de celle-ci... enfin cela
fait parti des règle du jeux à mon sens car en utilisant invoke on
demande à ce que l'action s'exécute dans un context particulier dès que
celui-ci est disponible. Donc rien de grave, surtout qu'il n'existe
aucune preuve que l'on allonge le temps d'exécution de l'action ou le
délais avant début de celle-ci.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Cela semble effectivement être ça, enfin c'est tel que j'ai compris la documentation.
Le petit truc sympathique c'est que le job demandé va invoqué le thread dont il a besoin et quand ton utilisateur demande un traitemetn il s'exécutera dans un nouveau thread ou un thread disponible, donc l'utilisateur peut travailler :)
Mais quand on recherche des information sur le net on trouver des documents qui font planer un léger doute, non pas sur la durée d'exécution, mais sur le délais qui peut exister entre le moment où l'on demande l'exécution et le lancement réelle de celle-ci... enfin cela fait parti des règle du jeux à mon sens car en utilisant invoke on demande à ce que l'action s'exécute dans un context particulier dès que celui-ci est disponible. Donc rien de grave, surtout qu'il n'existe aucune preuve que l'on allonge le temps d'exécution de l'action ou le délais avant début de celle-ci. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Jérémy Jeanson
ça doit fonctionner ainsi et c'est d'ailleurs tout l'interet de l'invoke : on lance une méthode dans un nouveau thread et cette méthode demande l'invoke si besoin. -- Jérémy JEANSON MCP http://www.jjeanson.fr
ça doit fonctionner ainsi et c'est d'ailleurs tout l'interet de l'invoke
: on lance une méthode dans un nouveau thread et cette méthode demande
l'invoke si besoin.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
ça doit fonctionner ainsi et c'est d'ailleurs tout l'interet de l'invoke : on lance une méthode dans un nouveau thread et cette méthode demande l'invoke si besoin. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Sylo
Je viens de faire un test. Je lance un thread dans mon thread principal Le thread fait immédiatement un invoke sur le thread principale Dans l'invoke, il y a une boucle infini qui incremente un compteur dans un label sur la winform
Plusieurs chose: Si je me contente de la boucle, le invoke prend "la main" sur le thread principale et lache rien (même pas de mise à jour de la fenêtre pour afficher la mise à jour du label. Du coup, je ne peux plus rien faire dans mon thread principale Avec un update de la fenêtre, on voit le compteur avancé mais je n'ai toujours pas la main Avec un doevents, je reprend la main entre chaque traitement. Si je garde la main (en restant cliqué sur la barre de titre, par exemple), le invoke semble attendre.
Donc ok, c pas top mais je m'en contenterais. Il faut juste que je veille à pas garder la main trop longtemps dans le invoke
Merci pour ton aide Sylo
"Jérémy Jeanson" a écrit dans le message de news:
Cela semble effectivement être ça, enfin c'est tel que j'ai compris la documentation.
Le petit truc sympathique c'est que le job demandé va invoqué le thread dont il a besoin et quand ton utilisateur demande un traitemetn il s'exécutera dans un nouveau thread ou un thread disponible, donc l'utilisateur peut travailler :)
Mais quand on recherche des information sur le net on trouver des documents qui font planer un léger doute, non pas sur la durée d'exécution, mais sur le délais qui peut exister entre le moment où l'on demande l'exécution et le lancement réelle de celle-ci... enfin cela fait parti des règle du jeux à mon sens car en utilisant invoke on demande à ce que l'action s'exécute dans un context particulier dès que celui-ci est disponible. Donc rien de grave, surtout qu'il n'existe aucune preuve que l'on allonge le temps d'exécution de l'action ou le délais avant début de celle-ci. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Je viens de faire un test.
Je lance un thread dans mon thread principal
Le thread fait immédiatement un invoke sur le thread principale
Dans l'invoke, il y a une boucle infini qui incremente un compteur dans un
label sur la winform
Plusieurs chose:
Si je me contente de la boucle, le invoke prend "la main" sur le thread
principale et lache rien (même pas de mise à jour de la fenêtre pour
afficher la mise à jour du label. Du coup, je ne peux plus rien faire dans
mon thread principale
Avec un update de la fenêtre, on voit le compteur avancé mais je n'ai
toujours pas la main
Avec un doevents, je reprend la main entre chaque traitement. Si je garde la
main (en restant cliqué sur la barre de titre, par exemple), le invoke
semble attendre.
Donc ok, c pas top mais je m'en contenterais. Il faut juste que je veille à
pas garder la main trop longtemps dans le invoke
Merci pour ton aide
Sylo
"Jérémy Jeanson" <jeremy.jeanson@free.fr> a écrit dans le message de news:
ONedP5ZcJHA.1732@TK2MSFTNGP05.phx.gbl...
Cela semble effectivement être ça, enfin c'est tel que j'ai compris la
documentation.
Le petit truc sympathique c'est que le job demandé va invoqué le thread
dont il a besoin et quand ton utilisateur demande un traitemetn il
s'exécutera dans un nouveau thread ou un thread disponible, donc
l'utilisateur peut travailler :)
Mais quand on recherche des information sur le net on trouver des
documents qui font planer un léger doute, non pas sur la durée
d'exécution, mais sur le délais qui peut exister entre le moment où l'on
demande l'exécution et le lancement réelle de celle-ci... enfin cela fait
parti des règle du jeux à mon sens car en utilisant invoke on demande à ce
que l'action s'exécute dans un context particulier dès que celui-ci est
disponible. Donc rien de grave, surtout qu'il n'existe aucune preuve que
l'on allonge le temps d'exécution de l'action ou le délais avant début de
celle-ci.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Je viens de faire un test. Je lance un thread dans mon thread principal Le thread fait immédiatement un invoke sur le thread principale Dans l'invoke, il y a une boucle infini qui incremente un compteur dans un label sur la winform
Plusieurs chose: Si je me contente de la boucle, le invoke prend "la main" sur le thread principale et lache rien (même pas de mise à jour de la fenêtre pour afficher la mise à jour du label. Du coup, je ne peux plus rien faire dans mon thread principale Avec un update de la fenêtre, on voit le compteur avancé mais je n'ai toujours pas la main Avec un doevents, je reprend la main entre chaque traitement. Si je garde la main (en restant cliqué sur la barre de titre, par exemple), le invoke semble attendre.
Donc ok, c pas top mais je m'en contenterais. Il faut juste que je veille à pas garder la main trop longtemps dans le invoke
Merci pour ton aide Sylo
"Jérémy Jeanson" a écrit dans le message de news:
Cela semble effectivement être ça, enfin c'est tel que j'ai compris la documentation.
Le petit truc sympathique c'est que le job demandé va invoqué le thread dont il a besoin et quand ton utilisateur demande un traitemetn il s'exécutera dans un nouveau thread ou un thread disponible, donc l'utilisateur peut travailler :)
Mais quand on recherche des information sur le net on trouver des documents qui font planer un léger doute, non pas sur la durée d'exécution, mais sur le délais qui peut exister entre le moment où l'on demande l'exécution et le lancement réelle de celle-ci... enfin cela fait parti des règle du jeux à mon sens car en utilisant invoke on demande à ce que l'action s'exécute dans un context particulier dès que celui-ci est disponible. Donc rien de grave, surtout qu'il n'existe aucune preuve que l'on allonge le temps d'exécution de l'action ou le délais avant début de celle-ci. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Jérémy Jeanson
Ton blocage est normal, pour faire une mise à jour d'un affichage en multi-thread, les méthode invoke et invokerequiered sont un peu vieille école car il existe depuis .net 2.0 le backgroundWorker qui est bien plus trivial pour effectuer des mises à jours d'un formulaire et effectuer une tache de fond en mode asynchrone.
le invoke est bien pratique du moment que l'on ne cherche pas à utiliser la méthode invoke du formulaire que l'utilisateur veut manipuler, mais celle d'un autre objet ou formulaire. -- Jérémy JEANSON MCP http://www.jjeanson.fr
Ton blocage est normal, pour faire une mise à jour d'un affichage en
multi-thread, les méthode invoke et invokerequiered sont un peu vieille
école car il existe depuis .net 2.0 le backgroundWorker qui est bien
plus trivial pour effectuer des mises à jours d'un formulaire et
effectuer une tache de fond en mode asynchrone.
le invoke est bien pratique du moment que l'on ne cherche pas à utiliser
la méthode invoke du formulaire que l'utilisateur veut manipuler, mais
celle d'un autre objet ou formulaire.
--
Jérémy JEANSON
MCP
http://www.jjeanson.fr
Ton blocage est normal, pour faire une mise à jour d'un affichage en multi-thread, les méthode invoke et invokerequiered sont un peu vieille école car il existe depuis .net 2.0 le backgroundWorker qui est bien plus trivial pour effectuer des mises à jours d'un formulaire et effectuer une tache de fond en mode asynchrone.
le invoke est bien pratique du moment que l'on ne cherche pas à utiliser la méthode invoke du formulaire que l'utilisateur veut manipuler, mais celle d'un autre objet ou formulaire. -- Jérémy JEANSON MCP http://www.jjeanson.fr
