CARREGANDO EM SEGUNDO PLANO

KERPLUNK 30/09/2016 17:00:05
#467768
Já expliquei isso. JAMAIS vai rodar sem nenhuma travadinha. Está sendo executada uma tarefa relativamente pesada e seja de modo síncrono ou assíncrono, requer processamento e memória. A diferença com método assíncrono é que a aplicação vai estar [Ô]liberada[Ô] para outras tarefas simultaneamente.
VARUS 30/09/2016 17:22:22
#467772
testei utilizando o backgroundWorker e funcionou, rodou sem nenhuma travada
NICKOSOFT 30/09/2016 18:22:17
#467775
background sempre me atendeu bem, consigo mostrar progresso, e sem travadinhas....
apenas pra uma ideia de doutorado q tenho q parti pra threads mesmo, e até assim consegue dar uma congelada com o volume de cálculos q processa.......
VARUS 30/09/2016 20:01:18
#467778
O problema de usar o Backgroud é que não consigo atualizar labels, textbox durante o DoWork
KERPLUNK 30/09/2016 20:14:54
#467780
Citação:

:
O problema de usar o Backgroud é que não consigo atualizar labels, textbox durante o DoWork


Porque é uma thread separada da thread em que a UI roda. Quando tenta atualizar a UI à partir da thread do bgWorker, você vai ter uma exception the [Ô]cross-thread[Ô]. é possível fazer todo o processo de leitura em uma thread separada e ainda assim atualizar a UI ao mesmo tempo, com métodos síncronos ou assíncronos. Mas aí a programação é outro nível, pois tem que trabalhar com ThreadPool e a coisa fica bem mais complexa. Quando for esse o caso, minha sugestão é fazer a parte de leitura de dados em uma DLL separada, lançando eventos para serem capturados na UI, fica muito mais fácil, você vai ter um ambiente multi-thread, que podem inclusive serem alteradas quanto à prioridade, paradas, pausadas e tudo mais que uma thread pode fazer. Estou pensando em implementar isso no sistema de Backwork que estou passando no Youtube... mas isso mais à frente, é realmente coisa bem complexa.
NICKOSOFT 30/09/2016 22:20:49
#467783
Citação:

:
O problema de usar o Backgroud é que não consigo atualizar labels, textbox durante o DoWork


logico q consegue atualizar a interface, tente usar o ProgressChanged do background, é possível preencher uma progressbar com o andamento da atividade, depende o q quer de retorno é possível sim....

agora se quer pensar em threads mesmo, existem livros específicos sobre o tema, comi pelo menos 3 deles na ideia q citei acima....de forma tradicional levava mais de 1h de processamento, com thread e atividades paralelas levou pouco mais de 10min, como no caso a questão é tempo mesmo, nem me interessei em interface, o esforço ficou todo no processamento.....
VARUS 01/10/2016 11:54:29
#467786
O que é uma Thread e de modo especifico, como funciona uma?
KERPLUNK 01/10/2016 18:52:00
#467790
Citação:

:
O que é uma Thread e de modo especifico, como funciona uma?


Nossa... Temos algo em torno de 10 mil caracteres disponíveis aqui para responder, isso não é suficiente nem para fazer uma introdução breve do que é e como funciona uma thread. Existem dezenas de livros bem extensos que abordam de forma um pouco mais profunda esse assunto que é vastíssimo.

