dcsimg
Results 1 to 17 of 17

Thread: Unload classes

  1. #1

    Thread Starter
    Member
    Join Date
    Nov 2016
    Posts
    46

    Unload classes

    Sorry for the novice question: is there a way to terminate all the classes in a project, for example with a "for each - next" cycle as with forms or controls of a form?

  2. #2
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,993

    Re: Unload classes

    Closing your application will release the classes. Otherwise, generally speaking, the answer is no. Any referenced object remains until its references are released. That means you will need to unload the classes manually setting them to Nothing, or unload any objects having references to those classes.

    Maybe you can explain more why you need this?
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  3. #3

    Thread Starter
    Member
    Join Date
    Nov 2016
    Posts
    46

    Re: Unload classes

    Of course: in my project I used a central error handler and obviously in case of error, after the error messages, program jump the execution in the "unload" of the main form that downloads all the other forms, saves various files and updates the register; however execution never reaches form_terminate, because of the classes that are still active. I hadn't realized this and I didn't understand why the execution ended with a vb6.exe crash message. So I had to put all the classes in the form_unload routine to nothing to avoid it. So I was wondering if there wasn't a smarter strategy for unloading the various active classes.

  4. #4
    PowerPoster
    Join Date
    Feb 2017
    Posts
    2,208

    Re: Unload classes

    Quote Originally Posted by fabel358 View Post
    however execution never reaches form_terminate, because of the classes that are still active.
    Normally it doesn't happen because of class objects loaded (by itself).

    Edited: look for references to the form object stored in variables.
    Last edited by Eduardo-; May 22nd, 2020 at 10:24 AM.

  5. #5
    VB-aholic & Lovin' It LaVolpe's Avatar
    Join Date
    Oct 2007
    Location
    Beside Waldo
    Posts
    18,993

    Re: Unload classes

    Quote Originally Posted by fabel358 View Post
    however execution never reaches form_terminate, because of the classes that are still active.
    Piggybacking on Eduardo's post... Exactly as he says. When a form closes, it destroys all hWnds it created and dereferences call classes it references. If any of those objects hold references to other things, they will release them when their terminate events occur. This cascading destruction may be interrupted if an unhandled error occurs or as Eduardo suggests, a line of code is inadvertently reloading the form.

    A form can get reloaded (after its unload/terminate events occur) if some other line of code references that form by name or any of its methods or public variables.

    Another thing that can prevent a class from unloading is circular references
    Last edited by LaVolpe; May 21st, 2020 at 04:28 PM.
    Insomnia is just a byproduct of, "It can't be done"

    Classics Enthusiast? Here's my 1969 Mustang Mach I Fastback. Her sister '67 Coupe has been adopted

    Newbie? Novice? Bored? Spend a few minutes browsing the FAQ section of the forum.
    Read the HitchHiker's Guide to Getting Help on the Forums.
    Here is the list of TAGs you can use to format your posts
    Here are VB6 Help Files online


    {Alpha Image Control} {Memory Leak FAQ} {Unicode Open/Save Dialog} {Resource Image Viewer/Extractor}
    {VB and DPI Tutorial} {Manifest Creator} {UserControl Button Template} {stdPicture Render Usage}

  6. #6
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,223

    Re: Unload classes

    Personally, I try very hard to manage my classes in such a way that they're de-referenced when I'm finished using them. I think of them a bit like open files. I'd never just leave various files open after I was finished with them. And, my thinking is the same for classes.

    I'll admit that classes can get more complex than files, particularly when a class has nested classes. However, the principle I'm trying to outline still holds.

    Also, you say that your code "never reaches form_terminate". We must realize that a form has both a COM/code (basically, a class) component and also a user-interface component. When you load a form, both the COM/code component is started (i.e., instantiated) and the user-interface component is loaded. However, when you unload a form, the user-interface component is unloaded, but the COM/code piece is not un-instantiated (i.e., dereferenced). The only way this can be accomplished is to set the form's object variable to Nothing. For instance, if we just have a Form1, and we're using the "pre-declared" Form1 object variable, then, in the Form_Unload, we could include the statement: Set Form1 = Nothing

    That would uninstantiate the the COM/code object as well as unload the UI component. And then, your Form_Terminate event would fire as the last gasp of that COM/code object before it was fully uninstantiated (even if your program isn't actually terminating). Also note that the Form_Unload (as well as Form_Load) events have more to do with the UI component, whereas Form_Initialize (and Form_Terminate) have more to do with the COM/code component.

    Maybe That'll Help,
    Elroy
    Last edited by Elroy; May 21st, 2020 at 07:03 PM.
    Any software I post in these forums written by me is provided AS IS without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that Ive been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a VB6 random code folder that is overflowing. Ive been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  7. #7

    Thread Starter
    Member
    Join Date
    Nov 2016
    Posts
    46

    Re: Unload classes

    My problem does not concern the "natural" end of the project evoked with classic "Exit" in "men", which passes by Form_terminate"; but when the end is caused by an error managed by a central error handler, which reported the error, despite jumping to the "Form_Unload" routine of the main form, then continues execution, when it has already done all the file closing procedures and updated the register. Therefore I am forced to use the "malicious" "END" instruction which crashes (obviously) vb6.exe in the exit, because the classes that are open have not been placed to "nothing". I solved it like this:

    Code:
      Call TerminateCls (CRC32, TipCommand, TipCommand2, AscmB, SprTrm, _
       clsReplace, WrdWrp, Add, cCase, cFs, Fso)
    
    Private Sub TerminateCls (ParamArray TCls () As Variant)
       Dim X As Long
          For X = LBound (TCls ()) To UBound (TCls ())
          Set TCls (X) = Nothing
       Next X
    End Sub
    So what I was wondering was if there wasn't an "automatic" way to find out what classes are open when an error occurs, just as you can do with the Forms or Controls collection using a "For - each" loop. But from your answers it seems not.

    While if the program ends naturally (with the closure via the "X" in the top right of the form or with "EXIT" in the drop-down menu), there is no need to download the classes that are closed automatically.

  8. #8
    Frenzied Member wqweto's Avatar
    Join Date
    May 2011
    Posts
    1,979

    Re: Unload classes

    > So what I was wondering was if there wasn't an "automatic" way to find out what classes are open when an error occurs

    Automatic - no. You have to do it manually.

    In each Class_Initialize and Class_Terminate you have to call logging procedures that will implement the bookkeeping of the instances like this.

    cheers,
    </wqw>

  9. #9

    Thread Starter
    Member
    Join Date
    Nov 2016
    Posts
    46

    Re: Unload classes

    Automatic - no. You have to do it manually.

    In each Class_Initialize and Class_Terminate you have to call logging procedures that will implement the bookkeeping of the instances like this.
    Just what I wasn't hoping for. Thanks for the contribution of all of you.

  10. #10
    PowerPoster Elroy's Avatar
    Join Date
    Jun 2014
    Location
    Near Nashville TN
    Posts
    6,223

    Re: Unload classes

    You know? This question keeps haunting me.

    It does seem that there has to be a list of instantiated objects somewhere. If I know of an instantiated object, I can get the reference count. However, getting a list of instantiated objects is another matter entirely.

    But, what's puzzling to me is that the IDE cleans this up without any problems. You can stop p-code from running in a variety of ways, and these instantiations always seem to get cleaned up perfectly. So, at least in the IDE, there's a list (or collection) somewhere.
    Any software I post in these forums written by me is provided AS IS without warranty of any kind, expressed or implied, and permission is hereby granted, free of charge and without restriction, to any person obtaining a copy. Please understand that Ive been programming since the mid-1970s and still have some of that code. My contemporary VB6 project is approaching 1,000 modules. In addition, I have a VB6 random code folder that is overflowing. Ive been at this long enough to truly not know with absolute certainty from whence every single line of my code has come, with much of it coming from programmers under my employ who signed intellectual property transfers. I have not deliberately attempted to remove any licenses and/or attributions from any software. If someone finds that I have inadvertently done so, I sincerely apologize, and, upon notice and reasonable proof, will re-attach those licenses and/or attributions. To all, peace and happiness.

  11. #11
    Frenzied Member
    Join Date
    Dec 2014
    Posts
    1,037

    Re: Unload classes

    if you need to use the "End" it means the termination procedure is not done correctly.
    it is very important, as mentioned by Elroy, to close/unload/terminate/release anything that you use in that class, and also in the right order.

    API/DLL that you "if" use in your classes can have a termination delay, sometimes a "sleep" method can help to avoid unloading too fast.
    using a timer, that unload each class one by one could be a solution, and of course in the right order.

    usually is like this

    Set classA = New classA
    Set classB = New classB
    Set classC = New classC

    Set classC = Nothing
    Set classB = Nothing
    Set classA = Nothing

    another thing:
    Code:
    Dim Classes(1 To 4) As Variant
    
    Private Sub Form_Load()
        Dim i&
    
        Set Classes(1) = New Class1
        Set Classes(2) = New Class2
        Set Classes(3) = New Class3
        Set Classes(4) = New Class4
    
        For i = LBound(Classes) To UBound(Classes)
            Set Classes(i) = Nothing
        Next i
    End Sub
    I did use this method when I did have 2 different classes, that depending on preferences it would load into a default variant (one was Direct2D the other GDI)
    but you can also do this in a array and with that u can unload all classes like that.
    the problem using this method, is that in IDE it will assume the Classes(1 to 4) are variants. but it works once compiled.

  12. #12
    PowerPoster
    Join Date
    Feb 2017
    Posts
    2,208

    Re: Unload classes

    Quote Originally Posted by Elroy View Post
    You know? This question keeps haunting me.

    It does seem that there has to be a list of instantiated objects somewhere. If I know of an instantiated object, I can get the reference count. However, getting a list of instantiated objects is another matter entirely.

    But, what's puzzling to me is that the IDE cleans this up without any problems. You can stop p-code from running in a variety of ways, and these instantiations always seem to get cleaned up perfectly. So, at least in the IDE, there's a list (or collection) somewhere.
    Suppose that you get the list, what would you do? The rule is that while there is a reference, the object don't have to be destroyed.

    Probably a list of where are the references for all the currently created objects accessible in the IDE UI would be useful for debugging purposes.

  13. #13

    Thread Starter
    Member
    Join Date
    Nov 2016
    Posts
    46

    Re: Unload classes

    Ok baka, I try to explain myself. Why do I use the "END" instruction?
    In my project I use a central error handler; when an unexpected error occurs, the execution jumps to the error manager, that after the messages, jumps to the "Form_Unload" of the central form; this, after executing all the instructions for downloading the files and updating the registry, closing all the forms that may be open and closing all the controls - including the timers, closing all the API/DLLs, closing all the classes (unfortunately without any "For - Each" automation as is possible for forms and controls) and everything in the right order, instead jumping to the "Fom_Terminate" routine, execution continues as if nothing had happened; but now all the forms are closed, the files closed, controls downloaded, timers disabled, classes downloaded... without an "end" instruction, many error messages would show and program, like a pinball ball, jumps from or to "central error handler" and finally crashes.
    If instead you close the program through the normal ways (without being closed by an error), everything is ok (and without downloading the classes still open).
    It's really frustrating!!
    Last edited by fabel358; May 27th, 2020 at 05:14 AM.

  14. #14
    Lively Member gilman's Avatar
    Join Date
    Jan 2017
    Location
    Bilbao
    Posts
    79

    Re: Unload classes

    Perhaps the problem is that there is a circular reference.
    You can see the behavior with this little sample:
    In the main form:
    Code:
    Option Explicit
    
    Private Sub Form_Load()
    
        Dim oParent As New ParentClass
        Dim oChild As New ChildClass
        
        Set oParent.Child = oChild
        Set oChild.Parent = oParent
        
        'now set oParent and oChild to nothing
        'usually you thing the objects will be destroyed
        'but there is a circular reference and they not will be destroyed
        Set oParent = Nothing
        Set oChild = Nothing
    End Sub
    
    
    Private Sub Form_Terminate()
        MsgBox "Destroying Form"
    End Sub
    
    Private Sub Form_Unload(Cancel As Integer)
        MsgBox "Unloading Form"
    End Sub
    the two classes:
    Code:
    'ParentClass
    Option Explicit
    
    Public Child As ChildClass
    
    Private Sub Class_Terminate()
        MsgBox "Destroying Parent object"
    End Sub
    Code:
    'ChildClass
    Option Explicit
    
    Public Parent As ParentClass
    
    Private Sub Class_Terminate()
        MsgBox "Destroying Child object"
    End Sub
    I think if your main form is involved in a circular reference it coudn't be destroyed and the aplication couldn' t be terminated.

  15. #15
    Frenzied Member
    Join Date
    Dec 2014
    Posts
    1,037

    Re: Unload classes

    I get it, but still, what kind of program is that with that many errors that you need to use "end" otherwise you will get so many error reports?
    I don't use error reports in my "main" programs, everything should work without any errors.


    also, it seems odd, you are saying you are using "end" to avoid your "central error handler" to fire, that for me seems like a solution in your case. just be happy with it or change your code.
    theres no magic coding that will fix "your" coding problems, you need to do it yourself, the problem is within your program, somewhere, something are doing bad or wrong and causing that many errors.

    errors should be trapped in a way you dont need to end your program.
    a fatal error, usually result in a total crash.

  16. #16
    PowerPoster techgnome's Avatar
    Join Date
    May 2002
    Posts
    32,796

    Re: Unload classes

    Name:  force_design_flaw.jpg
Views: 43
Size:  32.1 KB

    Seriously... sounds like there's a design flaw somewhere.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  17. #17

    Thread Starter
    Member
    Join Date
    Nov 2016
    Posts
    46

    Re: Unload classes

    We did not understand each other and we are off topic; my question was if there was an automatic way to download the classes: the answer is that there isn't. That's all. Sorry for the inconvenience...

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Featured


Click Here to Expand Forum to Full Width