Lectura del Puerto serie y problemas con los thread

Lo que ocurre es que el procedimiento del evento DataReceived se ejecuta en
un hilo obtenido del ThreadPool, que evidentemente no es el hilo que ejecuta
el interfaz de usuario. Como Windows Forms no es seguro para subprocesos,
sólo debe accederse al intefaz de usuario desde un único hilo, este hilo es
el hilo principal o hilo del interfaz de usuario. La solución es que desde
el procedimiento del evento DataReceived invoques a otro método de manera
que ese otro método se ejecute en el hilo principal, este "thread switch"
puede conseguirse mediante los métodos BeginInvoke e Invoke de la clase
control.

Saludos:

Jesús López



"Bingen" escribió en el mensaje
news:u209eY%

Hola a Todos.

Estoy realizando unas pruebas con la lectura de los puertos serie. En
cuanto a la lectura del propio puerto no tengo problemas en cuanto que
Visual 2005 proporciona muchas facilidades. En problema surge en el
momento de querer visualizar los datos.

Utilizo el evento de DataReceived para detectar la recepción de datos. En
la función leo una línea del puerto y la asigno en el text de un label.
Aqui me da error de Thread, indicandome que se intenta acceder mediante un
thread que no creo el control. ¿ Alguno de ustedes podría explicarme el
hecho ?, es decir, ¿ Resulta que la lectura de puertos implica que se crea
un hilo diferente al tratamiento de la interfaz y por consiguiente debo de
trabajar con hilos ?

Muchas gracias por vuestro tiempo.
Bingen

Gracias por tu respuesta. Una cuestión (abusando...), quisiera envolver toda
la gestión del puerto serie y la interpretación de su contenido separandolo
del resto del programa. Por ello, una vez que exista información util para
el sistema, generaría un evento desde la clase "gestora del puerto". Según
entiendo y veo, si genero el evento, como este evento lo genero a raíz del
evento DataReceived, estoy en las mismas. ¿ Como realizo para decirle al
hilo principal para que genere el evento ?

' Parte de código de la clase gestora del puerto e interpretación de los
datos

public Event HayDatos
Private Sub SerialPort1_DataReceived(ByVal sender As Object, ByVal e As
System.IO.Ports.SerialDataReceivedEventArgs) Handles
SerialPort1.DataReceived
'Obtengo los datos, los interpreto, genero el evento
raiseevent HayDatos ' este evento lo tendría que generar el hilo
principal ¿No? Como ??
End Sub


"Jesús López" escribió en el mensaje
news:%23ATh3i%

Lo que ocurre es que el procedimiento del evento DataReceived se ejecuta
en un hilo obtenido del ThreadPool, que evidentemente no es el hilo que
ejecuta el interfaz de usuario. Como Windows Forms no es seguro para
subprocesos, sólo debe accederse al intefaz de usuario desde un único
hilo, este hilo es el hilo principal o hilo del interfaz de usuario. La
solución es que desde el procedimiento del evento DataReceived invoques a
otro método de manera que ese otro método se ejecute en el hilo principal,
este "thread switch" puede conseguirse mediante los métodos BeginInvoke e
Invoke de la clase control.

Saludos:

Jesús López



"Bingen" escribió en el mensaje
news:u209eY%

Hola a Todos.

Estoy realizando unas pruebas con la lectura de los puertos serie. En
cuanto a la lectura del propio puerto no tengo problemas en cuanto que
Visual 2005 proporciona muchas facilidades. En problema surge en el
momento de querer visualizar los datos.

Utilizo el evento de DataReceived para detectar la recepción de datos. En
la función leo una línea del puerto y la asigno en el text de un label.
Aqui me da error de Thread, indicandome que se intenta acceder mediante
un thread que no creo el control. ¿ Alguno de ustedes podría explicarme
el hecho ?, es decir, ¿ Resulta que la lectura de puertos implica que se
crea un hilo diferente al tratamiento de la interfaz y por consiguiente
debo de trabajar con hilos ?

Muchas gracias por vuestro tiempo.
Bingen