Threads são processos que rodam em paralelo e de forma independente. Elas devem rodar de forma independente, mas é totalmente possível passar informações de uma para outra. O seu browser(o navegador), está provavelmente ocupando uma thread(ou até várias). O Visual Studio também, cada programa, cada DLL cada mínimo pedacinho de código, roda em alguma thread. Elas rodam de forma assíncrona. Imagine uma conversa entre duas pessoas, uma faz a pergunta e a outra dá a resposta e a conversa flui. Isso é um processo síncrono, onde uma ação depende da outra para ter continuidade. Em se falando de threads, esse paradigma não é válido, nem se pode comparar com uma conversação, pois são fluxos completamente diferentes, onde uma conversação, uma fala depende da outra(pergunta e resposta/comentário), mas assincronamente isso deixa de ser necessário. Para comparar, você consegue mascar chiclete enquanto sobe uma escada e digita um número de telefone no celular, certo? Pois é, isso é multi-threading ou ações de forma assíncrona. Os passos degraus acima não dependem de sua mandíbula estar aberta ou fechada, nem de seus dedos se moverem pelo teclado do telefone. A maior dificuldade é quando processos assíncronos precisam fazer algum tipo de interação com algum processo síncrono. Aí é que o bicho pega. Imagine que para poder digitar um número no telefone, seja necessário que seu pé direito esteja acima do esquerdo, a sua mandíbula mascando o chiclete esteja fechada e você não esteja engolindo a saliva aromatizada do chiclete. Então se qualquer uma das condições estejam desfavoráveis, você não pode digitar o número no celular, você precisa posicionar o pé direito acima do esquerdo, fechar a mandíbula e não engolir saliva, aí sim você pode digitar um número. Mas se por acaso você abrir a mandíbula nesse meio tempo, novamente, você precisa fechar para digitar outro número. Entende a dificuldade? Imagine agora que você quer ler dados de produto em um banco de dados, enquanto grava dados de outra tela e faz um processo de baixa de estoque e exiba um relógio na tela, tudo ao mesmo tempo, A baixa de produtos, depende do horário, que não pode parar de rodar, enquanto lê os produtos, o processo de baixa pode estar afetando um dos produtos sendo lidos ou um já lido e ainda o processo de gravação rodando pode até mesmo ter excluído um dos produtos que pode ou não estar lido ou adicionado um que pode ou não estar incluido na query. Isso acontecendo em uma máquina só, imagine quando isso acontece em 5 ou 100 máquinas ao mesmo tempo...

Acho que já se pode ter uma idéia à partir disso.
VARUS 03/10/2016 16:44:34
#467830
Agora entendi bem +- a ideia de Threads

Também vi um linha nos tutorias do Macoratti sobre Thread Pool ;

http://www.macoratti.net/09/06/vb_patp.htm

onde ele faz uma chamada usando o thread pool. tentei fazendo dessa forma;


     Private Sub Button2_Click(sender As Object, e As EventArgs) Handles Button2.Click 
               ThreadPool.QueueUserWorkItem(AddressOf DD.TodosNoFunction)
    End Sub 



  Public Event alllist(a As List(Of Clientes))
    Public Sub TodosNoFunction()
        Dim SqlAll As String = [Ô]SELECT * FROM clientes;[Ô]
        Dim result As New List(Of Clientes)
        Try
            Using conn As New MySqlConnection([Ô]server = localhost;user Id = root;password = 123456;database = test[Ô])
                Using cmd As New MySqlCommand(SqlAll, conn)
                    conn.Open()
                    Using rdr As MySqlDataReader = cmd.ExecuteReader()
                        While rdr.Read()
                            result.Add(New Clientes(rdr.Item([Ô]idclientes[Ô]), rdr.Item([Ô]nome[Ô]), rdr.Item([Ô]idade[Ô])))
                        End While
                    End Using
                End Using
            End Using
        Catch ex As Exception

        End Try
        RaiseEvent alllist(result)
    End Sub 


  Private Sub Alllist(A As List(Of Clientes)) Handles DD.alllist
        DataGridView2.DataSource = A
    End Sub


mas mesmo assim, apareceu este erro:
Citação:

Operação entre threads inválida: controle [ô]DataGridView2[ô] acessado de um thread que não é aquele no qual foi criado.



teria que parar essa thread? ou o que eu estou tentando fazer é impossível?
KERPLUNK 03/10/2016 16:47:53
#467831
Como já expliquei, threads são coisas que rodam em separado e podem ou não se comunicar. O que está acontecendo, é que seu datagrid roda em uma thread(a da aplicação), então você está criando uma segunda thread para fazer alguma coisa e à partir dessa, tentando atualizar um componente na thread da aplicação, isso é o que eu falei de erros de crossthread. E também como já disse, trabalhar com threads é algo bem avançado e não muito indicado para principiantes.
Página 4 de 5 [50 registro(s)]
Faça seu login para responder
Voltar