SerialPort y Formularios

Hola.

La forma más correcta desde el punto de vista de un sistema en tiempo real
es que dicho componente resida en un hilo independiente de la aplicación y
que la actualización de la UI la hagas mediante llamadas a Invoke. De esa
forma aíslas el control del puerto serie de cualquier cosa y te facilita el
control síncrono o asíncrono del mismo.

Ahora bien, muchas veces no merece la pena el esfuerzo... Y la forma en que
lo haces pienso que es la más correcta, salvo que podrías llegar a perder
alguna recepción... Una variante que se me ocurre es que crees una clase
global estática (¡Variables globales normales para C# YAAAAAAAAAAAAAA!) que
encapsule el puerto serie a la que le pases una referencia a la ficha activa
en ese momento y que sea esa clase la que invoque el delegado de cada ficha
dependiendo de cuál le hayas indicado.

Otra forma es que tengas ambos delegados instalados y un bool en cada ficha
que esté a true cuando dicha ficha esté activa, es decir

class Ficha1
{
Ficha1Delegado()
{
if(estoyActiva)
{
}
}
}

class Ficha2
{
Ficha2Delegado()
{
if(estoyActiva)
{
}
}
}

Podría valerte la propiedad de Active o Visible de la propia ficha.

El único inconveniente aquí sería la invocación de dos delegados ante cada
evento del puerto...


"Plextor" wrote in message
news:

Hola, a ver si alguien me puedo echar un cable

Tengo un formulario principal con un SerialPort haciendo polling a un COM.
En dicho formulario también tengo el correspondiente delegado de
recepciones de tramas.

Desde dicho formulario puedo abrir otro Form en el cual también quiero que
(bajo petición) pueda enviar tramas y recibir tramas.

¿Existe alguna manera elegante de realizar esta tarea? Yo, hasta ahora lo
que hacía era pasarle por referencia el SerialPort a el nuevo formulario y
crear en este nuevo formulario un delegado de evento. Pero no sé si es la
mejor opción la de crear y destruir delegados de eventos cada vez que abro
y cierro este form.

¿Alguien tiene alguna sugerencia o ejemplo de hacerlo?

Un saludo,
Plextor

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
El amor es ciego.

¡Variables globales normales para C# YAAAAAAAAAAAAAA!

Rafa,

¿Qué trabajo te cuesta crear una clase y ponerle un campo público estático?
:-)

Abrazo - Octavio

Realmente nada. :-) Y una variable global viola muchas de las normas de la
OO pura, o al menos eso creo, pero para ciertos desarrollos es lo ideal,
como el caso que nos ocupa: un objeto global que representa el puerto serie
y todo su funcionamiento para que sea accedido por todos los demás objetos
de la aplicación sin problemas. Si uno necesita notificación inmediata,
installa unos callback (en este caso delegados) y listo.

Peeeeeeeero resulta que el .NET no se lleva muy bien con los constructores
estáticos, ya que cuando estás haciendo algo no trivial necesitas construir
e inicializar cosas. Entre lo que no me mola está que no es capaz de
capturar bien una excepción producida en un constructor estático: en general
la excepción lanzada no se corresponde con la excepción producida, y a veces
ni siquiera se lanza, sino que la aplicación termina sin más, sobre todo en
código sin debug. Dentro del elemento estático la excepción generada es la
correcta, porque si la capturas a mano la ves, pero cuando te salta la
ventanita o la capturas a un nivel superior, tienes una excepción que nada
tiene que ver con la producida, en InnerException no hay nada, y encima la
información de contexto te redirecciona a la primera línea del primer método
que haya en el fichero de código fuente en el que esté dicho constructor
estático.

Ya sé que se deberían capturar todas las excepciones de forma correcta, pero
cuando estás desarrollando algo completamente estático (un quiosco, por
ejemplo), el código de producción va a ser completamente estático y todos
los objetos van a ser los mismos etc., y no veas lo que j*de que tengas un
problema y no veas dónde se genera... Además, en un quiosco (por ejemplo),
si se ha borrado un archivo poco se puede hacer: mostrar la ventanita
diciendo que falta tal fichero, que se llame al servicio técnico y bloquear
el funcionamiento (o mejor aún: que la máquina inicie una llamada telefónica
automática al servicio técnico... diciendo que se ha producido una excepción
genérica en el módulo genérico y que el InnerException es null, para que el
servicio téncico sepa qué ha pasado, no sé si se nota la ironía). Ese tipo
de excepciones se deben capturar en el nivel más alto, y es una absurda
pérdida de tiempo y código el que cada elemento estático tenga una captura
idéntica a las demás porque el .NET no es capaz de elevar la excepción bien,
etc.

Otro tema con los constructores estáticos es que no puedes llamar a un
constructor estático dentro de otro estático...

"Octavio Hernandez" wrote in message
news:

¡Variables globales normales para C# YAAAAAAAAAAAAAA!

Rafa,

¿Qué trabajo te cuesta crear una clase y ponerle un campo público
estático? :-)

Abrazo - Octavio

Microsoft Visual C++ MVP
==Mi blog sobre programación: http://geeks.ms/blogs/rfog
Mi blog sobre literatura: http://rfog.blogsome.com
Libros, ciencia ficción y programación
El amor es ciego.