Class_Terminate event in VB.NET version 1.

[Mark Alexander Bertenshaw]

Hi -

Way back, when I was following the VB.NET group, there was a lot of fuss
about the lack of a Class_Terminate event in VB.NET Beta 1. I subsequently
lost patience with that group (and it seems that vb.net.discussion is still
as pointless as ever), and have left it lie. Has anything changed since
then? Can we now use be sure that a Terminate type event/method is automatically
called when our object is freed? I was programming a Net32API.dll wrapper
last night, and just love the fact that my Class_Terminate event calls NetApiBufferFree()
when the object is destroyed! That was exactly the kind of functionality
that was abstracted out for me in VB.

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Cali LaFollett]

> Has anything changed since then? ...

Mark,

No, the Terminate event is gone and there are no immediate plans that I am
aware of to bring it back. In order to provide a *way out* you need to
implement the IDisposable interface and allow the user of your object the
choice to clean it up. Typically, the standard is for the consumer to
Dispose on any object that contains this method as soon as the consumer is
finished with it. There are several articles in the MSDN regarding the
proper techniques to implement it.

Hope this helps?

Regards,

Cal

[Greg Gates]

Hi Mark:

My understanding is that a type that uses an unmanaged resource should be
written so that the resource is freed in the finalize method. Unfortunately
it is not possible to determine when the finalize method will be called so
it is also necessary for the type to implement the IDisposable interface.
The dispose method of the IDisposable interface should enable a deterministic
freeing of the unmanaged resource. The catch is that it is up to the client
to call the dispose method so if the client forgets you've got a memory leak
until the object is garbage collected and the finalize method is called.


An interesting point regarding the dispose method is that it does not remove
the object from the heap. It just frees the unmanaged resource. The garbage
collector is the only mechanism to remove objects from the heap.


thanks ,Greg



"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
>
>Hi -
>
>Way back, when I was following the VB.NET group, there was a lot of fuss
>about the lack of a Class_Terminate event in VB.NET Beta 1. I subsequently
>lost patience with that group (and it seems that vb.net.discussion is still
>as pointless as ever), and have left it lie. Has anything changed since
>then? Can we now use be sure that a Terminate type event/method is automatically
>called when our object is freed? I was programming a Net32API.dll wrapper
>last night, and just love the fact that my Class_Terminate event calls NetApiBufferFree()
>when the object is destroyed! That was exactly the kind of functionality
>that was abstracted out for me in VB.
>
>--
>Mark Alexander Bertenshaw
>Programmer/Analyst
>Chordiant Software, Inc.
>Brentford
>UK

[Mark Alexander Bertenshaw]

Cali / Greg -

Thanks for the replies. It looks as if nothing has changed - I was kind of
hoping there would be a proper solution for this by now. Maybe next year?

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Joe \Nuke Me Xemu\ Foster]

"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message <news:3c8966d5@10.1.10.29>...

> Cali / Greg -
>
> Thanks for the replies. It looks as if nothing has changed - I was kind of
> hoping there would be a proper solution for this by now. Maybe next year?

Every boy should have a dream.

Anyway, it's worse than you think. Since .NET is optimized for
impressive magazine benchmarks, objects that need to be finalized
will be the last to be cleaned up, since firing off the Finalize
events might slow down the GC. Also, "child" objects could be
finalized before "parent" objects, with interesting implications
for such things as database class wrappers and object persistence
frameworks.

I wonder if any restrictions exist on SuppressFinalize, such as
disallowing calls on arbitrary objects from any old piece of code.
(Who says "managed" code is necessarily "safe" code?) After all,
this whole scheme is brought to you by the clowns responsible for
Beta 1's "RequestFinalizeOnShutdown" and the need for it...

URL:http://msdn.microsoft.com/msdnmag/is...00/GCI/GCI.asp

