[vb net] Richiesta info sui thread

[Marte99]

Sto facendo un programma in VB net che legge un flusso di dati dalla porta seriale.

Ho fatto una classe che gestisce la porta seriale e che viene usata da una applicazione form based.

Ho usato il vecchio controllo MScomm di VB6 che mi lancia l'evento Oncomm ogni volta che ci sono caratteri da leggere nella porta seriale. L'evento Oncomm invoca il metodo della classe per lo scarico dei dati dalla porta seriale

Problema:
Quando lancio il programma, l'interfaccia grafica si blocca durante la lettura dei dati dalla porta seriale perchè il controllo passa al metodo della classe che gestisce la porta seriale.

Volevo chiedervi come posso fare per usare il ThreadPool.QueueUserWorkItem per scaricare i bytes senza perdere il controllo del form

Volevo anche usare una label da mettere sul form che mi mostra il numero di bytes scaricati dal metodo della classe


Questo è l'evento che che parte ogni volta che ci sono caratteri
nella porta seriale:


-------------------------------------------------------------------------
Private Sub MSComm1_OnComm() Handles vfObjMSComm.OnComm

If vfObjMSComm.CommEvent = MSCommLib.OnCommConstants.comEvReceive Then

If False = vfObjClassRS232connection.fBolDecodeETPCommandReturn(Me.Name,vfStrErrorString,vfObjMSComm,vfRS232TimeOut, vfStrCommandReturn, vStrBlockCount) Then
Return
End If

End If

End Sub

-------------------------------------------------------------------------


Il metodo della classe è: fBolDecodeETPCommandReturn

l'ultimo parametro del metodo è: vStrBlockCount
questo parametro è passato per riferimento al metodo della classe e viene aggiornato continuamente dentro al metodo della classe e il suo contenuto dovrebbe essere mostrato da una label
sul form



Qualcuno può darmi una mano....

[gugoXX]

Per intanto ti consiglio di usare l'oggetto SerialPort, direttamente disponibile in C# e VB.net, e di lasciare stare l'oggetto COM.

Tale oggetto espone l'evento "DatoRicevuto" (non mi ricordo come si chiama).

Proverei ad usare questo.
Se il tuo metodo per processare i dati non e' troppo pesante, allora non dovresti notare nessun rallentamento sulla UI.

[Marte99]

Ok proverò a riscivere la parte di codice che riguarda la porta seriale....

vorrei chiederti se sai come si fa a ad usare il ThreadPool.QueueUserWorkItem
quando hai un metodo di una classe che esegue una lunga computazione e si vuole aggiornare una label del form con un valore che viene aggiornato all'interno del membro di una classe.

mi saresti di grande aiuto....

[gugoXX]

Ciao.

I ThreadPool servono principalmente quando si hanno gruppi di lavori da eseguire in parallelo, tipicamente aventi caratteristiche comuni
ovvero che sono proprio lo stesso lavoro (con diversi input), oppure che derivano tutti da una stessa classe di operativita'.
Ci sono facilities per i ThreadPool per sincronizzare i diversi lavori in parallelo, come p.es. attendere che tutti abbiano finito, oppure attendere che anche solo uno abbia finito, etc.
Nulla vieta ovviamente di usarli per un solo lavoro, ma per questo ti consiglio di studiare il sempilce Thread, cosicche' poi riuscirai anche da solo a capire i ThreadPool.

Un Thread e' un pezzo di codice che viene eseguito in parallelo, fa parte dello stesso processo che lo lancia, puo' accedere alle stesse risorse, puo' essere controllato (Start, Suspend, Join, etc.)

Cerca online delle parti di codice che spiegano come scrivere, fare partire e controllare un Thread.

Poi, come aggiornare parti visuali del processo principale,ovvero il thread della finestra che ha lanciato il tuo thread, e' un altro discorso.
Dovrai imparare il concetto di "event" e se non lo sai anche di delegate (cerca di nuovo), lanciare un evento, intercettarlo dalla finestra principale, sincronizzarlo (ti possiamo poi spiegare cosa vuol dire quando ci arriverai) e infine cambiare finalmente il contenuto visuale della finestra.

Quindi direi:
1) Capire e lanciare un Thread che fa qualcosa
2) Capire come lanciare un Event da parte del Thread, e di come intercettarlo da parte della finestra
3) Sincronizzare l'evento sul thread della finestra, ovvero fare in modo di eseguire un pezzo di codice sul thread della finestra, stimolato (triggerato) pero' dall'evento del thread che si sta studiando, questo perche' solo il thread della finestra e' autorizzato a cambiare parti visuali della finestra stessa.

[Marte99]

Capisco...

Da quello che ho letto in rete il thread più adatto per il mio programma
dovrebbe essere il BackgroundWorker...

Ieri ho provato con il BackgroundWorker implementatato in questo modo:



-------------------------------------------------------------------------

Private Sub MSComm1_OnComm() Handles vfObjMSComm.OnComm

If vfObjMSComm.CommEvent = MSCommLib.OnCommConstants.comEvReceive Then

TestWorker = New System.ComponentModel.BackgroundWorker
TestWorker.WorkerReportsProgress = True
TestWorker.WorkerSupportsCancellation = True
TestWorker.RunWorkerAsync()

End If

End Sub

-------------------------------------------------------------------------

Private Sub TestWorker_DoWork(ByVal sender As Object, ByVal e As System.ComponentModel.DoWorkEventArgs) Handles TestWorker.DoWork

If False = vfObjClassRS232connection.fBolDecodeETPCommandReturn(Me.Name, vfStrErrorString, vfObjMSComm, vfRS232TimeOut, vfStrCommandReturn, vStrBlockCount)
Then
Return
End If

TestWorker.ReportProgress(vStrBlockCount)

