|
| Iniciado por chuivaere, 18,feb. 2011 17:49 - 12 respuestas |
| |
| | | |
|
| |
| Publicado el 18,febrero 2011 - 17:49 |
Bonjour,
Quelqu'un aurait'il une solution pour arrêter un httprequete en cours sur un gros fichier ?
Pour information, j'ai déja essayé :
- les threads ( sans succès )
- lancer un autre httprequete ( sans succès )
Merci par avance de vos réponses. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,febrero 2011 - 09:54 |
| Hum hum, ca ne parle à personne ce genre de problème ? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,febrero 2011 - 23:45 |
| |
| |
| | | |
|
| | |
| |
| Publicado el 21,febrero 2011 - 07:05 |
Merci pour ta réponse.
J'ai déjà testé cette méthode mais cela n'arrête pas le 1er httprequete, en surveillant l'activité réseau on s'aperçoit que le téléchargement se fait toujours.
J'ai également procéder à un autre test en mettant la procédure de téléchargement dans une autre fenêtre. Le faîte de fermer la fenêtre n'interrompt pas non plus le httprequete.  |
| |
| |
| | | |
|
| | |
| |
| Publicado el 21,febrero 2011 - 18:12 |
bonjour,
voici un truc tout à fait bestial (grouik grouik) pour tuer un thread. C'est nettement moins propre qu'un ThreadArrête mais on n' attend pas la fin de la fonction qui est en train de s'exécuter dans le thread. Les problèmes suivants peuvent intervenir après cette opération :
1 - libérations mémoire non faite.
2 - Désallocation d'objets non faite.
3 - Dll utilisées par le thread dans un état non connu.
4 - Difficulté à fermer l'application car des éléments ne sont plus reconnus.
Alors voici la manip
1 - En global on déclare un entier système :
ThreadPID est un entier système
2 - Dans la procédure du thread avant de lancer la procédure longue qu'on veut pouvoir interrompre on fait un :
ThreadPID = ExeDonnePID(exeTID)
3 - Et pour interrompre le thread on peut alors essayer :
Résultat est un entier système
nHandleThread est un entier système
nHandleThread = API("Kernel32.dll","OpenThread",1,Faux,ThreadPID)
SI nHandleThread = 0 ALORS
API("KERNEL32.dll","GetLastError")
Info(ErreurInfo())
FIN
Résultat = API("Kernel32.dll","TerminateThread",nHandleThread,0)
SI Résultat = 0 ALORS
API("KERNEL32.dll","GetLastError")
Info(ErreurInfo())
FIN
Ami calmant, J.P  |
| |
| |
| | | |
|
| | |
| |
| Publicado el 22,febrero 2011 - 11:42 |
Merci beaucoup pour cette solution.
Par contre le problème n'est pas complètement résolu, je précise :
- Le thread au niveau de l'OS doit bien être tué puisque suite à l'appel de cette procédure je n'ai plus d'activité réseau.
- un Threadetat me renvoie que le thread en question est toujours en cours.
- un arretethread ne fonctionne pas.
La je ne suis pas sur qu'il y ai encore une solution !? |
| |
| |
| | | |
|
| | |
| |
| Publicado el 23,febrero 2011 - 08:01 |
bonjour,
et voici une autre solution en utilisant la classe Webclient de Dotnet :
1 - Dans le menu Atelier/Utiliser un assemblage .net dans ce projet choisir mscorlib et System
2 - En Déclaration globale de la fenêtre ajouter :
FileReader est un WebClient dynamique
3 - Voici le code qui lance le chargement d'un fichier par http de façon assynchrone (pas de blocage,pas la peine d'utiliser un thread) :
SiteUrl est un Uri dynamique
FileReader = allouer un WebClient()
FileReader:add_DownloadFileCompleted( DotNetDélégué(FichierChargé,"AsyncCompletedEventHandler"))
SiteUrl = allouer un Uri("http://www.pcsoft-windev-webdev.com/tdftech/2010/SupportDeCours.pdf")
QUAND EXCEPTION DANS
FileReader.DownloadFileAsync(SiteUrl,"f:\SupportDeCours.pdf")
FAIRE
Erreur(ErreurInfo())
FIN
et voici la procédure de fin de chargement :
Procedure FichierChargé()
Info("Téléchargement Terminé")
et voici le code pour interrompre le téléchargement :
FileReader.CancelAsync()
Le CancelAsync provoquera aussi l'arrivée de l'événement AsyncCompletedEvent
et voili voilo , c'est pas plus compliqué.
Ami calmant, J.P |
| |
| |
| | | |
|
| | |
| |
| Publicado el 24,febrero 2011 - 07:46 |
Merci beaucoup pour l'information 
Je teste ça de suite. |
| |
| |
| | | |
|
| | |
| |
| Publicado el 17,septiembre 2012 - 17:38 |
Merci pour ce morceau de code, cela m'a fait gagner beaucoup de temps !
Cyril |
| |
| |
| | | |
|
| | |
| |
| Publicado el 19,abril 2013 - 15:45 |
Bonjour Ami Calmant,
Jurassic Pork a écrit dans le message de news <eb48ac03b12df20de0b3366850e97048@news.pcsoft> :
bonjour, et voici une autre solution en utilisant la classe Webclient de Dotnet : 1 - Dans le menu Atelier/Utiliser un assemblage .net dans ce projet choisir mscorlib et System 2 - En Déclaration globale de la fenêtre ajouter : FileReader est un WebClient dynamique 3 - Voici le code qui lance le chargement d'un fichier par http de façon assynchrone (pas de blocage,pas la peine d'utiliser un thread) : SiteUrl est un Uri dynamique
FileReader = allouer un WebClient()
FileReader:add_DownloadFileCompleted( DotNetDélégué(FichierChargé,"AsyncCompletedEventHandler"))
SiteUrl = allouer un Uri("http://www.pcsoft-windev-webdev.com/tdftech/2010/SupportDeCours.pdf")
QUAND EXCEPTION DANS
FileReader.DownloadFileAsync(SiteUrl,"f:\SupportDeCours.pdf")
FAIRE
Erreur(ErreurInfo())
FIN et voici la procédure de fin de chargement : Procedure FichierChargé()
Info("Téléchargement Terminé") et voici le code pour interrompre le téléchargement : FileReader.CancelAsync()
Le CancelAsync provoquera aussi l'arrivée de l'événement AsyncCompletedEvent et voili voilo , c'est pas plus compliqué. Ami calmant, J.P
Pour l'instant, dans l'un de mes logiciels, j'utilise un "httprequete" pour récupérer la mise à jour dudit logiciel.
Cela marche très bien, à ceci près que:
- c'est très long
- la signature numérique du package d'installation "est perdue"
C'est pourquoi j'ai décidé d'utiliser ta solution.
C'est bon, ça marche nickel ... sauf qu'à la fin du téléchargement, la procédure "FichierChargé" n'est pas exécutée.
Donc, la fin du téléchargement n'est pas signalée à l'utilisateur.
Y aurait-il une raison ou quelque chose que j'aurai loupé (je suis sous WD18 et sur une machine qui tourne sous Seven 64 bits) ?
Merci de tes bons conseils.
A+ |
| |
| |
| | | |
|
| | |
| |
| Publicado el 20,abril 2013 - 21:58 |
Re-Bonjour,
Concernant le problème d'utilisation dont je parle plus haut (19/04/2013 à 13:45), à savoir que la procédure "FichierChargé" n'était pas exécutée à la fin du téléchargement ... c'est bon ... c'est réglé !
En fait, j'ai effectué une mise à jour du Framework .NET 4 via Windows Update et depuis tout marche nickel.
Par contre, je ne suis pas arrivé à ajouter une barre de progression de façon à ce que l'utilisateur puisse suivre l'évolution du téléchargement (surtout lorsque le fichier est gros).
Existe t'il une solution pour le faire ?
Sinon, avec WD18 46f, je note 2 grosses anomalies liés à l'incorporation d'un assemblage ".NET" et qui peuvent être importantes.
Déjà, au moment de la compilation de l'exécutable et même si l'option "Incrémentation automatique de la version à chaque génération" est décochée, la version de l'exe est automatiquement incrémentée ...
Ensuite, plus grave, mon projet contient une configuration 32 bits et une configuration 64 bits. Or, à chaque fois que je passe d'une configuration à l'autre ... des erreurs de compilation en rapport aux instructions liées à ce process .Net apparaissent dans l'onglet "Erreurs de compilation".
Donc, si on lance une génération multiple ... ça coince !
A+ |
| |
| |
| | | |
|
| | |
| |
| Publicado el 23,abril 2013 - 11:04 |
Bonjour,
Slayes a écrit dans le message de news <30ea79df9fc663a7827edf7e00a20403@news.pcsoft> :
Merci beaucoup pour cette solution.
Par contre le problème n'est pas complètement résolu, je précise :
- Le thread au niveau de l'OS doit bien être tué puisque suite à l'appel de cette procédure je n'ai plus d'activité réseau.
- un Threadetat me renvoie que le thread en question est toujours en cours.
- un arretethread ne fonctionne pas.
La je ne suis pas sur qu'il y ai encore une solution !?
J'utilise Windev 18 et je suis confronté au même problème que toi.
De ton côté, as-tu trouvé une solution viable ?
De mon côté, j'ai testé cette solution que je trouve très intéressante.
http://www.wdforge.org/modules/newbb/viewtopic.php…
En effet:
- on peut utiliser une jauge de progression (très utile si le fichier est gros)
- si on met tout cela dans une fenêtre, quand l'utilisateur annule le téléchargement, la fenêtre se ferme normalement et le programme reprend là où il en était
Le problème c'est que, si on examine les connexions réseaux, on voit que le téléchargement continu quand même en arrière plan.
Donc, la solution de lancer un 2eme HTTPRequête pour interrompre le 1er HTTPRequête ne marche pas (ou plus).
J'ai testé également la solution de "tuer le thread" présentée par notre Ami calmant J.P.
Cette solution est intéressante également car, cette fois, le téléchargement est bel et bien interrompu.
Par contre, l'arrêt du thread est relativement long (entre 20 et 30 secondes selon les machines).
Donc, quand l'utilisateur arrête le téléchargement, il doit attendre très, très longtemps avant de pouvoir reprendre la main.
J'ai vu que notre Ami calmant J.P avait proposé également une autre solution avec le "Framework .NET".
Par contre, j'ai vu qu'il n'y avait pas de jauge de progression.
Pour l'instant, je ne l'ai pas encore testée.
Merci de ton retour d'expérience.
Stefan |
| |
| |
| | | |
|
| | |
| |
Miembro registrado
50 mensajes |
|
| Publicado el 01,octubre 2020 - 11:40 |
Bonjour,
N'ayant pas trouvé de méthode "propre" et satisfaisante avec la fonction HTTPRequête, j'ai préféré m'en passer et faire le travail avec les fonctions
SocketConnecte, SocketEcrit , SocketExiste, SocketLit, ET SocketFerme
Cela permet de télécharger par paquet, et donc de mettre plus facilement le doigt dans l'engrenage.
Un bel exemple est présent ici : https://wlplus.org/fr/httpsocket/
--
La chute n'est pas un échec. L'échec c'est de rester là où on est tombé. |
| |
| |
| | | |
|
| | | | |
| | |
|