Disparar un evento cualquiera

Entiendo.
Pero voy a ver si reporto a Microsoft que agreguen a la WishList una rutina
"RaiseEvent" o "PerformEvent" aunque sea para una futura version :)
De hecho me extraña mucho que no lo tengan. El PerformClick ya iba por esa
ruta.


Saludos

"Alberto Poblacion"
escribió en el mensaje news:

"Pedro" wrote in message
news:

or ejemplo, si

al evento Validated de un textbox tienes conectada una rutina como esta:
private void textBox1_Validated(object sender, EventArgs e) {
... }
puedes llamarla ejecutando textBox1_Validated(this,EventArgs.Empty);
con lo que la rutina se ejecutará igual que si se hubiese disparado el
evento.

El problema, he visto, es que si tengo otros handler previamente
asignados al validated esos no se ejecutan.

Efectivamente, como te decía, tienes que "... llamar directamente a
_LAS_ rutinas que estén conectadas al evento". Lo cual requiere que sepas
cuáles son, cosa que sólo ocurrirá si las has conectado tú mismo.
Si tienes un delegado ya conectado y quieres conocer todos los gestores
de eventos conectados al mismo, la cosa es complicadilla. No hay una
solución universal que valga para cualquier tipo de delegado, pero para
los casos más comunes, hay una solución a base de Reflexión que está
descrita en este hilo:

http://forums.msdn.microsoft.com/en...fa3ed1f2c4
Busca el "post" que está marcado como "answer", y sigue bajando en el
hilo para ver algunas advertencias acerca de las limitaciones de este
método.

Hola Pedro,

Si entendí bien lo que quieres, una forma de hacer lo que deseas, si no
quieres usar reflexión, podría ser con la ayuda de los métodos OnXXXX(..):

Ejemplo si estás en un form y quieres disparar el evento Enter de una clase
personalizada de textbox, créale en dicha clase una llamada pública
indirecta a su método OnEnter. Recuerda que no se puede llamar directamente
desde fuera porque los OnXXXX son 'protected'.

Digamos:

class mytextbox {...

public xPerformEnter ()
{
this.OnEnter(new EventArgs());
}
..
..
}
Esto te llamaría a todos los manejadores que tengas asignados un
mytextbox.Enter hasta el nivel de la clase. Solo faltaría llamar
explícitamente los que tengas en el form (sería raro si fuese más de uno si
lo hay).

Luego en el form llamas:

mytextbox1.xPerformEnter(); //los manejadores previos
this.mytextbox1_Enter(mytextbox1, new EventArgs()); //el que tenga asignado
en el form (si lo hay).

Por supuesto, lo ideal es que ya exista en el lenguaje incorporado un
PerformEvent() para esto.

Espero te sirva,

Saludos

Ricardo Passians



"Pedro" escribió en el mensaje
news:

Entiendo.
Pero voy a ver si reporto a Microsoft que agreguen a la WishList una
rutina "RaiseEvent" o "PerformEvent" aunque sea para una futura version :)
De hecho me extraña mucho que no lo tengan. El PerformClick ya iba por
esa ruta.


Saludos

"Alberto Poblacion"
escribió en el mensaje news:

"Pedro" wrote in message
news:

or ejemplo, si

al evento Validated de un textbox tienes conectada una rutina como
esta:
private void textBox1_Validated(object sender, EventArgs e) {
... }
puedes llamarla ejecutando textBox1_Validated(this,EventArgs.Empty);
con lo que la rutina se ejecutará igual que si se hubiese disparado el
evento.

El problema, he visto, es que si tengo otros handler previamente
asignados al validated esos no se ejecutan.

Efectivamente, como te decía, tienes que "... llamar directamente a
_LAS_ rutinas que estén conectadas al evento". Lo cual requiere que sepas
cuáles son, cosa que sólo ocurrirá si las has conectado tú mismo.
Si tienes un delegado ya conectado y quieres conocer todos los gestores
de eventos conectados al mismo, la cosa es complicadilla. No hay una
solución universal que valga para cualquier tipo de delegado, pero para
los casos más comunes, hay una solución a base de Reflexión que está
descrita en este hilo:

http://forums.msdn.microsoft.com/en...fa3ed1f2c4
Busca el "post" que está marcado como "answer", y sigue bajando en el
hilo para ver algunas advertencias acerca de las limitaciones de este
método.

No lo habia pensado pero viendolo bien me sirve para cuando lo necesite.

Gracias.


"Ricardo Passians" escribió en
el mensaje news:

Hola Pedro,

Si entendí bien lo que quieres, una forma de hacer lo que deseas, si no
quieres usar reflexión, podría ser con la ayuda de los métodos OnXXXX(..):