--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Mark Alexander Bertenshaw]

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:
>"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote in message
<news:3c8966d5@10.1.10.29>...
>
>> Cali / Greg -
>>
>> Thanks for the replies. It looks as if nothing has changed - I was kind
of
>> hoping there would be a proper solution for this by now. Maybe next year?
>
>Every boy should have a dream.
>
>Anyway, it's worse than you think. Since .NET is optimized for
>impressive magazine benchmarks, objects that need to be finalized
>will be the last to be cleaned up, since firing off the Finalize
>events might slow down the GC. Also, "child" objects could be
>finalized before "parent" objects, with interesting implications
>for such things as database class wrappers and object persistence
>frameworks.
>
>I wonder if any restrictions exist on SuppressFinalize, such as
>disallowing calls on arbitrary objects from any old piece of code.
>(Who says "managed" code is necessarily "safe" code?) After all,
>this whole scheme is brought to you by the clowns responsible for
>Beta 1's "RequestFinalizeOnShutdown" and the need for it...
>
> URL:http://msdn.microsoft.com/msdnmag/is...00/GCI/GCI.asp

Hmmm. Just read it. The implications are somewhat alarming. The Garbage
Collector sounds like a chaotic system, a bit like riding your motorbike
on a set of rollers all turning at different speeds and directions.

Obvously MS think that the tradeoffs of reliability (perhaps I mean predictability
?) vs speed, speed is more important. You must program a **** of a lot of
exception handling, even if it is rarely needed, just in case the Garbage
collector burps. I suppose it is all well and good if programmers are a
**** of a lot more disciplined than in OldVB. Ill-disciplined programmers
(or just plain ignorant) are going to have a real hard time in this new world
order.

As for me? I think I just like good old-fashioned elegance!

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Zane Thomas [.NET MVP]]

On 11 Mar 2002 06:55:14 -0800, "Mark Alexander Bertenshaw"
<mark.bertenshaw@virgin.net> wrote:

> I think I just like good old-fashioned elegance!

Such as the garbage collectors which several decades of research in lisp
systems have produced?


--
When freedom is outlawed
only outlaws will be free.

[Mark Alexander Bertenshaw]

zane@mabry.com (Zane Thomas [.NET MVP]) wrote:
>On 11 Mar 2002 06:55:14 -0800, "Mark Alexander Bertenshaw"
><mark.bertenshaw@virgin.net> wrote:
>
>> I think I just like good old-fashioned elegance!
>
>Such as the garbage collectors which several decades of research in lisp
>systems have produced?

Zane -

Not specifically. But if they are elegant (and I have not looked into garbage
collection algorithms myself, so I won't pretend any such knowledge), then
- cool. When I was talking about "elegance", I was referring to the code
I was talking about at the top of the thread. The elegance in the implementation
I have written is that I don't have to tell the class to clear itself up.
Since I didn't have to tell it to initialise itself e.g. an Init() method,
it makes a nice symmetry that I don't have to tell it to clear up itself
(presumably the Dispose() method in the case of .NET).

I've just noticed that you're a .NET MVP now. A new title? I don't suppose
you know of a nice way to do the kind of thing I'm talking about?

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Zane Thomas [.NET MVP]]

On 11 Mar 2002 10:30:53 -0800, "Mark Alexander Bertenshaw"
<mark.bertenshaw@virgin.net> wrote:

