Hi,
Various custom controls in my WinForms application register for the
'Application.Idle' event on load, and unregister on dispose. To avoid memory
leaks, it's essential that I remember to unregister on dispose.
Before my application exits, I'd like to do an 'assert' to assure myself
that there are no cases in which I've forgotten to unregister. I was under
the impression that an event is nothing more than a collection of delegates.
I therefore tried:
Debug.Assert(Application.Idle.Count==0);
This doesn't compile, however, and begs the question: Given an event
object, how do I obtain the underlying delegate collection?
Dave 12 1630
What makes you think you need to do that?
You don't.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"The One We Call 'Dave'" <gh****@englewood.com> wrote in message
news:JY********************@giganews.com... Hi,
Various custom controls in my WinForms application register for the 'Application.Idle' event on load, and unregister on dispose. To avoid memory leaks, it's essential that I remember to unregister on dispose.
Before my application exits, I'd like to do an 'assert' to assure myself that there are no cases in which I've forgotten to unregister. I was under the impression that an event is nothing more than a collection of delegates. I therefore tried:
Debug.Assert(Application.Idle.Count==0);
This doesn't compile, however, and begs the question: Given an event object, how do I obtain the underlying delegate collection?
Dave
"The One We Call 'Dave'" <gh****@englewood.com> wrote in message
news:JY********************@giganews.com... Given an event object, how do I obtain the underlying delegate collection?
I think something along these lines:
// Number of subscribers to the event:
int n = Idle.GetInvocationList().Length;
- OR -
// Get at each subscriber:
System.Delegate[] DelegateList = Idle.GetInvocationList();
foreach (IdleDelegate Delegate in DelegateList) {
...
}
-- Alan
> "The One We Call 'Dave'" <gh****@englewood.com> wrote in message news:JY********************@giganews.com...
Given an event object, how do I obtain the underlying delegate collection? I think something along these lines:
// Number of subscribers to the event: int n = Idle.GetInvocationList().Length; - OR -
// Get at each subscriber: System.Delegate[] DelegateList = Idle.GetInvocationList(); foreach (IdleDelegate Delegate in DelegateList) { ... }
Both of those will result in compiler error "The event...can only appear
on the left hand side of += or -=";
This is a fun one and I'm experimenting with it right now.
Chris
> What makes you think you need to do that? You don't.
You most certainly do. 'Application.Idle' is a static event. If you fail
to unregister, the reference will be held in the event collection until the
Application terminates. This constitutes a memory leak. Just to confirm, I
looked up the event in MSDN and found this excerpt:
Because this is a static event, you must detach any event handlers
attached to this event in the ApplicationExit event. If you do not detach
these handlers, they will remain attached to the event and continue to
consume memory.
David
> Various custom controls in my WinForms application register for the 'Application.Idle' event on load, and unregister on dispose. To avoid memory leaks, it's essential that I remember to unregister on dispose.
If the control is disposed of while the app still runs, yes.
Before my application exits, I'd like to do an 'assert' to assure myself that there are no cases in which I've forgotten to unregister. I was under the impression that an event is nothing more than a collection of delegates. I therefore tried:
When your app exits, the Application.Idle event goes with it.
Application.Idle is 'just' WinForms' way of multiplexing the idle
proc. There should be no consequences of terminating an app with a
populated Application.Idle.
Debug.Assert(Application.Idle.Count==0);
This doesn't compile, however, and begs the question: Given an event object, how do I obtain the underlying delegate collection?
So far as I know (and I just yesterday found how far from
comprehensive my understanding of events is) you don't: the only
things you can do with another class's event is += and -= it.
--
<http://www.midnightbeach.com>
> I think something along these lines: // Number of subscribers to the event: int n = Idle.GetInvocationList().Length;
Thanks for the reply.
I had a similar thought, but I get the following compilation error:
Error 1 The event 'System.Windows.Forms.Application.Idle' can only appear on
the left hand side of += or -=
David
>> What makes you think you need to do that? You don't.
You most certainly do. 'Application.Idle' is a static event. If you fail to unregister, the reference will be held in the event collection until the Application terminates. This constitutes a memory leak. Just to confirm, I looked up the event in MSDN and found this excerpt:
Because this is a static event, you must detach any event handlers attached to this event in the ApplicationExit event. If you do not detach these handlers, they will remain attached to the event and continue to consume memory. David
Take a look at this Dave.
I just tested it and it's golden! http://tinyurl.com/ao252
> When your app exits, the Application.Idle event goes with it. Application.Idle is 'just' WinForms' way of multiplexing the idle proc. There should be no consequences of terminating an app with a populated Application.Idle.
Ah, now I see why Kevin made the comment that he did. I didn't express
myself clearly (sorry kevin).
I didn't mean to imply that there were negative consequences of terminating
the app with a bunch of Application.Idle callbacks in place. The only reason
I want to perform the assert is to confirm with myself that I'm not
forgetting to unregster these handlers.
My WinForms app will be active for weeks at a time. Many controls will be
created and subsequently disposed during that period. If I forget to
unregister these handlers, the effect of the memory leak will build up over
the lifetime of the application session. I thought that running an assert
just prior to exit would be a clever way to determine during the development
phase whether I was failing to clean up any of these handlers.
David
> Take a look at this Dave. I just tested it and it's golden!
http://tinyurl.com/ao252
Oh my! Well, I certainly wouldn't have guessed approach that on my own. :)
Thanks, I'll try it.
>> Take a look at this Dave. I just tested it and it's golden!
http://tinyurl.com/ao252
Oh my! Well, I certainly wouldn't have guessed approach that on my own. :) Thanks, I'll try it.
After screwing with this, trying to find an answer (before the googlin'),
this was definately where I was heading. My stuff was way uglier though.
That class I linked is a keeper methinks.
Dave,
I am curious why you want to do this before your application exits.
From a cleanup point of view, the app domain is going to be torn down,
meaning your objects are going to be collected. On top of that, your
process is going to disappear. Given that event handlers (methods on
objects) are not resources that need to be reclaimed at the risk of
something detrimental, it doesn't seem to be a big deal to me, at the time
your app shuts down.
The other concerns you have are valid, about your class/control
unsubscribing to the Idle event. However, your assertion is wrong, because
you assume that your classes are the only ones subscribing. What if there
are elements of the framework that subscribe, and are ok with doing so for
the lifetime of the app? What do you do then?
The best you can do is make sure your classes implement IDisposable, to
indicate that lifetime management needs to be a consideration when using the
class, and make sure to unsubscribe when done.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"The One We Call 'Dave'" <gh****@englewood.com> wrote in message
news:JY********************@giganews.com... Hi,
Various custom controls in my WinForms application register for the 'Application.Idle' event on load, and unregister on dispose. To avoid memory leaks, it's essential that I remember to unregister on dispose.
Before my application exits, I'd like to do an 'assert' to assure myself that there are no cases in which I've forgotten to unregister. I was under the impression that an event is nothing more than a collection of delegates. I therefore tried:
Debug.Assert(Application.Idle.Count==0);
This doesn't compile, however, and begs the question: Given an event object, how do I obtain the underlying delegate collection?
Dave
> Ah, now I see why Kevin made the comment that he did. I didn't express myself clearly (sorry kevin).
No need to apologize. I am well aware of my communication difficulties. I'm
sure it was as much my fault as yours!
In any case, I see you've straightened it out. All's well that ends well!
--
Kevin Spencer
Microsoft MVP
..Net Developer
You can lead a fish to a bicycle,
but it takes a very long time,
and the bicycle has to *want* to change.
"The One We Call 'Dave'" <gh****@englewood.com> wrote in message
news:48********************@giganews.com... When your app exits, the Application.Idle event goes with it. Application.Idle is 'just' WinForms' way of multiplexing the idle proc. There should be no consequences of terminating an app with a populated Application.Idle.
Ah, now I see why Kevin made the comment that he did. I didn't express myself clearly (sorry kevin).
I didn't mean to imply that there were negative consequences of terminating the app with a bunch of Application.Idle callbacks in place. The only reason I want to perform the assert is to confirm with myself that I'm not forgetting to unregster these handlers.
My WinForms app will be active for weeks at a time. Many controls will be created and subsequently disposed during that period. If I forget to unregister these handlers, the effect of the memory leak will build up over the lifetime of the application session. I thought that running an assert just prior to exit would be a clever way to determine during the development phase whether I was failing to clean up any of these handlers.
David This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Ian Richardson |
last post by:
I'm writing some code which does one thing when onreadystatechange
occurs, e.g.
handle.onreadystatechange = function() { blah(handle,other_params) };
....but sometimes I need to add another,...
|
by: Lore Leuneog |
last post by:
Hi.
You can add new delegates for an event with += and you can remove delegates
from an event by using: -= but is there a way (method) to list all delegates
added to one event???
Sincerely...
|
by: Ondrej Sevecek |
last post by:
Hello,
what is the difference between "event" and the only use of delegate? Why
one should note events with "event" keyword when the functionality seems the
same as with pure delegates?
When I...
|
by: Bob |
last post by:
C# newbie here.... studying about delegates and now events.
I just don't get the purpose of declaring events using the event keyword.
What does this do for me that can't be done using only...
|
by: Elder Hyde |
last post by:
Hey all,
A class of mine needs to tell the outside world when its buffer is not
empty. The problem is that C# seems to force you to put the
event-raising code in the base class. To illustrate,...
|
by: Chua Wen Ching |
last post by:
Hi there,
I just read Chris Sells's article at
http://www.codeproject.com/csharp/delegate_bedtime.asp?df=100&forumid=2983&select=922269#xx922269xx
I wonder i can do this:
1)
I want to...
|
by: MuZZy |
last post by:
Hi,
Is there a way to remove all event handlers for a control's event? Say, i have a button and i want
to remove all button.Click events for it - i don't know how many of them was hooked to the...
|
by: Codemonkey |
last post by:
Heya All,
Sorry, but I think it's about time for a monkey-ramble.
I've just had enough of trying to serialize even simple objects with VB. A
simple task you may think - stick the...
|
by: AliRezaGoogle |
last post by:
Hi,
I have a conceptual question on Events and Multicast Delegates. Let me
explain:
As we know an event is a multicast delegate. What we declare as an
event is inherently a multicast delegate....
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| | |