End Sub

-------------------------------------------------------------------------

Private Sub TestWorker_ProgressChanged(ByVal sender As Object, ByVal e As System.ComponentModel.ProgressChangedEventArgs) Handles TestWorker.ProgressChanged
Label1.Text = e.UserState
End Sub

-------------------------------------------------------------------------


Purtroppo quando lo lancio mi appare questo errore:


Error Message: Operazione di cross-thread non valida: è stato eseguito l'accesso al controlllo 'frmMain' da un thread diverso da quello da cui è stata eseguita la creazione.


Hai un suggerimento....

[gugoXX]

Quello in cui occorso e' proprio il problema della sincronizzazione. Solo il thread della finestra puo' cambiare il contenuto visuale della finestra stessa.

Potrei aituarti in C#, dato che la sintassi del VB.net non la conosco bene. Il concetto e' lo stesso, ma e' piu' che altro un problema di sintassi, dato che le righe di codice sono solo 5/6

[Marte99]

Va bene anche il C# poi provo io a fare la traduzione...

Grazie in anticipo...

[MarcoGG]

Originariamente inviato da Marte99

Problema:
Quando lancio il programma, l'interfaccia grafica si blocca durante la lettura dei dati dalla porta seriale perchè il controllo passa al metodo della classe che gestisce la porta seriale.

Ma non potresti semplicemente "spostare" la tua classe su un'altra piccola Form, magari una piccola FixedToolWindow, con una label e un timer che aggiorna periodicamente il valore desiderato ?
Parecchio tempo fa avevo un piccolo problema con una progressbar, che rimaneva bloccata sulla Form principale e poi schizzava al 100% a processo finito. Ricordo che ho risolto semplicemente spostando quell'operazione su una piccola Form secondaria, sbloccando del tutto quella principale...
Insomma alla fine se è solo un problema di blocco Form, credo si possa risolvere senza multithread.

[Marte99]

Inizialmente il progetto l'ho fatto in visual C++ in cui il problema è stato risolto con il multithreading. Ora lo devo tradurre in un progetto VB net e devo rimanere aderente al funzionamento dell'interfaccia grafica per non dover aggiornare figure e descrizioni di manuali che parlano del sorgente....insomma devo usare il multithread con le classi...se mi aiutate vene sono grato, se per caso vi può interessare vi posso far vedere come si fa i Visual C++ anche se ormai nn si usa più...

va benissimo anche un pezzetto di sorgente in C#...

[gugoXX]

Allego una risposta perntinente data gia' a suo tempo:

Non puoi accedere a metodi che abbiano a che fare con la parte visuale di una form (o un controllo) da parte di un thread diverso da quello della form ospitante.
La soluzione e' sempre quella del delegate.

Se invece stai usando un thread solo per temporizzare qualcosa che periodicamente deve essere fatto, ti consiglio l'uso del controllo Timer, che ha gia' scritto tutto il codice per te, e io tuo codice girerebbe gia' sotto il thread della finestra.

Altrimenti, questa e' la versione C#2.0 per quello che chiedi (se ho capito bene)

private Thread th = null;

// Nella load o dove ti serve
th = new Thread(new ThreadStart(ThreadBody));
            th.Start();
// se non altrimenti gestito
//    almeno nella FormClosing metterei la Join del Thread
...
...

private void ThreadBody()
{
    Thread.Sleep(5000);
    int mioval = THRoutine();
    MessageBox.Show(mioval.ToString());
}

// Esempio di una proprieta'/metodo che fa accesso ad un parametro della form
// E che ritornera' un intero
private delegate int IntDelegate();

private int THRoutine()
{
    if (InvokeRequired) return (int)Invoke(new IntDelegate(THRoutine));
    else
    {
        BackColor = Color.FromArgb(128, 200, 255);
        button1.Text = "PPPPRRR";
        return (int)BackColor.R + (int)BackColor.G + (int)BackColor.B;
    }
}

Con il C# 3.0 e' possibile fare qualcosa di un pelino piu' comodo.
Si potrebbe scrivere il seguente codice anche per C#2.0, ma e' tanto che non uso piu' le implicit delegate, dato che le Func sono cosi' comode...

private Thread th = null;

// Nella load o dove ti serve
th = new Thread(new ThreadStart(ThreadBody));
            th.Start();
// se non altrimenti gestito
//    almeno nella FormClosing metterei la Join del Thread
...
...
private void ThreadBody()
{
    Thread.Sleep(5000);
    int mioval = FormThreadExecutor<int>( () => {
                    BackColor = Color.FromArgb(128, 200, 255);
                    button1.Text = "PPPPRRR";
                    return (int)BackColor.R + (int)BackColor.G + (int)BackColor.B;
                });
    MessageBox.Show(mioval.ToString());
}        
            
private T FormThreadExecutor<T>(Func<T> CodeToBeInvoked)
{
    if (InvokeRequired) return (T)Invoke(CodeToBeInvoked);
    else return CodeToBeInvoked();
}

In questo modo il FormThreadExecutor e' scritto una volta sola, ritorna un parametro di tipo variabile, e si potranno scrivere tutti i codici da sincronizzare direttamente dentro il ThreadBody(Certo, se devi sincronizzare una cosa sola, allora voto per la soluzione C#2.0).
Oppure usando le extension e/o le partial class puoi scrivere questo FormThreadExecutor in una tua libreria, cosicche' tutte le tue soluzioni WinForm avranno questo metodo gia' pronto per l'uso.

[Marte99]

sono riuscito a risolvere il problema con il BackGroundWorker e ad aggiornare anche la label finalmente....


Grazie a tutti per l'aiuto e i pezzi d icodice che mi avete inviato, hanno servito per farmi ragionare


Grazie ancora !