Saltar al contenido principal

 none
Manipulando controles de un formulario desde una clase RRS feed

  • Pregunta

  • Buenas estoy trabajando con winsocket para recibir datos, lo tengo realizado en vb.net consola, como lo deseo en winform, lo converti, el problema es que en Consola se puede usar Console.write(), entonces estoy tratando de imitar esto, agregando lineas en un textbox, que tiene la opcion multiline activada.

    Asi que lo que tengo un formulario y la clase( donde estan las funciones), desde el formulario solo hago cosas simples, 

    Codigo 1

    dim server as server= new Server(ip, puerto)
    
    server.star()
    
    server.Loogedin.Wait()
    
    ..
    ...
    

    en cambio la programacion esta en la clase, como es comprensible este codigo queda a la espera de recibir un dato desde stream de la clase server, entonces cree un backgroundprocess el cual tiene el Codigo 1 en el proceso Do_Work.

    Bueno el problema es que deseo escribir lo que va sucediendo en la clase server en el textbox del formulario 1, para eso probe dos cosas que no funcionaron, 

    1~ 

    Public sub Consola(msg as string)
    txtConsola.text & = msg & vbNewLine
    end sub

    Entonces llamaba a consola desde Server 

    dim frm as new form1
    frm.consola("mensaje")

    Pero no funciona, si enviaba el valor, y poniendo breackpoint me daba cuenta que el el valor de txtConsola aumentaba que era lo que debia hacer, pero en pantalla no pasaba nada, entonces probe con invoke y delegate pero no funciona

    2~ cree una función en la clase Server que hacia referencia de igual modo a txtconsola con un new form1 pero no paso nada

    por favor que solucion me proponen


    J4 Programing

    miércoles, 21 de enero de 2015 0:53

Respuestas

Todas las respuestas

  • Yo creo que el problema está aquí:

    dim frm as new form1
    frm.consola("mensaje")

    Cada vez que quieres mostrar un mensaje, crear una nueva instancia del formulario y le pasas el mensaje. Esa nueva instancia es otra diferente de la que ya está mostrando. Una solución podría ser encontrar el formulario de ese tipo que está abierto:

            Dim frm As Form1 = Application.OpenForms.Cast(Of Form).OfType(Of Form1).FirstOrDefault()
            If Not frm Is Nothing Then
                frm.Consola("Mensaje")
            End If

    Otra solución sería hacer una clase que usara Server y que lanzara un evento. El formulario instanciaría esta clase y se subsribiría al evento.



    Jesús López


    EntityLite a lightweight, database first, micro orm

    miércoles, 21 de enero de 2015 6:01
  • Funciono agregando tus lineas y adicionando esta linea en el LoadForm, 

    CheckForIllegalCrossThreadCalls = False

    Pero mi duda es si es lo mas optimo, te explico un poco mejor acerca de lo que estoy tratando de hacer, El programa que deseo implementar en si es un Repetidor(cliente-servidor) trabajano con sockets, La información actualizada la recibo como cliente socket, estos datos debo tomarlos, y enviarlos a los diferentes clientes web(automáticamente), Lo hago con winform por que deseo poder darle click a cualquier cliente y poder enviarle un msg personal, o global, o automatico( que es como va a funcionar), entonces esta parte es solo la cliente, entonces esta clase en si debería llamarse cliente,por que hace un ListenerSocket, como es un winform estoy usando el BackgroundProccess para llamar a la clase cliente, así evito que se cuelgue.

    La Clase usa un

    dim task as System.Threading.Tasks msg_pump_task = Task.Factory.StartNew(MsgPump(), m_cancel_token_src, TaskCreationOptions.LongRunning, TaskScheduler.Default)

    para crear un nuevo Thread, por que aca va a faltar otro subproceso que se ejecutara al momento que debo enviar los datos a los clientes( actuando como server) " Obviamente con diferente conexiones Sockets" donde debere crear una clase Server, que hará lo propio.

    No se si me estoy haciendo bolas pero, necesito una o varias opiniones adicionales

    Gracias de antemano


    J4 Programing


    miércoles, 21 de enero de 2015 8:08
  • Es una mala idea desactivar la comprobación de llamadas inter-subprocesos ilegales.

    CheckForIllegalCrossThreadCalls = False

    Lo recomendable es usar SynchonizationContext.Post

    En cuanto a si es óptimo o no, no sé decirte, porque en realidad no sé qué es lo que quieres optimizar.



    Jesús López


    EntityLite a lightweight, database first, micro orm

    miércoles, 21 de enero de 2015 9:19
  • Hablo de optimizar en cuanto a no sobrecargar los procesos tratando de crear cada uno de ellos en hilos (diferentes thread )de manera correcta, por que se va a tener un hilo que funcionara como cliente y otro para servidor que a la vez creara otros hilos para cada cliente que se va a conectar, y yo lo que busco es que entre la Entrada->Procesamiento-->Envio no se pierda mucho tiempo, en cuestión de recursos no hay problemas por que la aplicación estará funcionando sola  en un servidor 

    J4 Programing

    miércoles, 21 de enero de 2015 9:45
  • Eso de un hilo por cada cliente no muy escalable, ¿Cuantos clientes esperas tener? Si son pocos no importa, pero si van a ser muchos sería mejor usar sockets asíncronos.


    Jesús López


    EntityLite a lightweight, database first, micro orm

    miércoles, 21 de enero de 2015 11:18
  • En realidad por el momento no pasara de 20, pero en un futuro se espera muchos mas, a partir de cuantos crees que seria lo mejor usar asincronos y me podrías dar un ejemplo de como implementar sockets asincronos algo simple para entenderlo mejor

    Gracias


    J4 Programing

    miércoles, 21 de enero de 2015 14:26
  • Yo creo que 20 ya es como para ir pensando en los sockets asíncronos.

    Hay algunos ejemplos en la Red, elige el que más te guste:

    asynchronous socket



    Jesús López


    EntityLite a lightweight, database first, micro orm

    miércoles, 21 de enero de 2015 16:18