Class_Terminate event in VB.NET version 1.


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: Class_Terminate event in VB.NET version 1.

  1. #1
    Mark Alexander Bertenshaw Guest

    Class_Terminate event in VB.NET version 1.


    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

  2. #2
    Cali LaFollett Guest

    Re: Class_Terminate event in VB.NET version 1.

    > 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



  3. #3
    Greg Gates Guest

    Re: Class_Terminate event in VB.NET version 1.


    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



  4. #4
    Mark Alexander Bertenshaw Guest

    Re: Class_Terminate event in VB.NET version 1.

    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



  5. #5
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Class_Terminate event in VB.NET version 1.

    "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!



  6. #6
    Mark Alexander Bertenshaw Guest

    Re: Class_Terminate event in VB.NET version 1.


    "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

  7. #7
    Zane Thomas [.NET MVP] Guest

    Re: Class_Terminate event in VB.NET version 1.

    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.

  8. #8
    Mark Alexander Bertenshaw Guest

    Re: Class_Terminate event in VB.NET version 1.


    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

  9. #9
    Zane Thomas [.NET MVP] Guest

    Re: Class_Terminate event in VB.NET version 1.

    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.

  10. #10
    Greg Gates Guest

    Re: Class_Terminate event in VB.NET version 1.


    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
    >
    >



  11. #11
    Mark Alexander Bertenshaw Guest

    Re: Class_Terminate event in VB.NET version 1.


    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

  12. #12
    Greg Gates Guest

    Re: Class_Terminate event in VB.NET version 1.


    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




  13. #13
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Class_Terminate event in VB.NET version 1.

    "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!



  14. #14
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Class_Terminate event in VB.NET version 1.

    "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!



  15. #15
    Zane Thomas [.NET MVP] Guest

    Re: Class_Terminate event in VB.NET version 1.

    "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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center