WEBCLIENT DENTRO DE THREAD
Olá pessoal.
Bom dia a todos!
Então, estou com um problema que está me encucando.
Eu tenho um projeto Windows Form, e nele eu tenho um método que é executado numa Thread separada. Dentre as várias coisas que esse método executa, uma é fazer download de um arquivo no FTP. Estou usando o WebClient pra isso.
Em 99% dos computadores, funciona que é uma beleza. Só que nesse 1% restante, o evento DownloadFileCompleted não é disparado, mesmo quando o arquivo foi baixado. O mais estranho é que o evento DownloadProgressChanged, chega nos 100% tranquilamente.
Estou usando o método DownloadFileAsync.
Vi, inclusive, este tópico: http://stackoverflow.com/questions/12249484/downloadfilecompleted-and-downloadprogresschanged-not-firing-in-a-multithread-wi
Resolver, eu já resolvi.
Usei o evento DownloadProgressChanged, e comparo os bytes recebidos e o tamanho do arquivo. AÃ eu disparo uma subrotina simulando o evento DownloadCompleted.
Também, acho que daria se eu jogasse a parte do código que faço download para a Thread principal ...
Enfim, só queria entender o motivo de não disparar mesmo, caso alguém saiba. Fiquei encucado com isso. Até onde eu saiba, o método DownloadFileAsync cria uma nova thread, de qualquer jeito, para fazer a operação assÃncrona. Então não deveria importar se chamo o método na thread principal ou em outra...
Abração a todos!
E bom trabalho aÃ.
Bom dia a todos!
Então, estou com um problema que está me encucando.
Eu tenho um projeto Windows Form, e nele eu tenho um método que é executado numa Thread separada. Dentre as várias coisas que esse método executa, uma é fazer download de um arquivo no FTP. Estou usando o WebClient pra isso.
Em 99% dos computadores, funciona que é uma beleza. Só que nesse 1% restante, o evento DownloadFileCompleted não é disparado, mesmo quando o arquivo foi baixado. O mais estranho é que o evento DownloadProgressChanged, chega nos 100% tranquilamente.
Estou usando o método DownloadFileAsync.
Vi, inclusive, este tópico: http://stackoverflow.com/questions/12249484/downloadfilecompleted-and-downloadprogresschanged-not-firing-in-a-multithread-wi
Resolver, eu já resolvi.
Usei o evento DownloadProgressChanged, e comparo os bytes recebidos e o tamanho do arquivo. AÃ eu disparo uma subrotina simulando o evento DownloadCompleted.
Também, acho que daria se eu jogasse a parte do código que faço download para a Thread principal ...
Enfim, só queria entender o motivo de não disparar mesmo, caso alguém saiba. Fiquei encucado com isso. Até onde eu saiba, o método DownloadFileAsync cria uma nova thread, de qualquer jeito, para fazer a operação assÃncrona. Então não deveria importar se chamo o método na thread principal ou em outra...
Abração a todos!
E bom trabalho aÃ.
Essa acho que talvez o Kerplunk até já saiba a resposta, aliás, ele tá meio sumido, né?
Não tem aparecido por aqui....
Não tem aparecido por aqui....
Verdade, tá meio sumido mesmo.
De certo, tem mulher na parada hahaha
De certo, tem mulher na parada hahaha
Bom, certamente ele está sendo disparado, e por estar numa thread diferente, o handler, que faz a ponte com o método-evento, pode não estar apontando para a instância do objeto que você espera. Ou seja, seu WebClient pode estar criando uma outra thread também e fazendo você esperar pelo evento no lugar errado.
Fala aà Jaba, belezinha?
Então, pelo WebClient tá executando um método assÃncrono, de certo ele cria uma outra thread. Mas o estranho, é que ele deveria buscar o handler na thread em que o método foi chamado. Pelo menos, é o que reza a lenda.
Quando você faz na thread principal, tudo ocorre sem problemas. Ele cria essa outra thread, e todos os eventos são disparados e identificados corretamente.
Como o WebClient encapsula o FtpWebRequest, eu resolvi fazer por este último.
Funcionou em todos os computadores belezinha. Fui testar nesse computador que estava problemático com o WebClient e adivinha...?! Ele deu uma travada também depois que criou o arquivo. Apenas ficou travado no método Read, que deveria me retornar 0, já que não tinha mais nada pra ler no Stream retornado pelo GetResponse.
Ao invés de usar o retorno do Read pra verificar se tinha acabado a leitura, achei melhor usar a condição => bytes recebidos = tamanho arquivo ... e pulei essa linha do Read quando isso acontecia. Aà parou de travar, mas ainda assim, tava dando erro no Dispose! Olha que bosta, dando erro no Dispose do Stream hahaha
Depois de altas pesquisas, verifiquei que em alguns computadores, você precisa pegar seu FtpWebRequest e dar um Abort nele, antes de dar o Dispose no Stream originado pelo GetResponse.
Por que?
Cara, nem imagino... Mas vou te falar, que to cansadão depois dessa... vou chegar em casa e só dormir.
Fico na expectativa por mais respostas. hahaha
Abração!
Então, pelo WebClient tá executando um método assÃncrono, de certo ele cria uma outra thread. Mas o estranho, é que ele deveria buscar o handler na thread em que o método foi chamado. Pelo menos, é o que reza a lenda.
Quando você faz na thread principal, tudo ocorre sem problemas. Ele cria essa outra thread, e todos os eventos são disparados e identificados corretamente.
Como o WebClient encapsula o FtpWebRequest, eu resolvi fazer por este último.
Funcionou em todos os computadores belezinha. Fui testar nesse computador que estava problemático com o WebClient e adivinha...?! Ele deu uma travada também depois que criou o arquivo. Apenas ficou travado no método Read, que deveria me retornar 0, já que não tinha mais nada pra ler no Stream retornado pelo GetResponse.
Ao invés de usar o retorno do Read pra verificar se tinha acabado a leitura, achei melhor usar a condição => bytes recebidos = tamanho arquivo ... e pulei essa linha do Read quando isso acontecia. Aà parou de travar, mas ainda assim, tava dando erro no Dispose! Olha que bosta, dando erro no Dispose do Stream hahaha
Depois de altas pesquisas, verifiquei que em alguns computadores, você precisa pegar seu FtpWebRequest e dar um Abort nele, antes de dar o Dispose no Stream originado pelo GetResponse.
Por que?
Cara, nem imagino... Mas vou te falar, que to cansadão depois dessa... vou chegar em casa e só dormir.
Fico na expectativa por mais respostas. hahaha
Abração!
O Framework instalado nessa máquina que ta dando problema é o mesmo das outras?
Fala Jaba, boa tarde!
Obrigatoriamente, deixei o programa dependente do framework 3.5, mesmo havendo versões posteriores instaladas na máquina. (O projeto é um instalador, e precisava manter a compatibilidade até com o XP SP3... encontrei problemas usando frameworks mais novos).
Eu peguei máquinas virtuais completamente limpas e testei o projeto em todos os sistemas operacionais. Tudo funcionou bem.
Deixei a publicação como ClickOnce, não sei se pode ter algo a ver. Já instalei em máquinas com o .NET 4.5 habilitado, assim como máquinas com o 3.5 ... Eles funcionam bem.
Só dá esse problema muito de vez em quando em máquinas especÃficas. Até agora foi um Windows 10 (com o 3.5 habilitado também) e um Windows 7.
Abraços!
Obrigatoriamente, deixei o programa dependente do framework 3.5, mesmo havendo versões posteriores instaladas na máquina. (O projeto é um instalador, e precisava manter a compatibilidade até com o XP SP3... encontrei problemas usando frameworks mais novos).
Eu peguei máquinas virtuais completamente limpas e testei o projeto em todos os sistemas operacionais. Tudo funcionou bem.
Deixei a publicação como ClickOnce, não sei se pode ter algo a ver. Já instalei em máquinas com o .NET 4.5 habilitado, assim como máquinas com o 3.5 ... Eles funcionam bem.
Só dá esse problema muito de vez em quando em máquinas especÃficas. Até agora foi um Windows 10 (com o 3.5 habilitado também) e um Windows 7.
Abraços!
Tópico encerrado , respostas não são mais permitidas