Tambien puede servirte la siguiente explicacion :
http://msmvps.com/blogs/peplluis/ar...96905.aspx
Saludos,

[MVP] Visual Developer - Visual Basic


"unknown" wrote:

Ya te lo he dicho ;-) puedes usar Control.BeginInvoke, pero mejor sería
usar SyncronizationContext que es más 2.0. Por ejemplo:


Public Class SerialPortManager
Private WithEvents port As System.IO.Ports.SerialPort
Private SyncContext As System.Threading.SynchronizationContext

Private OnDataReceivedCallback As System.Threading.SendOrPostCallback

Public Event DataReceived As
System.IO.Ports.SerialDataReceivedEventHandler

Public Sub New(ByVal PortName As String)
port = New System.IO.Ports.SerialPort(PortName)
port.Open()
SyncContext = System.Threading.SynchronizationContext.Current
OnDataReceivedCallback = New
System.Threading.SendOrPostCallback(AddressOf OnDataReceived)
End Sub

Private Sub OnDataReceived(ByVal e As Object)
RaiseEvent DataReceived(Me, DirectCast(e,
System.IO.Ports.SerialDataReceivedEventArgs))
End Sub

Private Sub port_DataReceived(ByVal sender As Object, ByVal e As
System.IO.Ports.SerialDataReceivedEventArgs) Handles port.DataReceived
SyncContext.Post(OnDataReceivedCallback, e)
End Sub
End Class

Con esto, SerialPortManager lanza el evento DataReceived en el hilo
principal.

Saludos:

Jesús López

"Bingen" escribió en el mensaje
news:O%

Gracias por tu respuesta. Una cuestión (abusando...), quisiera envolver
toda la gestión del puerto serie y la interpretación de su contenido
separandolo del resto del programa. Por ello, una vez que exista
información util para el sistema, generaría un evento desde la clase
"gestora del puerto". Según entiendo y veo, si genero el evento, como este
evento lo genero a raíz del evento DataReceived, estoy en las mismas. ¿
Como realizo para decirle al hilo principal para que genere el evento ?

' Parte de código de la clase gestora del puerto e interpretación de los
datos

public Event HayDatos
Private Sub SerialPort1_DataReceived(ByVal sender As Object, ByVal e As
System.IO.Ports.SerialDataReceivedEventArgs) Handles
SerialPort1.DataReceived
'Obtengo los datos, los interpreto, genero el evento
raiseevent HayDatos ' este evento lo tendría que generar el hilo
principal ¿No? Como ??
End Sub


"Jesús López" escribió en el mensaje
news:%23ATh3i%

Lo que ocurre es que el procedimiento del evento DataReceived se ejecuta
en un hilo obtenido del ThreadPool, que evidentemente no es el hilo que
ejecuta el interfaz de usuario. Como Windows Forms no es seguro para
subprocesos, sólo debe accederse al intefaz de usuario desde un único
hilo, este hilo es el hilo principal o hilo del interfaz de usuario. La
solución es que desde el procedimiento del evento DataReceived invoques a
otro método de manera que ese otro método se ejecute en el hilo
principal, este "thread switch" puede conseguirse mediante los métodos
BeginInvoke e Invoke de la clase control.

Saludos:

Jesús López



"Bingen" escribió en el mensaje
news:u209eY%

Hola a Todos.

Estoy realizando unas pruebas con la lectura de los puertos serie. En
cuanto a la lectura del propio puerto no tengo problemas en cuanto que
Visual 2005 proporciona muchas facilidades. En problema surge en el
momento de querer visualizar los datos.

Utilizo el evento de DataReceived para detectar la recepción de datos.
En la función leo una línea del puerto y la asigno en el text de un
label. Aqui me da error de Thread, indicandome que se intenta acceder
mediante un thread que no creo el control. ¿ Alguno de ustedes podría
explicarme el hecho ?, es decir, ¿ Resulta que la lectura de puertos
implica que se crea un hilo diferente al tratamiento de la interfaz y
por consiguiente debo de trabajar con hilos ?

