I'm using a DataGrid and have assigned

this.DataSourceChanged += new EventHandler( DataGrid_DataSourceChanged
);

This works fine but there is one case where it doesn't. How can I
check if DataSourceChanged has anything assigned. I can add it to the
watch because it says it needs to be on the left side of a -= or +=.

Thanks,
Brett

Unless you "own" the class publichsing the event, there is no robust
way of doing this. However, if you have subscribed to the event (and it
didn't error) then chances are that it worked fine and the
DataSourceChanged backer has (at least) 1 delegate.

Can you give any more details on the one case where it doesn't work? It
is more likely to be specific to your usage / expectations.

Marc

> Unless you "own" the class publichsing the event

What do you mean by own the class? I've created all the code involved.

The event isn't firing in the one case. I know because a breakpoint in
the delegated method is never hit in the one case. I'd like to give
details but it would require lots of explaining. If there is just a
way to check the invocation list for the one event, that would be a
good start.

Thanks,
Brett

I mean DataGrid, so no: you don't. And no there isn't.

You could always add a public method call that returned the delegate list to
the class the defines the event. You could then examine the delegates to see
if the one you think ought to be there really is.

public Delegate[] GetlList()
{
if ( YourEventNameHere != null )
return YourEventNameHere.GetInvocationList();
return new Delegate[0]; // empty list
}


"Brett Romero" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>> Unless you "own" the class publichsing the event
>
> What do you mean by own the class? I've created all the code involved.
>
> The event isn't firing in the one case. I know because a breakpoint in
> the delegated method is never hit in the one case. I'd like to give
> details but it would require lots of explaining. If there is just a
> way to check the invocation list for the one event, that would be a
> good start.
>
> Thanks,
> Brett
>

David Levine wrote:
> You could always add a public method call that returned the delegate list to
> the class the defines the event. You could then examine the delegates to see
> if the one you think ought to be there really is.
>
> public Delegate[] GetlList()
> {
> if ( YourEventNameHere != null )
> return YourEventNameHere.GetInvocationList();
> return new Delegate[0]; // empty list
> }

DataGrid.DataSourceChanged doesn't have a GetInvocationList().

Thanks,
Brett

You said that you wrote the event but I gather that is not the case.

If it's an event then either it has a GetInvocationList() method or they
defined their own backing store for the delegates. In either case it is only
directly accessible to the class that defines the event, not to subscribers
to the event. But you can use reflection to access those hidden fields. I
suggest using reflector to look at how the event was implemented. You may
able to use reflection to access the delegate list.

"Brett Romero" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> David Levine wrote:
>> You could always add a public method call that returned the delegate list
>> to
>> the class the defines the event. You could then examine the delegates to
>> see
>> if the one you think ought to be there really is.
>>
>> public Delegate[] GetlList()
>> {
>> if ( YourEventNameHere != null )
>> return YourEventNameHere.GetInvocationList();
>> return new Delegate[0]; // empty list
>> }
>
> DataGrid.DataSourceChanged doesn't have a GetInvocationList().
>
> Thanks,
> Brett
>

David Levine wrote:
> You said that you wrote the event but I gather that is not the case.
>
> If it's an event then either it has a GetInvocationList() method or they
> defined their own backing store for the delegates. In either case it is only
> directly accessible to the class that defines the event, not to subscribers
> to the event. But you can use reflection to access those hidden fields. I
> suggest using reflector to look at how the event was implemented. You may
> able to use reflection to access the delegate list.

I inherited DataGrid for my own DataGrid. DataSourceChanged is an
event that comes from the base (DataGrid). I only created a method in
my datagrid to delegate the event to. I didn't write the handler.

I've added the datagrid in question to my watches. I can see
InvocationList deep down inside the datagrid. However, the only thing
ever there is DoubleClick. So I still don't see a route to figure out
if the DataSourceChanged event is wired up according to the datagrid.

Thanks,
Brett

Let's try a different approach...you said previously that you subscribed to
the DataSourceChanged event. Check the invocation list of that event
immediately to ensure yourself that you did indeed subscribe to it. Now, why
would you think that at some point later it is not subscribed? Are you sure
that the conditions that should cause the event to get fired have actually
occurred?

"Brett Romero" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> David Levine wrote:
>> You said that you wrote the event but I gather that is not the case.
>>
>> If it's an event then either it has a GetInvocationList() method or they
>> defined their own backing store for the delegates. In either case it is
>> only
>> directly accessible to the class that defines the event, not to
>> subscribers
>> to the event. But you can use reflection to access those hidden fields. I
>> suggest using reflector to look at how the event was implemented. You may
>> able to use reflection to access the delegate list.
>
> I inherited DataGrid for my own DataGrid. DataSourceChanged is an
> event that comes from the base (DataGrid). I only created a method in
> my datagrid to delegate the event to. I didn't write the handler.
>
> I've added the datagrid in question to my watches. I can see
> InvocationList deep down inside the datagrid. However, the only thing
> ever there is DoubleClick. So I still don't see a route to figure out
> if the DataSourceChanged event is wired up according to the datagrid.
>
> Thanks,
> Brett
>

David Levine wrote:
> Let's try a different approach...you said previously that you subscribed to
> the DataSourceChanged event. Check the invocation list of that event
> immediately to ensure yourself that you did indeed subscribe to it. Now, why
> would you think that at some point later it is not subscribed? Are you sure
> that the conditions that should cause the event to get fired have actually
> occurred?

At the point I'm checking on the subscriber side, here is what I do:

MyDataGrid.DataSource = null;
MyDataGrid.DataSource = myDataTable;

I do that on purpose to make sure the source is not null and ensure
DataSourceChanged() has to fire. Inside of MyDataGrid, I override the
datasource and assign the value coming in to base.datasource. After
that assignment, DataSourceChanged() fires. It all works fine except
for this one condition on the above code. I have a breakpoint inside
of MyDataGrid.DataSourceChanged() method as well. I'll go through the
above code a few times and all works fine. Then I hit a point at which
it doesn't fire my breakpoint inside of DataSourceChanged. Hope that
helps more.

Now, how exactly do I get at InvocationList() for DataSourceChanged?
Where do I check that exactly? Are you saying at some place I break
and check MyDataGrid.InvocationList()? Because if you are, that method
doesn't exist there. It's buried down inside of base, base on the
watch list for my custom datagrid.

Thanks,
Brett