[VB.NET] Aggiornare una TextBox in un ciclo while

[angelo86]

Ciao
vorrei aggiornare in un ciclo while una TextBox1 che si autoincrementa numericamente ad ogni ciclo...
Il problema e che il ciclo nn tiene proprio in considerazione il textbox e quindi nn lo aggiorna..

Ecco il codice:

	While (copiato < totale)
           
	     .....codice dal eseguire......

            copiato = copiato + i


            Dim pc As Integer = Int((copiato / totale) * 100.0)
            Dim perc As String = pc.ToString()
            TextBox1.Text = perc + "%"


        End While

Come mai nn si aggiorna il "TextBox1.Text = perc + "%" "?
Come posso risolvere questo incoveniente?

[MItaly]

Aggiungi un TextBox1.Refresh.

[oregon]

Direi di provare ad aggiungere un

DoEvents

nel ciclo ...

[MItaly]

Personalmente credo sia il caso di usare il meno possibile il DoEvents (che è un'operazione molto dispendiosa in termini di impiego di CPU)... spesso un Refresh basta e avanza.

[oregon]

Il DoEvents e' importante per garantire il flusso dei messaggi ... nel caso specifico per i WM_PAINT che garantiscono il refresh grafico della finestra e permettono all'interfaccia di reagire ...

[MItaly]

È quello che logicamente verrebbe da pensare anche a me, ma se tu inserisci un codice di questo genere:

    Private Sub Form1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Click
        For c As Integer = 1 To 10000
            Label1.Text = c.ToString()
            Label1.Refresh()
        Next
    End Sub

Vedi nella label i numeri che scorrono tranquillamente. Sto facendo un po' di ricerche con ILDASM su come può funzionare una cosa del genere, e ho visto che all'atto pratico Refresh richiama Invalidate e Update

.method public hidebysig newslot virtual 
        instance void  Refresh() cil managed
{
  // Code size       14 (0xe)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldc.i4.1
  IL_0002:  call       instance void System.Windows.Forms.Control::Invalidate(bool)
  IL_0007:  ldarg.0
  IL_0008:  call       instance void System.Windows.Forms.Control::Update()
  IL_000d:  ret
} // end of method Control::Refresh

Update a sua volta richiama l'API UpdateWindow

.method public hidebysig instance void  Update() cil managed
{
  // Code size       29 (0x1d)
  .maxstack  8
  IL_0000:  ldarg.0
  IL_0001:  ldfld      class System.Windows.Forms.Control/ControlNativeWindow System.Windows.Forms.Control::window
  IL_0006:  ldarg.0
  IL_0007:  ldfld      class System.Windows.Forms.Control/ControlNativeWindow System.Windows.Forms.Control::window
  IL_000c:  callvirt   instance native int System.Windows.Forms.NativeWindow::get_Handle()
  IL_0011:  newobj     instance void [mscorlib]System.Runtime.InteropServices.HandleRef::.ctor(object,
                                                                                               native int)
  IL_0016:  call       bool System.Windows.Forms.SafeNativeMethods::UpdateWindow(valuetype [mscorlib]System.Runtime.InteropServices.HandleRef)
  IL_001b:  pop
  IL_001c:  ret
} // end of method Control::Update

La MSDN a tal proposito dice questo:

The UpdateWindow function updates the client area of the specified window by sending a WM_PAINT message to the window if the window's update region is not empty. The function sends a WM_PAINT message directly to the window procedure of the specified window, bypassing the application queue. If the update region is empty, no message is sent.

Che la parte evidenziata c'entri qualcosa con tutto questo? Qui c'è bisogno della conferma di qualcuno più esperto di me...

[MItaly]

Ok, il grande capo mi dà ragione...
http://www.devx.com/vb2themax/Tip/18646

[alka]

Originariamente inviato da MItaly
Ok, il grande capo mi dà ragione...

Sì, ma non funziona sempre, checché ne dica Balena.

[oregon]

Sì ... infatti ... non e' sempre come dice Francesco ...

Intanto stiamo parlando di VB6 e VB.NET e, sebbene "sotto" ci stia sempre Windows, tutto quello che c'e' "sopra" e' molto diverso ...

In secondo luogo, anche se il messaggio e' inviato direttamente alla wproc del controllo, il messaggio deve essere comunque processato (estratto dalla coda e gestito) e, soprattutto in condizioni di single threading (come per VB6), questa operazione può essere effettuata con molto ritardo.

Considera anche che il messaggio WM_PAINT è uno dei messaggi più a basso livello e quindi viene trattato ancora con meno "solerzia" ... a volte il DoEvents si rende necessario (in dipendenza dalle condizioni di carico della CPU ...). Il fatto di essere in un ambiente multithreading, in realta', facilita .NET da questo punto di vista .

[MItaly]

Capisco, ma stavo anche pensando: questa frase:

The function sends a WM_PAINT message directly to the window procedure of the specified window, bypassing the application queue.

non significa "questa funzione richiama direttamente la window procedure della finestra"? Cioè, se io da un certo evento richiamo UpdateWindow non succederà qualcosa di questo genere?

• viene richiamata la wndproc allo scatenarsi di un evento (diciamo un WM_COMMAND);
• dalla wndproc vengono richiamate una serie di funzioni che in base al messaggio decidono che delegate richiamare;
• nel delegate viene richiamata UpdateWindow;
• UpdateWindow richiama, sempre dallo stesso thread chiamante, la wndproc della finestra passandole WM_PAINT come messaggio; viene a crearsi una ricorsione;
• la wndproc aggiorna quel che deve aggiornare e ritorna;
• il delegate ritorna;
• le funzioni intermedie ritornano;
• anche la wndproc, che era lì in attesa, ritorna.

wndproc[funzioni varie[delegate impostato dal programmatore[UpdateWindow[wndproc[funzione di refresh]]]]]
Può essere o è una mia follia?