none
Para que usar los delegados? RRS feed

  • Pregunta

  • Hola a todos como estan???

    Entiendo que los delegados se pueden definir como apuntadores que apuntan valga la redundancia a algun metodo... Pero para que usar delegados en lugar de usar los metodos directamente???

    De antemano muchisimas gracias por todo...

    sábado, 10 de julio de 2010 18:59

Respuestas

  • Entiendo que surjan dudas con los delegados y su funcionamiento, ya que
    son la evolución última de los callback o funciones de retroll amada. A ver
    si yo soy capaz de explicaros el concepto y los usos más comunes.

    Cuando hacéis doble clic sobre un evento en el listado de enventos  de
    Windows Forms, la función que se abre en el editor es un delegado.  Bueno,
    es un evento, que no es más que un delegado con un formato de par� �metros
    especial definido por el .NET.

    Por lo tanto ya tenemos un uso: si nos suscribimos con un delegado a un
    evento, estamos diciéndole a alguien que, cuando ocurra algo, nos l o
    notifique. Es como cuando vamos a la chica de recepción y le dec� �s: "si
    llama Pepito me lo pasas". La chica coge su lista de "avisar si" y te
    añade. Luego, cuando llame alguien, cogerá la lista de "avisar  si" y
    comprobará si el nombre de quien está llamando tiene algú n "delegado"
    suscrito, y si es así, "ejecutará" dicho delegado.

    Lo mismo ocurre con ese evento al que nos hemos suscrito: cuando se
    produzca la acción (por ejemplo el presionado de un botón) el  sistema
    cogerá su lista de delegados e irá llamando por orden a cada d elegado que
    se haya suscrito.

    Imaginad que tenéis un ordenador con Bluetooth y que queréis q ue vuestro
    programa se entere de cada vez que un elemento se intente parear. Pues
    vosotros instaláis un delegado en el sistema BT y cada vez que otro elemento intente conectarse, ese delegado se ejecutará, de manera q ue el
    código que hayas puesto ahí dentro tendrá que hacer alg� �n tipo de acción
    en respuesta.

    Otra aplicación es la del "delegado asíncrono", que viene a se r como
    decirle a la secretaria que te haga algo mientras tu haces otra cosa.
    Supón que cuando aprieten un botón en tu aplicación se te nga que
    pre-procesar un trabajo de impresión que va a llevar mucho tiempo.  Puedes
    hacerlo mediante un delegado (evento) normal, pero entonces tu aplicaci� �n
    se parará hasta que termine el proceso. Otra opción es crear u n hilo,
    pasar el trabajo ahí y que la aplicación siga en sus cosas has ta que el
    hilo termine. Y puedes usar un delegado asíncrono, que es una forma  rápida
    y lista para funcionar de lo del hilo. Antes de llamar al delegado te
    suscribes a su evento de finalización (otro delegado), y luego lo e jecutas
    asíncronamente. CUando dicho delegado termine, llamará al dele gado al cual
    te has suscrito para informarte de que ha terminado (la secretaria ya ha terminado). La ventaja es que tienes "infinitas" secretarias, porque
    podrás lanzar de nuevo el delegado asíncrono sin que el anteri or termine
    (y deberás llevar la cuenta). ¿Para qué avisar de que ha  terminado? Pues
    para permitir, por ejemplo, cerrar la aplicación, o permitir la edi ción de
    los datos que se estaban procesando...

    Y finalmente en .NET un hilo es la ejecución de un delegado de form a
    simultánea con el hilo principal de la aplicación. En Win32 un  hilo es una
    función ejecutándose de forma simultánea, y en .NET es lo  otro. Mismo
    concepto, diferente implementación.

    Un delegado es lo que en lenguaje técnico se conoce como "closure".  Un
    callback tradicional es un puntero a función: tu guardas dicha dire cción
    en tu lista interna y cada vez que necesites ejecutar dicha función , la
    llamas. En OO hay un problema con los "callback" de funciones miembro,
    porque tienes que almacenar tanto la dirección del método como  la clase a
    la que pertenece (el "this"). Eso es una closure: un this más un pu ntero a
    función. El puntero nos da la función a ejecutar, y el this qu é datos a
    usar (para entender bien esto deberíamos entender cómo funcion a el
    concepto de clase cuando está compilada, en tiempo de ejecució n y a bajo
    nivel).

    Un delegado es más que eso, porque aparte de ser un "this" y un pun tero a
    función, es una clase en sí con una serie de métodos. Y u n evento también.

    Existen delegados "monocast" y multicast. El primero sólo contiene  un
    "this" y un puntero, el segundo puede contener varios de ambos, como una especie de bolsa contenedora de delegados, que serán ejecutados tod os uno
    detrás de otro (a no ser que sean asíncronos) representando el  concepto de
    "vaciar la bolsa".

    On Sat, 10 Jul 2010 20:59:07 +0200, <AdyIr> wrote:

    Hola a todos como estan???

    Entiendo que los delegados se pueden definir como apuntadores que   apuntan valga
    la redundancia a algun metodo... Pero para que usar delegados en lugar    de usar
    los metodos directamente???

    De antemano muchisimas gracias por todo...

    --  Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
    ======================== =============== Cualquier tarea que vale la pena hacer, valía la pena hacerla ayer.  -- Lema de Grossman.


    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 11:29
  • A ver.
     
    Tienes una clase normal y corriente que tiene un delegado que será  un hilo
    en algún momento.
     
    Todos los datos miembro de esa clase son "globales" en cuanto al delegad o:
    cualquier delegado que se esté ejecutando como un hilo podrá v er y cambiar
    esos datos, con el peligro de que tienes que sincronizarlos porque podr� �a
    ocurrir que a medio actualizar uno de esos datos, entre otro hilo y lo l ea
    (o lo modifique) a la vez.
     
    Luego, las variables locales al delegado son independientes de cada hilo .
    Si tenemos 3 hilos en ejecución a partir del mismo delegado, vDato  y
    vEntero son locales e independientes a cada hilo.
     
    Quizás te interese ver este webcast mío sobre hilos:
     
    Allí hablo de delegados y de hilos (y de más cosas). Cuanquier a que vaya a
    usar hilos debería, como poco, conocer todo lo que explico allí .
     
    On Tue, 13 Jul 2010 22:07:52 +0200, Paul P. <Garcia> wrote:
     
    >> Muchas veces la teoría nos deja con la misma duda o incluso con  más  
    >> dudas que la duda original :-)
    >>
    >> Para ver si realmente comprendiste el uso de los delegados, trata de   
    >> resolver el siguiente problema real:
    >>
    >> Suponte que tienes un formulario windows 1 (FM1) y un formulario  
    >> windows 2 (FM2).
    >>
    >> FM1 tiene un Label y un botón de comandos. Al dar clic al bot� �n, se  
    >> muestra FM2.
    >>
    >> FM2 tiene un TextBox y un botón de comandos.
    >>
    >> Deseamos lo siguiente:
    >>
    >> Cuando el usuario escriba algún caracter en el TextBox del FM2 d ebemos  
    >> escribirlo inmediatamente en el Label del FM1 (probablemente porque  
    >> quisieramos validar).
    >>
    >> Cuando demos clic en el boton de FM2 el formulario FM2 debe cerrarse.
    >>
    >> Como lo resolverias? Utilizarias delegados?
    >>
    >> Saludos!!!
    >>
    >> --
    >> MSM-DotNet
    >
    >
    > Hola.
    >
    > En este caso usaria delegados. Aun sin entender muy bien.
    >
    > No me acuerdo bien lo que esta en la MSDN sobre los delegados, pero  
    > cuando se trata de controles existe sincronizacion a nivel grafico com o  
    > de codigo, es decir los 2 deben sincronizarse.
    > En el caso de los label y los textbox debe sincronizarse tanto en la  
    > propiedad Textbox1.Text como en lo que nos va aparecer en el control y   
    > por tanto para resolver esto se debe usar delegados. De seguro me  
    > equivoco pero escribo esto para que alguien me pueda orientar.
    >
    > Ahora en los hilos lo que entiendo es algo asi:
    > Es como una cola de solicitudes, es decir puedo crear varios  
    > procedimiento y como son hilos estos se ponen en cola, es decir si el   
    > sistema esta desocupado y el hilo se puede ejecutar se ejecutara hasta   
    > que el sistema este ocupado nuevamente. Estos hilos se ponen en cola  
    > hasta que se desocupen, tambien se ponen en pausa. Es lo que entiendo. ..
    >
    > Espero que alguien me aclare un poco mas, pero de los hilos creo  
    > entender un poco mas que los delegados, quizas no me este explicando m uy  
    > bien en esto de los hilos.
    >
    > Ahora lo que quisiera saber es si las variables creada en el  
    > procedimiento que llama al hilo son los mismo o se crean otro nuevo co n  
    > otros valores.
    > Me explico, por ejemplo: digamos que el procedimiento que llama al hil o  
    > se llama MiHilo ahora en este procedimiento creo de inicio variables  
    > ejemplo
    >
    > void MiHilo()
    > String vDato
    > int32 vEntero
    > vDato = gDatoGlobal
    >
    > Ahora como veran en el procedimiento vDato se almacena lo que contiene   
    > gDatoGlobal (gDatoGlobal es una variable de ambito publico)
    > Ahora digamos que cuando creamos el hilo gDatoGlobal contenia "hola" p or  
    > tanto vDato contendra "hola" pero que tal si todavia no se termino est e  
    > hilo, y se creo otro hilo pero en este lapso de tiempo gDatoGlobal ya  no  
    > contiene "hola" sino "adios"
    >
    > Mi pregunta es la siguiente: como nuevamente creamos un hilo, quisiera   
    > saber si el nuevo vDato es el mismo que el anterior, es decir los dos   
    > hilos contienen "adios" o en el anterior vDato contiene "hola" y el  
    > nuevo hilo con la variable vDato contiene "adios" ???
    >
    > Puede ser que no me este explicando bien, pero a mi lo que me sirve es   
    > que estos procedimientos sean muy aparte, porque lo que quiero es crea r  
    > cola de solicitudes, ahora si las variables son las mismas cada vez qu e  
    > cree un hilo no me sirve.
    >
     -- 
    Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
    ======================== =============== Hay algo que Dios ha hecho mal. A todo le puso límites menos a la t ontería.
     -- Konrad Adenauer.
     

    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 11:55
  • No entendí bien el codigo :-(

    Creo que con un ejemplo puedes entender mejor este asunto de los delegados y eventos.

    En este webcast, expongo de una manera sencilla (eso creo yo) un ejemplo del uso de delegados y eventos.

    Checalo y me avisas si te fue útil para entender el uso de los delegados y eventos.

    Saludos!!!

    http://jaimesanchez.com.mx/backtobasics2/PubData/Engine/Default.htm?http%3A%2F%2Fjaimesanchez.com.mx%2Fbacktobasics2%2FPubData%2F

     


    MSM-DotNet
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 21 de julio de 2010 21:08
    Moderador
  • hola

    los delegados permiten definir metodo anonimos o sea podrias crear funcionalidad sin especificar un nombre en concreto para este

    mira este ejemplo

    en el link se puede ver que usa

    SampleDelegate d2 = delegate(string message)
    {
        Console.WriteLine(message);
    };

    alli esta definiendo un delegado con codigo sin necesidad de definir un nombre de metodo, mientras que en d1 si hace uso de la declaracion del metodo del delegado

    aqui hay un ejemplo similar:

     

    ademas existe el concepto de multicast delegate

    con esto podrias por medio del nombre subscribirte al mismo e invocar varios de estos, veras como hace en un momento

    c = a + b;

    como veras es muy dinamico, podrias enlazar la llamada a varios metodo con uan sola invocacion

    sabiendo esto veras que es muy practico aplicarlos a eventos


    los eventos hacen uso del delegado para permitir que metodo que cumplan con la especificacion que define el delegado se subscriban y puedan ser lanzados sin generar una acoplamiento en el codigo

    no se si con esta explciacion queda ams claro el tema, se que no es simple de comrpender a simple vista, solo con la practica se llega a entenderlos, mas que nada si estudias patrones de diseños se ven mejor como se aplican

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    • Propuesto como respuesta davidDDR lunes, 12 de julio de 2010 5:51
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    sábado, 10 de julio de 2010 19:15
  • Hola.

    Yo tampoco comprendo muy bien esto de los delegados, lo estaba tomando asi como si de un hilo se tratara...

    El caso que me sucedio para poder usar un delegado aunque tampoco lo comprendo bien.
    Bueno, resulta que cree una DLL el cual tiene eventos, ahora para usar mi DLL en la aplicacion agrego una referencia y esta carga sus eventos. Ahora que ocurre en los eventos, al parecer no se ejecutan los codigos que tengo dentro del evento. Para que se llegue a ejecutar sin problema y pueda pasar los parametros tuve que crear delegados, solo de esta forma se ejecuta el codigo y las variables se guardan sin problema, sin mensionar que parece que es la unica forma de pasar los parametros de los eventos.

    Aun asi no comprendo muy bien sobre el tema de los delegados, solo se que asi funciona mi aplicacion.

    Ahora nose cual es la diferencia con los Hilos (Thread)
    Tanto los delegados como los hilos, segun capto es para trabajar en multiproceso...

    Espero se me aclare un poco mas, a medida que voy usando tanto delegados como Hilos...

    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    martes, 13 de julio de 2010 19:35
  • Muchas veces la teoría nos deja con la misma duda o incluso con más dudas que la duda original :-)

    Para ver si realmente comprendiste el uso de los delegados, trata de resolver el siguiente problema real:

    Suponte que tienes un formulario windows 1 (FM1) y un formulario windows 2 (FM2).

    FM1 tiene un Label y un botón de comandos. Al dar clic al botón, se muestra FM2.

    FM2 tiene un TextBox y un botón de comandos.

    Deseamos lo siguiente:

    Cuando el usuario escriba algún caracter en el TextBox del FM2 debemos escribirlo inmediatamente en el Label del FM1 (probablemente porque quisieramos validar).

    Cuando demos clic en el boton de FM2 el formulario FM2 debe cerrarse.

    Como lo resolverias? Utilizarias delegados?

    Saludos!!!


    MSM-DotNet
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    martes, 13 de julio de 2010 19:37
    Moderador
  • Mira este artículo, te muestra diferentes aplicaciónes de los delegados :

    http://www.codeproject.com/KB/cs/6ImportDelegatesAndEvents.aspx

    además es una muy buena introducción a los mismos.

     

    Saludos,

     


    Mauricio Atanache G. - MCP
    Bogotá - Colombia
    "Bienaventurados los Pesimistas. Por que hacen BACKUPS."
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    martes, 13 de julio de 2010 20:05
  • A ver.
     
    Tienes una clase normal y corriente que tiene un delegado que será  un hilo
    en algún momento.
     
    Todos los datos miembro de esa clase son "globales" en cuanto al delegad o:
    cualquier delegado que se esté ejecutando como un hilo podrá v er y cambiar
    esos datos, con el peligro de que tienes que sincronizarlos porque podr� �a
    ocurrir que a medio actualizar uno de esos datos, entre otro hilo y lo l ea
    (o lo modifique) a la vez.
     
    Luego, las variables locales al delegado son independientes de cada hilo .
    Si tenemos 3 hilos en ejecución a partir del mismo delegado, vDato  y
    vEntero son locales e independientes a cada hilo.
     
    Quizás te interese ver este webcast mío sobre hilos:
     
    Allí hablo de delegados y de hilos (y de más cosas). Cuanquier a que vaya a
    usar hilos debería, como poco, conocer todo lo que explico allí .
     
    On Tue, 13 Jul 2010 22:07:52 +0200, Paul P. <Garcia> wrote:
     

    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/

    Hola.

    Me ha quedado un poco mas claro sobre este tema, pero tengo algunas preguntontas.
    Como te mensionaba cree una DLL (sckServer) el cual tiene metodos, propiedades y eventos. Uno de los eventos es DataArrival el cual se dispara cuando nos llegan datos.
    El sock es sincrono, pero le creo un hilo. Por ejemplo en server.Receive esta dentro de un procedimiento hilo, debajo de Server.Receive esta lo que va a disparar el evento DataArrival.
    Por tanto en la aplicacion que hace referencia a mi DLL se muestra el evento DataArrival...
    Aqui es mi pregunta: Porque en mi aplicacion que hago referencia a mi dll en el evento DataArrival, tengo que ponerle un delegado, sino le pongo un delegado el parametro que tiene el evento DataArrival no se puede leer, es decir en la aplicacion:

        private  void  sckServer_DataArrival ( System. Net. IPEndPoint IDTerminal)
        {
            this . BeginInvoke ( new  mDelegado ( DelegarDatos),  new  object []  {
                Factorial,
                IDTerminal
            });
        }

    Si no lo hago de esta forma no puedo coger el parametro IDTerminal o darle un txtBody.Text = "hola", es mas no se ejecuta muy bien todo lo que le ponga en el evento DataArrival, todo tengo que transportarlo al procedimiento DelegarDatos, por ejemplo ahi le pongo el txtBody.Text = "hola"

    Otra preguntita:
    Cuando me llegan muchas consultas del mismo cliente en DataArrival el sckServer.GetData se me concatena, para resolver esto pense hacerlo de la siguiente forma (usando hilo) "Siguiendo el ejemplo de arriva solo metiendole lo siguiente"

        private  void  DelegarDatos ( string  A,  System. Net. IPEndPoint B)
        {
            vThd = new  Thread ( HSolicitud);
            vThd. Start ();
        }

    Ahora todo el proceso se lo paso a HSolicitud, para que de esta forma nome concatene, pero el efecto es el mismo...

    Una ultima pregunta:
    En los delegados se le pueden pasar parametros, como muestro en el ejemplo anterior (        this . BeginInvoke ( new  mDelegado ( DelegarDatos),  new  object []  { Factorial, IDTerminal) pero en los hilos como puedo crear un Procedimiento el cual tenga parametros y al iniciar el hilo pasarle los parametros. Si se fijan arriva en void DelegarDatos inicio un hilo pero su procedimiento no tiene parametros, lo hice de esa forma porque nose como pasarle un parametro en: vThd = new Thread(HSolicitud)

    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 13:41
  • A ver si me entero. Sigue debajo.
    >
    > Me ha quedado un poco mas claro sobre este tema, pero tengo algunas  
    > preguntontas.
    > Como te mensionaba cree una DLL (sckServer) el cual tiene metodos,  
    > propiedades y
    > eventos. Uno de los eventos es DataArrival el cual se dispara cuando n os  
    > llegan
    > datos.
    > El sock es sincrono, pero le creo un hilo. Por ejemplo en server.Recei ve  
    > esta
    > dentro de un procedimiento hilo, debajo de Server.Receive esta lo que  va  
    > a
    > disparar el evento DataArrival.
    > Por tanto en la aplicacion que hace referencia a mi DLL se muestra el   
    > evento
    > DataArrival...
    > Aqui es mi pregunta: Porque en mi aplicacion que hago referencia a mi   
    > dll en el
    > evento DataArrival, tengo que ponerle un delegado, sino le pongo un  
    > delegado el
    > parametro que tiene el evento DataArrival no se puede leer, es decir e n  
    > la
    > aplicacion:
    >
    > private void sckServer_DataArrival ( System. Net. IPEndPoint IDTermina l)
    > {
    > this . BeginInvoke ( new mDelegado ( DelegarDatos), new object [] {
    > Factorial,
    > IDTerminal
    > });
    > }
    >
    > Si no lo hago de esta forma no puedo coger el parametro IDTerminal o  
    > darle un
    > txtBody.Text = "hola", es mas no se ejecuta muy bien todo lo que le   
    > ponga en el
    > evento DataArrival, todo tengo que transportarlo al procedimiento  
    > DelegarDatos,
    > por ejemplo ahi le pongo el txtBody.Text = "hola"
    >
     
    Lo del socket lo veo correcto. Pero esa llamada a delegado se está
    ejecutando en el hilo del socket. Es decir, aunque el delegado pertenezc a
    a tu aplicación, se ejecuta en el contexto del llamante. Si ese del egado
    está accediendo a la UI de tu aplicación, no puedes ejecutarlo
    directamente. O bien pasas al hilo del server, el this de tu form e
    invocas el delegado mediante el Invoke de ese this o bien en tu delegado ,
    una vez ejecutado, vuelves a ejecutar otro delegado con el Invoke del Fo rm.
     > Otra preguntita:
    > Cuando me llegan muchas consultas del mismo cliente en DataArrival el   
    > sckServer.GetData
    > se me concatena, para resolver esto pense hacerlo de la siguiente form a  
    > (usando
    > hilo) "Siguiendo el ejemplo de arriva solo metiendole lo siguiente"
    >
    > private void DelegarDatos ( string A, System. Net. IPEndPoint B)
    > {
    > vThd = new Thread ( HSolicitud);
    > vThd. Start ();
    > }
    >
    > Ahora todo el proceso se lo paso a HSolicitud, para que de esta forma   
    > nome
    > concatene, pero el efecto es el mismo...
    >
     
    Más o menos es la forma correcta de hacerlo, pero puedes tener prob lemas
    de rendimiento si el servidor no es cañero y dependiendo de la velo cidad
    de entrada de los datos. Eso está resuelto en Win32 mediante una
    combinación de thread pool y overlappeds, pero no creo que funcione  con
    Interop...
     
    Necesitas un thread pool y usarlo desde DelegarDatos... O lo mismo usar
    delegados asíncronos:
     
    > Una ultima pregunta:
    > En los delegados se le pueden pasar parametros, como muestro en el  
    > ejemplo
    > anterior ( this . BeginInvoke ( new mDelegado ( DelegarDatos), new  
    > object [] {
    > Factorial, IDTerminal) pero en los hilos como puedo crear un  
    > Procedimiento el
    > cual tenga parametros y al iniciar el hilo pasarle los parametros. Si  se  
    > fijan
    > arriva en void DelegarDatos inicio un hilo pero su procedimiento no ti ene
    > parametros, lo hice de esa forma porque nose como pasarle un parametro   
    > en: vThd
    > = new Thread(HSolicitud)
     
    Pues creo que sí se pueden pasar parámetros, pero no me acuerd o bien
    porque llevo varios años que no uso C#... A ver si esto te ayunda:
     
    En caso de que no, hereda de Thread y añade variables miembro, que  asignas
    en el constructor personalizado que hayas creado o antes de llamar a
    Start()
     
    -- 
    Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
    ======================== =============== Hay algo que Dios ha hecho mal. A todo le puso límites menos a la t ontería.
     -- Konrad Adenauer.
     

    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 16:41

Todas las respuestas

  • hola

    los delegados permiten definir metodo anonimos o sea podrias crear funcionalidad sin especificar un nombre en concreto para este

    mira este ejemplo

    en el link se puede ver que usa

    SampleDelegate d2 = delegate(string message)
    {
        Console.WriteLine(message);
    };

    alli esta definiendo un delegado con codigo sin necesidad de definir un nombre de metodo, mientras que en d1 si hace uso de la declaracion del metodo del delegado

    aqui hay un ejemplo similar:

     

    ademas existe el concepto de multicast delegate

    con esto podrias por medio del nombre subscribirte al mismo e invocar varios de estos, veras como hace en un momento

    c = a + b;

    como veras es muy dinamico, podrias enlazar la llamada a varios metodo con uan sola invocacion

    sabiendo esto veras que es muy practico aplicarlos a eventos


    los eventos hacen uso del delegado para permitir que metodo que cumplan con la especificacion que define el delegado se subscriban y puedan ser lanzados sin generar una acoplamiento en el codigo

    no se si con esta explciacion queda ams claro el tema, se que no es simple de comrpender a simple vista, solo con la practica se llega a entenderlos, mas que nada si estudias patrones de diseños se ven mejor como se aplican

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina
    • Propuesto como respuesta davidDDR lunes, 12 de julio de 2010 5:51
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    sábado, 10 de julio de 2010 19:15
  • hola

    los delegados permiten definir metodo anonimos o sea podrias crear funcionalidad sin especificar un nombre en concreto para este

    mira este ejemplo

    en el link se puede ver que usa

    SampleDelegate d2 = delegate(string message)
    {
        Console.WriteLine(message);
    };

    alli esta definiendo un delegado con codigo sin necesidad de definir un nombre de metodo, mientras que en d1 si hace uso de la declaracion del metodo del delegado

    aqui hay un ejemplo similar:

     

    ademas existe el concepto de multicast delegate

    con esto podrias por medio del nombre subscribirte al mismo e invocar varios de estos, veras como hace en un momento

    c = a + b;

    como veras es muy dinamico, podrias enlazar la llamada a varios metodo con uan sola invocacion

    sabiendo esto veras que es muy practico aplicarlos a eventos


    los eventos hacen uso del delegado para permitir que metodo que cumplan con la especificacion que define el delegado se subscriban y puedan ser lanzados sin generar una acoplamiento en el codigo

    no se si con esta explciacion queda ams claro el tema, se que no es simple de comrpender a simple vista, solo con la practica se llega a entenderlos, mas que nada si estudias patrones de diseños se ven mejor como se aplican

    saludos


    Leandro Tuttini

    Blog
    Buenos Aires
    Argentina


    Hola Leandro muchas gracias por tu ayuda... Si logre comprender las cosas en lago pero lo que no capto es cuando realmente debo usarlos, es decir, casos del dia a dia que se me presenten como tu me dices seria con practica... Eso que me comentas de patrones de diseños a que se refiere como tal... Muchas gracias una vez mas..

    martes, 13 de julio de 2010 19:16
  • Hola.

    Yo tampoco comprendo muy bien esto de los delegados, lo estaba tomando asi como si de un hilo se tratara...

    El caso que me sucedio para poder usar un delegado aunque tampoco lo comprendo bien.
    Bueno, resulta que cree una DLL el cual tiene eventos, ahora para usar mi DLL en la aplicacion agrego una referencia y esta carga sus eventos. Ahora que ocurre en los eventos, al parecer no se ejecutan los codigos que tengo dentro del evento. Para que se llegue a ejecutar sin problema y pueda pasar los parametros tuve que crear delegados, solo de esta forma se ejecuta el codigo y las variables se guardan sin problema, sin mensionar que parece que es la unica forma de pasar los parametros de los eventos.

    Aun asi no comprendo muy bien sobre el tema de los delegados, solo se que asi funciona mi aplicacion.

    Ahora nose cual es la diferencia con los Hilos (Thread)
    Tanto los delegados como los hilos, segun capto es para trabajar en multiproceso...

    Espero se me aclare un poco mas, a medida que voy usando tanto delegados como Hilos...

    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    martes, 13 de julio de 2010 19:35
  • Muchas veces la teoría nos deja con la misma duda o incluso con más dudas que la duda original :-)

    Para ver si realmente comprendiste el uso de los delegados, trata de resolver el siguiente problema real:

    Suponte que tienes un formulario windows 1 (FM1) y un formulario windows 2 (FM2).

    FM1 tiene un Label y un botón de comandos. Al dar clic al botón, se muestra FM2.

    FM2 tiene un TextBox y un botón de comandos.

    Deseamos lo siguiente:

    Cuando el usuario escriba algún caracter en el TextBox del FM2 debemos escribirlo inmediatamente en el Label del FM1 (probablemente porque quisieramos validar).

    Cuando demos clic en el boton de FM2 el formulario FM2 debe cerrarse.

    Como lo resolverias? Utilizarias delegados?

    Saludos!!!


    MSM-DotNet
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    martes, 13 de julio de 2010 19:37
    Moderador
  • Mira este artículo, te muestra diferentes aplicaciónes de los delegados :

    http://www.codeproject.com/KB/cs/6ImportDelegatesAndEvents.aspx

    además es una muy buena introducción a los mismos.

     

    Saludos,

     


    Mauricio Atanache G. - MCP
    Bogotá - Colombia
    "Bienaventurados los Pesimistas. Por que hacen BACKUPS."
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:09
    martes, 13 de julio de 2010 20:05
  • Muchas veces la teoría nos deja con la misma duda o incluso con más dudas que la duda original :-)

    Para ver si realmente comprendiste el uso de los delegados, trata de resolver el siguiente problema real:

    Suponte que tienes un formulario windows 1 (FM1) y un formulario windows 2 (FM2).

    FM1 tiene un Label y un botón de comandos. Al dar clic al botón, se muestra FM2.

    FM2 tiene un TextBox y un botón de comandos.

    Deseamos lo siguiente:

    Cuando el usuario escriba algún caracter en el TextBox del FM2 debemos escribirlo inmediatamente en el Label del FM1 (probablemente porque quisieramos validar).

    Cuando demos clic en el boton de FM2 el formulario FM2 debe cerrarse.

    Como lo resolverias? Utilizarias delegados?

    Saludos!!!


    MSM-DotNet


    Hola.

    En este caso usaria delegados. Aun sin entender muy bien.

    No me acuerdo bien lo que esta en la MSDN sobre los delegados, pero cuando se trata de controles existe sincronizacion a nivel grafico como de codigo, es decir los 2 deben sincronizarse.
    En el caso de los label y los textbox debe sincronizarse tanto en la propiedad Textbox1.Text como en lo que nos va aparecer en el control y por tanto para resolver esto se debe usar delegados. De seguro me equivoco pero escribo esto para que alguien me pueda orientar.

    Ahora en los hilos lo que entiendo es algo asi:
    Es como una cola de solicitudes, es decir puedo crear varios procedimiento y como son hilos estos se ponen en cola, es decir si el sistema esta desocupado y el hilo se puede ejecutar se ejecutara hasta que el sistema este ocupado nuevamente. Estos hilos se ponen en cola hasta que se desocupen, tambien se ponen en pausa. Es lo que entiendo...

    Espero que alguien me aclare un poco mas, pero de los hilos creo entender un poco mas que los delegados, quizas no me este explicando muy bien en esto de los hilos.

    Ahora lo que quisiera saber es si las variables creada en el procedimiento que llama al hilo son los mismo o se crean otro nuevo con otros valores.
    Me explico, por ejemplo: digamos que el procedimiento que llama al hilo se llama MiHilo ahora en este procedimiento creo de inicio variables ejemplo

    void MiHilo()
    String vDato
    int32 vEntero
    vDato = gDatoGlobal

    Ahora como veran en el procedimiento vDato se almacena lo que contiene gDatoGlobal (gDatoGlobal es una variable de ambito publico)
    Ahora digamos que cuando creamos el hilo gDatoGlobal contenia "hola" por tanto vDato contendra "hola" pero que tal si todavia no se termino este hilo, y se creo otro hilo pero en este lapso de tiempo gDatoGlobal ya no contiene "hola" sino "adios"

    Mi pregunta es la siguiente: como nuevamente creamos un hilo, quisiera saber si el nuevo vDato es el mismo que el anterior, es decir los dos hilos contienen "adios" o en el anterior vDato contiene "hola" y el nuevo hilo con la variable vDato contiene "adios" ???

    Puede ser que no me este explicando bien, pero a mi lo que me sirve es que estos procedimientos sean muy aparte, porque lo que quiero es crear cola de solicitudes, ahora si las variables son las mismas cada vez que cree un hilo no me sirve.

    martes, 13 de julio de 2010 20:07
  • Entiendo que surjan dudas con los delegados y su funcionamiento, ya que
    son la evolución última de los callback o funciones de retroll amada. A ver
    si yo soy capaz de explicaros el concepto y los usos más comunes.

    Cuando hacéis doble clic sobre un evento en el listado de enventos  de
    Windows Forms, la función que se abre en el editor es un delegado.  Bueno,
    es un evento, que no es más que un delegado con un formato de par� �metros
    especial definido por el .NET.

    Por lo tanto ya tenemos un uso: si nos suscribimos con un delegado a un
    evento, estamos diciéndole a alguien que, cuando ocurra algo, nos l o
    notifique. Es como cuando vamos a la chica de recepción y le dec� �s: "si
    llama Pepito me lo pasas". La chica coge su lista de "avisar si" y te
    añade. Luego, cuando llame alguien, cogerá la lista de "avisar  si" y
    comprobará si el nombre de quien está llamando tiene algú n "delegado"
    suscrito, y si es así, "ejecutará" dicho delegado.

    Lo mismo ocurre con ese evento al que nos hemos suscrito: cuando se
    produzca la acción (por ejemplo el presionado de un botón) el  sistema
    cogerá su lista de delegados e irá llamando por orden a cada d elegado que
    se haya suscrito.

    Imaginad que tenéis un ordenador con Bluetooth y que queréis q ue vuestro
    programa se entere de cada vez que un elemento se intente parear. Pues
    vosotros instaláis un delegado en el sistema BT y cada vez que otro elemento intente conectarse, ese delegado se ejecutará, de manera q ue el
    código que hayas puesto ahí dentro tendrá que hacer alg� �n tipo de acción
    en respuesta.

    Otra aplicación es la del "delegado asíncrono", que viene a se r como
    decirle a la secretaria que te haga algo mientras tu haces otra cosa.
    Supón que cuando aprieten un botón en tu aplicación se te nga que
    pre-procesar un trabajo de impresión que va a llevar mucho tiempo.  Puedes
    hacerlo mediante un delegado (evento) normal, pero entonces tu aplicaci� �n
    se parará hasta que termine el proceso. Otra opción es crear u n hilo,
    pasar el trabajo ahí y que la aplicación siga en sus cosas has ta que el
    hilo termine. Y puedes usar un delegado asíncrono, que es una forma  rápida
    y lista para funcionar de lo del hilo. Antes de llamar al delegado te
    suscribes a su evento de finalización (otro delegado), y luego lo e jecutas
    asíncronamente. CUando dicho delegado termine, llamará al dele gado al cual
    te has suscrito para informarte de que ha terminado (la secretaria ya ha terminado). La ventaja es que tienes "infinitas" secretarias, porque
    podrás lanzar de nuevo el delegado asíncrono sin que el anteri or termine
    (y deberás llevar la cuenta). ¿Para qué avisar de que ha  terminado? Pues
    para permitir, por ejemplo, cerrar la aplicación, o permitir la edi ción de
    los datos que se estaban procesando...

    Y finalmente en .NET un hilo es la ejecución de un delegado de form a
    simultánea con el hilo principal de la aplicación. En Win32 un  hilo es una
    función ejecutándose de forma simultánea, y en .NET es lo  otro. Mismo
    concepto, diferente implementación.

    Un delegado es lo que en lenguaje técnico se conoce como "closure".  Un
    callback tradicional es un puntero a función: tu guardas dicha dire cción
    en tu lista interna y cada vez que necesites ejecutar dicha función , la
    llamas. En OO hay un problema con los "callback" de funciones miembro,
    porque tienes que almacenar tanto la dirección del método como  la clase a
    la que pertenece (el "this"). Eso es una closure: un this más un pu ntero a
    función. El puntero nos da la función a ejecutar, y el this qu é datos a
    usar (para entender bien esto deberíamos entender cómo funcion a el
    concepto de clase cuando está compilada, en tiempo de ejecució n y a bajo
    nivel).

    Un delegado es más que eso, porque aparte de ser un "this" y un pun tero a
    función, es una clase en sí con una serie de métodos. Y u n evento también.

    Existen delegados "monocast" y multicast. El primero sólo contiene  un
    "this" y un puntero, el segundo puede contener varios de ambos, como una especie de bolsa contenedora de delegados, que serán ejecutados tod os uno
    detrás de otro (a no ser que sean asíncronos) representando el  concepto de
    "vaciar la bolsa".

    On Sat, 10 Jul 2010 20:59:07 +0200, <AdyIr> wrote:

    Hola a todos como estan???

    Entiendo que los delegados se pueden definir como apuntadores que   apuntan valga
    la redundancia a algun metodo... Pero para que usar delegados en lugar    de usar
    los metodos directamente???

    De antemano muchisimas gracias por todo...

    --  Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
    ======================== =============== Cualquier tarea que vale la pena hacer, valía la pena hacerla ayer.  -- Lema de Grossman.


    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 11:29
  • A ver.
     
    Tienes una clase normal y corriente que tiene un delegado que será  un hilo
    en algún momento.
     
    Todos los datos miembro de esa clase son "globales" en cuanto al delegad o:
    cualquier delegado que se esté ejecutando como un hilo podrá v er y cambiar
    esos datos, con el peligro de que tienes que sincronizarlos porque podr� �a
    ocurrir que a medio actualizar uno de esos datos, entre otro hilo y lo l ea
    (o lo modifique) a la vez.
     
    Luego, las variables locales al delegado son independientes de cada hilo .
    Si tenemos 3 hilos en ejecución a partir del mismo delegado, vDato  y
    vEntero son locales e independientes a cada hilo.
     
    Quizás te interese ver este webcast mío sobre hilos:
     
    Allí hablo de delegados y de hilos (y de más cosas). Cuanquier a que vaya a
    usar hilos debería, como poco, conocer todo lo que explico allí .
     
    On Tue, 13 Jul 2010 22:07:52 +0200, Paul P. <Garcia> wrote:
     
    >> Muchas veces la teoría nos deja con la misma duda o incluso con  más  
    >> dudas que la duda original :-)
    >>
    >> Para ver si realmente comprendiste el uso de los delegados, trata de   
    >> resolver el siguiente problema real:
    >>
    >> Suponte que tienes un formulario windows 1 (FM1) y un formulario  
    >> windows 2 (FM2).
    >>
    >> FM1 tiene un Label y un botón de comandos. Al dar clic al bot� �n, se  
    >> muestra FM2.
    >>
    >> FM2 tiene un TextBox y un botón de comandos.
    >>
    >> Deseamos lo siguiente:
    >>
    >> Cuando el usuario escriba algún caracter en el TextBox del FM2 d ebemos  
    >> escribirlo inmediatamente en el Label del FM1 (probablemente porque  
    >> quisieramos validar).
    >>
    >> Cuando demos clic en el boton de FM2 el formulario FM2 debe cerrarse.
    >>
    >> Como lo resolverias? Utilizarias delegados?
    >>
    >> Saludos!!!
    >>
    >> --
    >> MSM-DotNet
    >
    >
    > Hola.
    >
    > En este caso usaria delegados. Aun sin entender muy bien.
    >
    > No me acuerdo bien lo que esta en la MSDN sobre los delegados, pero  
    > cuando se trata de controles existe sincronizacion a nivel grafico com o  
    > de codigo, es decir los 2 deben sincronizarse.
    > En el caso de los label y los textbox debe sincronizarse tanto en la  
    > propiedad Textbox1.Text como en lo que nos va aparecer en el control y   
    > por tanto para resolver esto se debe usar delegados. De seguro me  
    > equivoco pero escribo esto para que alguien me pueda orientar.
    >
    > Ahora en los hilos lo que entiendo es algo asi:
    > Es como una cola de solicitudes, es decir puedo crear varios  
    > procedimiento y como son hilos estos se ponen en cola, es decir si el   
    > sistema esta desocupado y el hilo se puede ejecutar se ejecutara hasta   
    > que el sistema este ocupado nuevamente. Estos hilos se ponen en cola  
    > hasta que se desocupen, tambien se ponen en pausa. Es lo que entiendo. ..
    >
    > Espero que alguien me aclare un poco mas, pero de los hilos creo  
    > entender un poco mas que los delegados, quizas no me este explicando m uy  
    > bien en esto de los hilos.
    >
    > Ahora lo que quisiera saber es si las variables creada en el  
    > procedimiento que llama al hilo son los mismo o se crean otro nuevo co n  
    > otros valores.
    > Me explico, por ejemplo: digamos que el procedimiento que llama al hil o  
    > se llama MiHilo ahora en este procedimiento creo de inicio variables  
    > ejemplo
    >
    > void MiHilo()
    > String vDato
    > int32 vEntero
    > vDato = gDatoGlobal
    >
    > Ahora como veran en el procedimiento vDato se almacena lo que contiene   
    > gDatoGlobal (gDatoGlobal es una variable de ambito publico)
    > Ahora digamos que cuando creamos el hilo gDatoGlobal contenia "hola" p or  
    > tanto vDato contendra "hola" pero que tal si todavia no se termino est e  
    > hilo, y se creo otro hilo pero en este lapso de tiempo gDatoGlobal ya  no  
    > contiene "hola" sino "adios"
    >
    > Mi pregunta es la siguiente: como nuevamente creamos un hilo, quisiera   
    > saber si el nuevo vDato es el mismo que el anterior, es decir los dos   
    > hilos contienen "adios" o en el anterior vDato contiene "hola" y el  
    > nuevo hilo con la variable vDato contiene "adios" ???
    >
    > Puede ser que no me este explicando bien, pero a mi lo que me sirve es   
    > que estos procedimientos sean muy aparte, porque lo que quiero es crea r  
    > cola de solicitudes, ahora si las variables son las mismas cada vez qu e  
    > cree un hilo no me sirve.
    >
     -- 
    Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
    ======================== =============== Hay algo que Dios ha hecho mal. A todo le puso límites menos a la t ontería.
     -- Konrad Adenauer.
     

    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 11:55
  • A ver.
     
    Tienes una clase normal y corriente que tiene un delegado que será  un hilo
    en algún momento.
     
    Todos los datos miembro de esa clase son "globales" en cuanto al delegad o:
    cualquier delegado que se esté ejecutando como un hilo podrá v er y cambiar
    esos datos, con el peligro de que tienes que sincronizarlos porque podr� �a
    ocurrir que a medio actualizar uno de esos datos, entre otro hilo y lo l ea
    (o lo modifique) a la vez.
     
    Luego, las variables locales al delegado son independientes de cada hilo .
    Si tenemos 3 hilos en ejecución a partir del mismo delegado, vDato  y
    vEntero son locales e independientes a cada hilo.
     
    Quizás te interese ver este webcast mío sobre hilos:
     
    Allí hablo de delegados y de hilos (y de más cosas). Cuanquier a que vaya a
    usar hilos debería, como poco, conocer todo lo que explico allí .
     
    On Tue, 13 Jul 2010 22:07:52 +0200, Paul P. <Garcia> wrote:
     

    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/

    Hola.

    Me ha quedado un poco mas claro sobre este tema, pero tengo algunas preguntontas.
    Como te mensionaba cree una DLL (sckServer) el cual tiene metodos, propiedades y eventos. Uno de los eventos es DataArrival el cual se dispara cuando nos llegan datos.
    El sock es sincrono, pero le creo un hilo. Por ejemplo en server.Receive esta dentro de un procedimiento hilo, debajo de Server.Receive esta lo que va a disparar el evento DataArrival.
    Por tanto en la aplicacion que hace referencia a mi DLL se muestra el evento DataArrival...
    Aqui es mi pregunta: Porque en mi aplicacion que hago referencia a mi dll en el evento DataArrival, tengo que ponerle un delegado, sino le pongo un delegado el parametro que tiene el evento DataArrival no se puede leer, es decir en la aplicacion:

        private  void  sckServer_DataArrival ( System. Net. IPEndPoint IDTerminal)
        {
            this . BeginInvoke ( new  mDelegado ( DelegarDatos),  new  object []  {
                Factorial,
                IDTerminal
            });
        }

    Si no lo hago de esta forma no puedo coger el parametro IDTerminal o darle un txtBody.Text = "hola", es mas no se ejecuta muy bien todo lo que le ponga en el evento DataArrival, todo tengo que transportarlo al procedimiento DelegarDatos, por ejemplo ahi le pongo el txtBody.Text = "hola"

    Otra preguntita:
    Cuando me llegan muchas consultas del mismo cliente en DataArrival el sckServer.GetData se me concatena, para resolver esto pense hacerlo de la siguiente forma (usando hilo) "Siguiendo el ejemplo de arriva solo metiendole lo siguiente"

        private  void  DelegarDatos ( string  A,  System. Net. IPEndPoint B)
        {
            vThd = new  Thread ( HSolicitud);
            vThd. Start ();
        }

    Ahora todo el proceso se lo paso a HSolicitud, para que de esta forma nome concatene, pero el efecto es el mismo...

    Una ultima pregunta:
    En los delegados se le pueden pasar parametros, como muestro en el ejemplo anterior (        this . BeginInvoke ( new  mDelegado ( DelegarDatos),  new  object []  { Factorial, IDTerminal) pero en los hilos como puedo crear un Procedimiento el cual tenga parametros y al iniciar el hilo pasarle los parametros. Si se fijan arriva en void DelegarDatos inicio un hilo pero su procedimiento no tiene parametros, lo hice de esa forma porque nose como pasarle un parametro en: vThd = new Thread(HSolicitud)

    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 13:41
  • A ver si me entero. Sigue debajo.
    >
    > Me ha quedado un poco mas claro sobre este tema, pero tengo algunas  
    > preguntontas.
    > Como te mensionaba cree una DLL (sckServer) el cual tiene metodos,  
    > propiedades y
    > eventos. Uno de los eventos es DataArrival el cual se dispara cuando n os  
    > llegan
    > datos.
    > El sock es sincrono, pero le creo un hilo. Por ejemplo en server.Recei ve  
    > esta
    > dentro de un procedimiento hilo, debajo de Server.Receive esta lo que  va  
    > a
    > disparar el evento DataArrival.
    > Por tanto en la aplicacion que hace referencia a mi DLL se muestra el   
    > evento
    > DataArrival...
    > Aqui es mi pregunta: Porque en mi aplicacion que hago referencia a mi   
    > dll en el
    > evento DataArrival, tengo que ponerle un delegado, sino le pongo un  
    > delegado el
    > parametro que tiene el evento DataArrival no se puede leer, es decir e n  
    > la
    > aplicacion:
    >
    > private void sckServer_DataArrival ( System. Net. IPEndPoint IDTermina l)
    > {
    > this . BeginInvoke ( new mDelegado ( DelegarDatos), new object [] {
    > Factorial,
    > IDTerminal
    > });
    > }
    >
    > Si no lo hago de esta forma no puedo coger el parametro IDTerminal o  
    > darle un
    > txtBody.Text = "hola", es mas no se ejecuta muy bien todo lo que le   
    > ponga en el
    > evento DataArrival, todo tengo que transportarlo al procedimiento  
    > DelegarDatos,
    > por ejemplo ahi le pongo el txtBody.Text = "hola"
    >
     
    Lo del socket lo veo correcto. Pero esa llamada a delegado se está
    ejecutando en el hilo del socket. Es decir, aunque el delegado pertenezc a
    a tu aplicación, se ejecuta en el contexto del llamante. Si ese del egado
    está accediendo a la UI de tu aplicación, no puedes ejecutarlo
    directamente. O bien pasas al hilo del server, el this de tu form e
    invocas el delegado mediante el Invoke de ese this o bien en tu delegado ,
    una vez ejecutado, vuelves a ejecutar otro delegado con el Invoke del Fo rm.
     > Otra preguntita:
    > Cuando me llegan muchas consultas del mismo cliente en DataArrival el   
    > sckServer.GetData
    > se me concatena, para resolver esto pense hacerlo de la siguiente form a  
    > (usando
    > hilo) "Siguiendo el ejemplo de arriva solo metiendole lo siguiente"
    >
    > private void DelegarDatos ( string A, System. Net. IPEndPoint B)
    > {
    > vThd = new Thread ( HSolicitud);
    > vThd. Start ();
    > }
    >
    > Ahora todo el proceso se lo paso a HSolicitud, para que de esta forma   
    > nome
    > concatene, pero el efecto es el mismo...
    >
     
    Más o menos es la forma correcta de hacerlo, pero puedes tener prob lemas
    de rendimiento si el servidor no es cañero y dependiendo de la velo cidad
    de entrada de los datos. Eso está resuelto en Win32 mediante una
    combinación de thread pool y overlappeds, pero no creo que funcione  con
    Interop...
     
    Necesitas un thread pool y usarlo desde DelegarDatos... O lo mismo usar
    delegados asíncronos:
     
    > Una ultima pregunta:
    > En los delegados se le pueden pasar parametros, como muestro en el  
    > ejemplo
    > anterior ( this . BeginInvoke ( new mDelegado ( DelegarDatos), new  
    > object [] {
    > Factorial, IDTerminal) pero en los hilos como puedo crear un  
    > Procedimiento el
    > cual tenga parametros y al iniciar el hilo pasarle los parametros. Si  se  
    > fijan
    > arriva en void DelegarDatos inicio un hilo pero su procedimiento no ti ene
    > parametros, lo hice de esa forma porque nose como pasarle un parametro   
    > en: vThd
    > = new Thread(HSolicitud)
     
    Pues creo que sí se pueden pasar parámetros, pero no me acuerd o bien
    porque llevo varios años que no uso C#... A ver si esto te ayunda:
     
    En caso de que no, hereda de Thread y añade variables miembro, que  asignas
    en el constructor personalizado que hayas creado o antes de llamar a
    Start()
     
    -- 
    Microsoft Visual C++ MVP => http://geeks.ms/blogs/rfog
    ======================== =============== Hay algo que Dios ha hecho mal. A todo le puso límites menos a la t ontería.
     -- Konrad Adenauer.
     

    MVP Visual C++ - Visita mi blog sobre desarrollo: http://geeks.ms/blogs/rfog/
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 14 de julio de 2010 16:41
  • Muchas veces la teoría nos deja con la misma duda o incluso con más dudas que la duda original :-)

    Para ver si realmente comprendiste el uso de los delegados, trata de resolver el siguiente problema real:

    Suponte que tienes un formulario windows 1 (FM1) y un formulario windows 2 (FM2).

    FM1 tiene un Label y un botón de comandos. Al dar clic al botón, se muestra FM2.

    FM2 tiene un TextBox y un botón de comandos.

    Deseamos lo siguiente:

    Cuando el usuario escriba algún caracter en el TextBox del FM2 debemos escribirlo inmediatamente en el Label del FM1 (probablemente porque quisieramos validar).

    Cuando demos clic en el boton de FM2 el formulario FM2 debe cerrarse.

    Como lo resolverias? Utilizarias delegados?

    Saludos!!!


    MSM-DotNet

    Hola amigo la verdad estoy perdida, agradezco full la ayuda de todos pero hay tantas ideas y cosas que ya me enredes mas…

    Yo usuaria para lo que comentas una interface, guiandome en un ejempo de post que publico Leandro hace mucho, seria algo asi…

    // Creo una interface

        class Interfaces

        {

            public interface IForm

            {

                void CambiarTextBox(string texto);

            }

        }

    Supongamos que tengo Form1 y Form2. Form1 sera el padre y Form2 el hijo…

    Implemento la interfaz en Form1

    public partial class Form1 : Form, Interfaces.IForm

        {

            public Form1()

            {

                InitializeComponent();

            }

            public void CambiarTextBox(string texto)

            {

                txtNombre.Text = texto;

            }

     

    Llamo al Formulario 2 indicandole que el uno sera el padre…

    private void btlForm2_Click(object sender, EventArgs e)

            {

                Form2 frm = new Form2();

                frm.Show(this);

            }   

     

    Y desde el formulario 2, hago lo siguiente que la verdad no lo entiendo del todo bien…

    private void btlPasarDatos_Click(object sender, EventArgs e)

            {

                Interfaces.IForm formInterface = this.Owner as Interfaces.IForm;

                if(formInterface != null)

                    formInterface.CambiarTextBox(txtNombre.Text);

            }

    Y automaticamente el valor del txtNombre del Form2 sera pasado al txtNombre del Form1…

    Ahora me podrias enseñar como hacer eso con delegados para ver si haciendo un ejemplo capto la idea… Es que la verdad ahora creo que entiendo menos que cuando hice la pregunta…

    De antemano muchisimas gracias…

    jueves, 15 de julio de 2010 15:54
  • No entendí bien el codigo :-(

    Creo que con un ejemplo puedes entender mejor este asunto de los delegados y eventos.

    En este webcast, expongo de una manera sencilla (eso creo yo) un ejemplo del uso de delegados y eventos.

    Checalo y me avisas si te fue útil para entender el uso de los delegados y eventos.

    Saludos!!!

    http://jaimesanchez.com.mx/backtobasics2/PubData/Engine/Default.htm?http%3A%2F%2Fjaimesanchez.com.mx%2Fbacktobasics2%2FPubData%2F

     


    MSM-DotNet
    • Marcado como respuesta AdyIr jueves, 22 de julio de 2010 20:10
    miércoles, 21 de julio de 2010 21:08
    Moderador
  • No entendí bien el codigo :-(

    Creo que con un ejemplo puedes entender mejor este asunto de los delegados y eventos.

    En este webcast, expongo de una manera sencilla (eso creo yo) un ejemplo del uso de delegados y eventos.

    Checalo y me avisas si te fue útil para entender el uso de los delegados y eventos.

    Saludos!!!

    http://jaimesanchez.com.mx/backtobasics2/PubData/Engine/Default.htm?http%3A%2F%2Fjaimesanchez.com.mx%2Fbacktobasics2%2FPubData%2F

     


    MSM-DotNet

    Hola que tal muchas Gracias... Dejame revisarlo a ver...
    miércoles, 21 de julio de 2010 21:15
  • No entendí bien el codigo :-(

    Creo que con un ejemplo puedes entender mejor este asunto de los delegados y eventos.

    En este webcast, expongo de una manera sencilla (eso creo yo) un ejemplo del uso de delegados y eventos.

    Checalo y me avisas si te fue útil para entender el uso de los delegados y eventos.

    Saludos!!!

    http://jaimesanchez.com.mx/backtobasics2/PubData/Engine/Default.htm?http%3A%2F%2Fjaimesanchez.com.mx%2Fbacktobasics2%2FPubData%2F

     


    MSM-DotNet

    Hola amigo ya vi el video completo, la verdad super util te felicito, en verdad aclare bastante... No me habia planteando eso de que cuando se desarrollan componentes, los metodos aun no estan creados... Tambien me gusto muchisimo lo del metodo recursvio, la verdad he usado recursividad en SQL Server pero no me habia puesto a pensar que seria util tambien en aplicacion de Visual Studio... Muchas gracias una vez mas 20 pts...
    jueves, 22 de julio de 2010 20:09