>But if they are elegant (and I have not looked into garbage
>collection algorithms myself, so I won't pretend any such knowledge), then
>- cool.

They are. As I said there are *several* decades of research into garbage
collection algorithms. When I studied them in the early 80s there was
already a huge amount of accumulated research on a vast array of types of
collectors, and variations of types and subtypes, and so on.

>I've just noticed that you're a .NET MVP now. A new title? I don't suppose
>you know of a nice way to do the kind of thing I'm talking about?

If by "nice" you mean like VB6 the answer is simple: no.

However I have over the past year written *a whole lot* of code which uses
sockets and I simply haven't seen, in my experience, that there is a real
issue. If you create an object then at some time you lose the last
reference to it. My approach to handling this issue is to be carefull by
explicitly Disposing (or Closing) objects when the last reference is lost.
Of course that propagates to objects having references to other objects
needed disposal, something to keep in mind.

That does impose an additional burden on you as a programmer, or as the
user of a component which requires disposal. This is a new design-issue
for VB programmers and it comes as a shock to many. There are always
trade-offs when it comes to designing software and MS made some with .Net
- obviously not everyone agrees with those trade-offs and only the future
will tell whether MS prevails with its vision or not.

Personally I think they've done a great job. But part of that comes from
the fact that this time - for the first time in the history of VB - I
actually gained new capabilities which didn't come at a huge price in
terms of complexity and learning-curve as was the case with mfc-authored
and then atl-authored components. There are personal-perspectives
everywhere, we all have our a$$holes, my take on the situation is that MS
has created a really powerful programming environment for programmers
using vb.net and other languages. YMMV.



--
When freedom is outlawed
only outlaws will be free.

[Greg Gates]

Hi Mark:

Here is my understanding of the situation...

For a user of disposable objects, it's not as bad as you might think. It
is really only those objects that are backed by system resources (file handlers,
windows handles, graphics objects, bitmaps, database connections etc.) that
should be freed as soon as possible.

In the case of file handles or database connections we do have to remember
to call close.

In the case of windows handles there is often no work to be done if one is
using the class generated by the Windows Form Designer.

For example:
When a form is closed, the framework calls the Dispose method on each control
in the form controls collection. (Controls are added to the form controls
collection in the InitializeComponent method.)

Components that use unmanaged resources should be added to a field of type
System.ComponentModel.IContainer (given the name "components" by the auto-generated
code). The auto-generated Dispose method calls Dispose on components as well
as the form's base.

You may have noticed that when you add an an ImageList, code will be added
to InitializeComponent that adds the ImageList to the components container.
Given that Dispose is called when the form closes, and the Dispose method
calls components.Dispose, the ImageList resources will be freed.

So you can see that, in most cases, most of the work is done for you.

thanks, Greg


"Mark Alexander Bertenshaw" <mark.bertenshaw@virgin.net> wrote:
>Cali / Greg -
>
>Thanks for the replies. It looks as if nothing has changed - I was kind
of
>hoping there would be a proper solution for this by now. Maybe next year?
>
>--
>Mark Alexander Bertenshaw
>Programmer/Analyst
>Chordiant Software, Inc.
>Brentford
>UK
>
>

[Mark Alexander Bertenshaw]

Greg -

Thanks for the reply.

"Greg Gates" <ggates@capcollege.bc.ca> wrote:
>
>In the case of file handles or database connections we do have to remember
>to call close.

Yes, I think I will just have to live with that if I'm using VB.NET

>In the case of windows handles there is often no work to be done if one
is
>using the class generated by the Windows Form Designer.
>
>For example:
>When a form is closed, the framework calls the Dispose method on each control
>in the form controls collection. (Controls are added to the form controls
>collection in the InitializeComponent method.)

Question: Exactly how does a Component differ from a Class from a Control?

>Components that use unmanaged resources should be added to a field of type
>System.ComponentModel.IContainer (given the name "components" by the auto-generated
>code). The auto-generated Dispose method calls Dispose on components as
well
>as the form's base.

Interesting. When you say "auto-generated" do you mean auto-generated code,
or is this an internal delegation?

>You may have noticed that when you add an an ImageList, code will be added
>to InitializeComponent that adds the ImageList to the components container.

I'll have to look.

>Given that Dispose is called when the form closes, and the Dispose method
>calls components.Dispose, the ImageList resources will be freed.

>So you can see that, in most cases, most of the work is done for you.
>
>thanks, Greg
>
Thanks -

--
Mark Alexander Bertenshaw
Programmer/Analyst
Chordiant Software, Inc.
Brentford
UK

[Greg Gates]

Hi Mark:



>>When a form is closed, the framework calls the Dispose method on each control
>>in the form controls collection. (Controls are added to the form controls
>>collection in the InitializeComponent method.)
>
>Question: Exactly how does a Component differ from a Class from a Control?
>


A control is a class that has a visual representation (i.e. a TextBox).
A component is a class that implements the IComponent interface



>>Components that use unmanaged resources should be added to a field of type
>>System.ComponentModel.IContainer (given the name "components" by the auto-generated
>>code). The auto-generated Dispose method calls Dispose on components as
>well
>>as the form's base.
>
>Interesting. When you say "auto-generated" do you mean auto-generated code,
>or is this an internal delegation?


Auto-generated code. When you add a windows form using the Windows Form template
in VS.NET, you will see the auto-generated Dispose method.

thanks, Greg

[Joe \Nuke Me Xemu\ Foster]

"Zane Thomas [.NET MVP]" <zane@mabry.com> wrote in message <news:3c8de949.57748671@news.devx.com>...

> On 11 Mar 2002 06:55:14 -0800, "Mark Alexander Bertenshaw"
> <mark.bertenshaw@virgin.net> wrote:
>
> > I think I just like good old-fashioned elegance!
>
> Such as the garbage collectors which several decades of research in lisp
> systems have produced?

So is forcing object cleanup timing issues back onto the developer the
culmination of these several decades of research, or just what exactly
are you claiming here? Is this merely another non-sequitur, like what
you post in the microsoft.public groups?

URL:http://groups.google.com/groups?selm....microsoft.com

I notice you didn't come right out and claim that VB5 and VB6 do not
support multithreading. Why is that, exactly?

--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Joe \Nuke Me Xemu\ Foster]

