I know that I can use a With statement to make repeated references to a single object:
With myObj
.StringProperty = ""
.BooleanProperty = False
End With
However, what I want to know is: is there a shorthand for referring to the original object in the With statement? In the above example, can I refer to myObj without explicitly typing myObj as I'm already working with it.
No you can't, but it wouldn't mean much anyway. With just sets the default scope to the object expression that follows it. If you need a reference to the object this doesn't help unless the object is one of the very few that has a .Self property, which is quite rare.
I'm not sure what's expected for me to leave here, but basically, I've passed an object of type AwesomeMenu into an ActionControl object's (subclass of NSOBject) initializer class so that the ActionControl object has a reference to the AwesomeMenu. However, in one of the ActionControl functions, there is a call like
[self.menu updateButton];
Where self.menu is the AwesomeMenu and updateButton is a function within AwesomeMenu. For some reason, XCode never enters updateButton. I've tried setting up breakpoints inside updateButton. They don't ever trip. I tried stepping INTO updateButton (it just shows me the parameters and then it skips past the line without taking me into the function), etc. I don't get any errors either. My chosen path through the program takes me over that function call multiple times but it never actually calls.
What's happening?
I did not assign self.menu prior to calling one of its functions; self.menu's value was nil. I just had to switch my initialization statements around to get it to work.
Is it possible to have multiple constructors in vb6? The reason I'm asking is because I see the class initialize, but i don't know if I can stick in 0 or more parameters into a constructor or if class_initialize is the constructor and it can accept any number of parameters. Its confusing mainly because I am so familiar with c#, that going to vb6 is confounding as far as classes are concerned.
Class_Initialize is an event that gets always gets invoked as soon as an instance of the class is instantiated. It's not really comparable to a C# constructor.
For example, notice the Class_Initialize is created as Private, whereas a C# class with a private constructor cannot be instantiated.
While you can change a VB6 Class_Initialize event from Private to Public there wouldn't be much point: because the event is invoked on instantiation anyway, why would you want to call it explicitly a second time? (If you did, it would be better to have a public method that is called from the Class_Initialize event.)
You cannot add parameters to VB6 Class_Initialize event, not even Optional ones. Attempting to do so will cause a compile error.
The best you can do is to roll your own Initialize method, with parameter as required, which must be explicitly called, perhaps and have an internal flag isInitialized state variable to ensure the class is not used until the Initialize method has been invoked. Also consider a 'factory' approach: classes that are PublicNotCreatable with Friend Initialize methods invoked by the factory and served out to callers suitable initialized.
In VB6 you can specify method parameters as being optional. This means that you don't have to specify them when calling a function. In the case that they are not specified, a default value is given in the method signature.
An example from here:
Private Sub Draw(Optional X As Single = 720, Optional Y As Single = 2880)
Cls
Circle (X, Y), 700
End Sub
This can be called either:
Draw 'OR
Draw 100 'OR
Draw 200, 200
Edit
You can even use optional and regular parameters together, though I think you might have to put the optional ones at the end.
In a VB6 application, I have a Dictionary whose keys are Strings and values are instances of a custom class. If I call RemoveAll() on the Dictionary, will it first free the custom objects? Or do I explicitly need to do this myself?
Dim d as Scripting.Dictionary
d("a") = New clsCustom
d("b") = New clsCustom
' Are these two lines necessary?
Set d("a") = Nothing
Set d("b") = Nothing
d.RemoveAll
Yes, all objects in the Dictionary will be released after a call to RemoveAll(). From a performance (as in speed) standpoint I would say those lines setting the variables to Nothing are unnecessary, because the code has to first look them up based on the key names whereas RemoveAll() will enumerate and release everything in one loop.
RemoveAll will remove all the associations from the Dictionary: both the keys and values.
It would be a reference leak for the Dictionary to keep a reference to the values in the Dictionary.
If there are no other variables that reference the items in the collection then those objects should be handed to the Garbage Collector to be cleaned up the next time the GC is run.
If you, for example do this where sObj is a static variable somewhere then the when the GC is invoked next by the system, the first object will be cleaned up but the second which still is referenced by sObj will not.
d("a") = New clsCustom
d("b") = New clsCustom code.
sObj = d("b")
d.RemoveAll()
In one of my VB6 forms, I create several other Form objects and store them in member variables.
Private m_frm1 as MyForm
Private m_frm2 as MyForm
// Later...
Set m_frm1 = New MyForm
Set m_frm2 = New MyForm
I notice that I'm leaking memory whenever this (parent) form is created and destroyed. Is it necessary for me to assign these member variables to Nothing in Form_Unload()?
In general, when is that required?
SOLVED: This particular memory leak was fixed when I did an Unload on the forms in question, not when I set the form to Nothing. I managed to remove a few other memory leaks by explicitly setting some instances of Class Modules to Nothing, as well.
Actually, VB6 implements RAII just like C++ meaning that locally declared references automatically get set to Nothing at the end of a block. Similarly, it should automatically reset member class variables after executing Class_Terminate. However, there have been several reports that this is not done reliably. I don't remember any rigorous test but it has always been best practice to reset member variables manually.
#Matt Dillard - Did setting these to nothing fix your memory leak?
VB6 doesn't have a formal garbage collector, more along the lines of what #Konrad Rudolph said.
Actually calling unload on your forms seems to me to be the best way to ensure that the main form is cleaned up and that each subform cleans up their actions.
I tested this with a blank project and two blank forms.
Private Sub Form_Load()
Dim frm As Form2
Set frm = New Form2
frm.Show
Set frm = Nothing
End Sub
After running both forms are left visible. setting frm to nothing did well... nothing.
After settign frm to nothing, the only handle open to this form is via the reference.
Unload Forms(1)
Am I seeing the problem correctly?
Josh
Objects in VB have reference counting. This means that an object keeps a count of how many other object variables hold a reference to it. When there are no references to the object, the object is garbage collected (eventually). This process is part of the COM specification.
Usually, when a locally instantiated object goes out of scope (i.e. exits the sub), its reference count goes down by one, in other words the variable referencing the object is destroyed. So in most instances you won't need to explicitly set an object equal to Nothing on exiting a Sub.
In all other instances you must explicitly set an object variable to Nothing, in order to decrease its reference count (by one). Setting an object variable to Nothing, will not necessarily destroy the object, you must set ALL references to Nothing. This problem can become particularly acute with recursive data structures.
Another gotcha, is when using the New keyword in an object variable declaration. An object is only created on first use, not at the point where the New keyword is used. Using the New keyword in the declaration will re-create the object on first use every time its reference count goes to zero. So setting an object to Nothing may destroy it, but the object will automatically be recreated if referenced again. Ideally you should not declare using the New keyword, but by using the New operator which doesn't have this resurrection behaviour.
#Martin
VB6 had a "With/End With" statement that worked "like" the Using() statement in C#.NET. And of course, the less global things you have, the better for you.
With/End With does not working like the Using statement, it doesn't "Dispose" at the end of the statement.
With/End With works in VB 6 just like it does in VB.Net, it is basically a way to shortcut object properties/methods call. e.g.
With aCustomer
.FirstName = "John"
.LastName = "Smith"
End With
Strictly speaking never, but it gives the garbage collector a strong hint to clean things up.
As a rule: do it every time you're done with an object that you've created.
Setting a VB6 reference to Nothing, decreases the refecences count that VB has for that object. If and only if the count is zero, then the object will be destroyed.
Don't think that just because you set to Nothing it will be "garbage collected" like in .NET
VB6 uses a reference counter.
You are encouraged to set to "Nothing" instanciated objects that make referece to C/C++ code and stuff like that. It's been a long time since I touched VB6, but I remember setting files and resources to nothing.
In either case it won't hurt (if it was Nothing already), but that doesn't mean that the object will be destroyed.
VB6 had a "With/End With" statement that worked "like" the Using() statement in C#.NET. And of course, the less global things you have, the better for you.
Remember that, in either case, sometimes creating a large object is more expensive than keeping a reference alive and reusing it.
I had a problem similar to this a while back. I seem to think it would also prevent the app from closing, but it may be applicable here.
I pulled up the old code and it looks something like:
Dim y As Long
For y = 0 To Forms.Count -1
Unload Forms(x)
Next
It may be safer to Unload the m_frm1. and not just set it to nothing.
One important point that hasn't yet been mentioned here is that setting an object reference to Nothing will cause the object's destructor to run (Class_Terminate if the class was written in VB) if there are no other references to the object (reference count is zero).
In some cases, especially when using a RAII pattern, the termination code can execute code that can raise an error. I believe this is the case with some of the ADODB classes. Another example is a class that encapsulates file i/o - the code in Class_Terminate might attempt to flush and close the file if it's still open, which can raise an error.
So it's important to be aware that setting an object reference to Nothing can raise an error, and deal with it accordingly (exactly how will depend on your application - for example you might ignore such errors by inserting "On Error Resume Next" just before "Set ... = Nothing").