Ejemplo si estás en un form y quieres disparar el evento Enter de una
clase personalizada de textbox, créale en dicha clase una llamada pública
indirecta a su método OnEnter. Recuerda que no se puede llamar
directamente desde fuera porque los OnXXXX son 'protected'.

Digamos:

class mytextbox {...

public xPerformEnter ()
{
this.OnEnter(new EventArgs());
}
..
..
}
Esto te llamaría a todos los manejadores que tengas asignados un
mytextbox.Enter hasta el nivel de la clase. Solo faltaría llamar
explícitamente los que tengas en el form (sería raro si fuese más de uno
si lo hay).

Luego en el form llamas:

mytextbox1.xPerformEnter(); //los manejadores previos
this.mytextbox1_Enter(mytextbox1, new EventArgs()); //el que tenga
asignado en el form (si lo hay).

Por supuesto, lo ideal es que ya exista en el lenguaje incorporado un
PerformEvent() para esto.

Espero te sirva,

Saludos

Ricardo Passians



"Pedro" escribió en el mensaje
news:

Entiendo.
Pero voy a ver si reporto a Microsoft que agreguen a la WishList una
rutina "RaiseEvent" o "PerformEvent" aunque sea para una futura version
:)
De hecho me extraña mucho que no lo tengan. El PerformClick ya iba por
esa ruta.


Saludos

"Alberto Poblacion"
escribió en el mensaje news:

"Pedro" wrote in message
news:

or ejemplo, si

al evento Validated de un textbox tienes conectada una rutina como
esta:
private void textBox1_Validated(object sender, EventArgs e) {
... }
puedes llamarla ejecutando textBox1_Validated(this,EventArgs.Empty);
con lo que la rutina se ejecutará igual que si se hubiese disparado el
evento.

El problema, he visto, es que si tengo otros handler previamente
asignados al validated esos no se ejecutan.

Efectivamente, como te decía, tienes que "... llamar directamente a
_LAS_ rutinas que estén conectadas al evento". Lo cual requiere que
sepas cuáles son, cosa que sólo ocurrirá si las has conectado tú mismo.
Si tienes un delegado ya conectado y quieres conocer todos los
gestores de eventos conectados al mismo, la cosa es complicadilla. No
hay una solución universal que valga para cualquier tipo de delegado,
pero para los casos más comunes, hay una solución a base de Reflexión
que está descrita en este hilo:

http://forums.msdn.microsoft.com/en...fa3ed1f2c4
Busca el "post" que está marcado como "answer", y sigue bajando en el
hilo para ver algunas advertencias acerca de las limitaciones de este
método.

"Pedro" escribió en el mensaje de noticias
news:

Entiendo.
Pero voy a ver si reporto a Microsoft que agreguen a la WishList una
rutina "RaiseEvent" o "PerformEvent" aunque sea para una futura version :)
De hecho me extraña mucho que no lo tengan. El PerformClick ya iba por
esa ruta.

En mi opinión, hacer eso sería un terrible error de diseño. Vulneraría la
encapsulación. Si el diseñador de la clase no quiere que dispares el evento,
pues no puedes hacerlo y ya. Sus razones tendrán. Un RaiseEvent haría que
estas razones no importasen y entonces podrías violar los principios de
diseño de esa clase. La encapsulación, en todos los sentidos, tiene su razón
de ser. Si crees que haya una razón poderosa para que el evento que quieres
disparar se pueda hacer *desde afuera*, deberías sugerir que ese evento de
esa clase fuese accesible a través de algún método.

Bueno, mi opinión nada más. Ya saco mi nariz de la conversación.

Saludos,
FG.

No puedo estar de acuerdo con eso si existe ya un método del propio .NET
para PerformClick(), estarán violando ahí la encapsulación también?. Es
raro un lenguaje que no tenga algo como RaiseEvent().



"Fernando A. Gómez F." escribió en el mensaje
news:

"Pedro" escribió en el mensaje de noticias
news:

Entiendo.
Pero voy a ver si reporto a Microsoft que agreguen a la WishList una
rutina "RaiseEvent" o "PerformEvent" aunque sea para una futura version
:)
De hecho me extraña mucho que no lo tengan. El PerformClick ya iba por
esa ruta.

En mi opinión, hacer eso sería un terrible error de diseño. Vulneraría la
encapsulación. Si el diseñador de la clase no quiere que dispares el
evento, pues no puedes hacerlo y ya. Sus razones tendrán. Un RaiseEvent
haría que estas razones no importasen y entonces podrías violar los
principios de diseño de esa clase. La encapsulación, en todos los
sentidos, tiene su razón de ser. Si crees que haya una razón poderosa para
que el evento que quieres disparar se pueda hacer *desde afuera*, deberías
sugerir que ese evento de esa clase fuese accesible a través de algún
método.

Bueno, mi opinión nada más. Ya saco mi nariz de la conversación.

Saludos,
FG.