"Zane Thomas [.NET MVP]" <zane@mabry.com> wrote in message <news:3c900054.63647093@news.devx.com>...

> On 11 Mar 2002 10:30:53 -0800, "Mark Alexander Bertenshaw"
> <mark.bertenshaw@virgin.net> wrote:
>
> >But if they are elegant (and I have not looked into garbage
> >collection algorithms myself, so I won't pretend any such knowledge), then
> >- cool.
>
> They are. As I said there are *several* decades of research into garbage
> collection algorithms. When I studied them in the early 80s there was
> already a huge amount of accumulated research on a vast array of types of
> collectors, and variations of types and subtypes, and so on.

So do you claim that .NET actually incorporates these innovations,
or what?

> Personally I think they've done a great job. But part of that comes from
> the fact that this time - for the first time in the history of VB - I
> actually gained new capabilities which didn't come at a huge price in
> terms of complexity and learning-curve as was the case with mfc-authored
> and then atl-authored components.

Fine, so VB.NOT may indeed be more productive than MSVC+ and MFC or
ATL. However, do you rarely fail to sneak in comparisons to MFC and
ATL because you have some reason to suspect that VB.NOT is actually
/less/ productive than Classic VB for developing bread-and-butter
business applications?

--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!

[Zane Thomas [.NET MVP]]

"Joe \"Nuke Me Xemu\" Foster" <joe@bftsi0.UUCP> wrote:

>> They are. As I said there are *several* decades of research into garbage
>> collection algorithms. When I studied them in the early 80s there was
>> already a huge amount of accumulated research on a vast array of types of
>> collectors, and variations of types and subtypes, and so on.
>
>So do you claim that .NET actually incorporates these innovations,
>or what?

..Net includes a garbage collector yes, I thought that was already obvious
to everyone.

>Fine, so VB.NOT may indeed be more productive than MSVC+ and MFC or
>ATL.

And, in my experience, vb.net is more productive than VB6 too - comparable
to c#.

>However, do you rarely fail to sneak in comparisons to MFC and
>ATL because you have some reason to suspect that VB.NOT is actually
>/less/ productive than Classic VB for developing bread-and-butter
>business applications?

Nope - that's the make-believe world you live in Joe.


--
When freedom is outlawed
only outlaws will be free.