Muchas gracias por vuestro tiempo.
Bingen

Muy muy muy agradecido !!!

Un saludo
Bingen


"Jesús López" escribió en el mensaje
news:

Ya te lo he dicho ;-) puedes usar Control.BeginInvoke, pero mejor sería
usar SyncronizationContext que es más 2.0. Por ejemplo:


Public Class SerialPortManager
Private WithEvents port As System.IO.Ports.SerialPort
Private SyncContext As System.Threading.SynchronizationContext

Private OnDataReceivedCallback As System.Threading.SendOrPostCallback

Public Event DataReceived As
System.IO.Ports.SerialDataReceivedEventHandler

Public Sub New(ByVal PortName As String)
port = New System.IO.Ports.SerialPort(PortName)
port.Open()
SyncContext = System.Threading.SynchronizationContext.Current
OnDataReceivedCallback = New
System.Threading.SendOrPostCallback(AddressOf OnDataReceived)
End Sub

Private Sub OnDataReceived(ByVal e As Object)
RaiseEvent DataReceived(Me, DirectCast(e,
System.IO.Ports.SerialDataReceivedEventArgs))
End Sub

Private Sub port_DataReceived(ByVal sender As Object, ByVal e As
System.IO.Ports.SerialDataReceivedEventArgs) Handles port.DataReceived
SyncContext.Post(OnDataReceivedCallback, e)
End Sub
End Class

Con esto, SerialPortManager lanza el evento DataReceived en el hilo
principal.

Saludos:

Jesús López

"Bingen" escribió en el mensaje
news:O%

Gracias por tu respuesta. Una cuestión (abusando...), quisiera envolver
toda la gestión del puerto serie y la interpretación de su contenido
separandolo del resto del programa. Por ello, una vez que exista
información util para el sistema, generaría un evento desde la clase
"gestora del puerto". Según entiendo y veo, si genero el evento, como
este evento lo genero a raíz del evento DataReceived, estoy en las
mismas. ¿ Como realizo para decirle al hilo principal para que genere el
evento ?

' Parte de código de la clase gestora del puerto e interpretación de los
datos

public Event HayDatos
Private Sub SerialPort1_DataReceived(ByVal sender As Object, ByVal e As
System.IO.Ports.SerialDataReceivedEventArgs) Handles
SerialPort1.DataReceived
'Obtengo los datos, los interpreto, genero el evento
raiseevent HayDatos ' este evento lo tendría que generar el hilo
principal ¿No? Como ??
End Sub


"Jesús López" escribió en el mensaje
news:%23ATh3i%

Lo que ocurre es que el procedimiento del evento DataReceived se ejecuta
en un hilo obtenido del ThreadPool, que evidentemente no es el hilo que
ejecuta el interfaz de usuario. Como Windows Forms no es seguro para
subprocesos, sólo debe accederse al intefaz de usuario desde un único
hilo, este hilo es el hilo principal o hilo del interfaz de usuario. La
solución es que desde el procedimiento del evento DataReceived invoques
a otro método de manera que ese otro método se ejecute en el hilo
principal, este "thread switch" puede conseguirse mediante los métodos
BeginInvoke e Invoke de la clase control.

Saludos:

Jesús López



"Bingen" escribió en el mensaje
news:u209eY%

Hola a Todos.

Estoy realizando unas pruebas con la lectura de los puertos serie. En
cuanto a la lectura del propio puerto no tengo problemas en cuanto que
Visual 2005 proporciona muchas facilidades. En problema surge en el
momento de querer visualizar los datos.

Utilizo el evento de DataReceived para detectar la recepción de datos.
En la función leo una línea del puerto y la asigno en el text de un
label. Aqui me da error de Thread, indicandome que se intenta acceder
mediante un thread que no creo el control. ¿ Alguno de ustedes podría
explicarme el hecho ?, es decir, ¿ Resulta que la lectura de puertos
implica que se crea un hilo diferente al tratamiento de la interfaz y
por consiguiente debo de trabajar con hilos ?

Muchas gracias por vuestro tiempo.
Bingen