I am seeing code like "Unload frmMain" where from what I can tell frmMain is the type/module name, and I don't think it could also be simultaneously a variable name of the "ObjFrmMain" sort. Nevertheless, this command does successfully induce the form in question to unload.
So is the data type being used as an alias for its single existing instance? Or maybe for all of its instances?
Does VB6 do similar things to data types other than those derived from Form?
Yes, VB6 has odd object behavior. It gives you some shortcuts for dealing with form objects.
Load frmMain
...will load a single instance of that form under that variable name. In fact:
frmMain.lblSomeLabel.Caption = "some caption"
... will load that instance. However:
frmMain.SomeStringMember = "some value"
... will not load the form object (meaning the window itself) but you can access these variables, so in essence, the name of the form is a global variable.
You can, however, create new instances:
Dim newForm As MyForm
Set newForm = New MyForm
newForm.Show vbModal
That will actually create a new instance of MyForm, load it and show it, so you can have multiple instances of one form.
Also beware of the oddness in the New keyword:
Dim newObject As New MyClass
Set newObject = Nothing
newObject.SomeStringProperty = "some value"
This works without an "Object Reference Not Set ..." error. When you declare a reference variable using the As New syntax, you can destroy the object by setting it to Nothing and then reference that variable again and it will create a new instance.
In fact that's what's really going on with the forms. There is an implicit:
Dim frmMain As New frmMain
Personally I prefer not to use the As New syntax because it's confusing and dangerous. It also has a performance penalty, vs. this:
Dim newObject As MyClass
Set newObject = New MyClass
... but you're stuck with it for the forms.
What's happening when you call Unload frmMain is that it unloads the window (and all the controls) so all the data in those are gone, but the object frmMain is still hanging around. Therefore even after you unload it, you can still access any member variables and properties. However, if anything references any control on the form, it will trigger an implicit Load frmMain. This is the source of a lot of subtle programming errors in VB6, especially when you're trying to shut down.
Yes, it's a special functionality in VB6 and earlier. I normally tried to avoid doing it, since I saw it more as a source of confusion rather than a help.
The following comment In Visual Basic 6.0 and earlier versions, a special default instance of each form is automatically created for you, and allows you to use the form's name to access this instance. is taken from this MSDN page: Working with Multiple Forms in Visual Basic .NET: Upgrading to .NET
Related
I have always been under the understanding that in VBA we are unable to pass variables to a userform upon its creation/initialization. However, I had placed an opening parenthesis after the object name and a tooltip came up suggesting that this may not necessarily be true (or more likely I am simply just misinterpreting it):
So out of curiosity I attempted to see if I could pass a variable to the userform using varg:
but to no surprise it didn't work.
So ultimately the question is what is the purpose of varg? To me it actually looks like it would be used for indexing multiple separate instances of the userform since it actually appears to be an argument for the property .Item() and not for the actual object itself, but the only way I've ever known to create multiple userform objects is by setting them to a variable, such as:
Dim uf1 As MyUserForm, uf2 as MyUserform
Set uf1 = New MyUserform
set uf2 = New Myuserform
Can userforms actually be serialized and indexed a different way that would make use of this varg variable?
Note: This is not a question about how to pass external variables to a Userform - I am aware of numerous ways to accomplish this after its initialization (by passing via a Public Property, Function, or Variable within the object's code module or even less preferably an external global/public variable in a standard module).
UserForm has a default property Controls. It returns an instance of Controls class.
The Controls class, in turn, has a default property Item(varg) As Object.
So With New udfVendorDrillDown(varg) is the same as With New udfVendorDrillDown.Controls.Item(varg), which is probably not what you hoped it was.
You still cannot pass arguments to UserForms constructors. Or any class constructors in fact.
I understand what the InitializeComponent() does in the background - it creates the form and all the controls that were added in the designer. However, what I have not found is WHEN you would add a Public Sub New() constructor to a form and what you would add to that versus the Load() sub.
I did find that this is a good place to put my BackColor and BackGroundColor settings since they are user-preference and stored in Settings. What else should I put in there? I have always used the Load() sub to do any work with controls. Examples: Adding handlers, loading comboboxes, setting DGV columns, loading DataTables) Should I be doing that in the New constructor? Does it make any difference?
The Load event is fired just before the form is displayed for the first time.
... but that might not be right away. It's possible — common, even, in certain environments — to create a form and have it available to code long before the form is ever shown on screen. The form might even never be shown on screen.
Take, for example, a settings form, where properties are defined in the class that map to user preference fields on the form. Someone might decide to build an application that looks directly at a known form object instance to read preferences, but if the user never goes to change anything that form might never display to the screen, and the Load event would never fire. That's just one example, and whether or not it's a good idea is another story; it's enough to know I've seen it happen in real code.
However, what I have not found is WHEN you would add a Public Sub
New() constructor to a form and what you would add to that versus the
Load() sub.
Here is an example to answer (the core?) question of yours. Suppose you have a Form to edit a product. Let's call it ProductEditForm. Your use case for this Form is to edit the values of an existing Product in your system. How would you tell this form what product to edit? By requiring the passing of a Product object when you instantiate the form. For example, in the code page of ProductEditForm:
Private _product As Product = Nothing
Public Sub New(ByVal p As Product)
' This call is required by the Windows Form Designer.
InitializeComponent()
' Add any initialization after the InitializeComponent() call.
_product = p
' Now, you can reference the values of passed-in product "p" via variable _product, anywhere in this Form.
End Sub
And you would instantiate ProductEditForm like this:
Dim p As New Product
p.ID = 1234
p.Name = "Widget"
p.Cost = "10.00"
p.SalePrice = "30.00"
Dim f As New ProductEditForm(p)
In this example, you are making good use of code in Sub New(). You could also, perhaps, assign the values to _product to TextBox controls, check values in _product to set colors or fonts, etc.
(Side note: this method of requiring a target object in the constructor completely avoids the way-too-common bad habit of some WinForms programmers to pass data between Forms via public form properties or global variables.)
If you're talking about Windows Forms, I've found that it's best to do your UI setup in Load rather than in the constructor (New), because sometimes if you do it in New then certain things won't be initialized yet and you'll run into null reference exceptions.
So lets say I have a form1 that opens on startup. Form1 contains a textbox named textbox1 and a button named button1. When I click button1 this is code that is called:
Class form1
Sub CapLetters () 'buttons click event
Dim myObj as new MyObject
MyObj.CapAllLetters
Textbox1.text = MyObj.GetThoseCapLetters
End sub
End class
Now, I know this is kinda dumb, but my main question is, since im creating a new object, the textbox1 will not be available in my object unless I specifically call it like:
Form1.textbox1.text
Is this good practice or is there a better way? Now in my program I have about 10 textbox and comboboxs I need my object to use. I know i could do something like this:
MyObj.CapAllLetters (textbox1.text)
But that doesn't seem like a good idea to pass that many values in a method.
I think I need a way for my object to gather all the info upon initating it?
Thoughts?
You basically seem to be asking whether it's OK to use the default instance of a form. The answer is yes. In recent versions of VB, each form that has a parameterless constructor also has a default instance, which is a single instance that can be accessed anywhere and at any time via the class name. This feature exists because it makes it easier for beginners to access forms from different places in a project without having to worry about passing references to forms around that project.
In the case of the startup form in a project, it is always the default instance of its type, assuming that you haven't disabled the application framework. That means that you can always access your startup form anywhere in your project using the default instance of its type.
Now, you'll find that experienced developers rarely use default instances. That's because they are never required and rarely add value if you know what you're doing. That means that you can always access your application's startup form is reasonable locations throughout your project without using the default instance.
A older application loads some forms using implicit instances:
form2.showdialog()
Sometime between VS2008 32-bit and VS2013 64-bit, the forms stopped being initialized when they are reloaded. For example, if you load a form, close the form (using the Close method), and load the form again, the classes and controls (and, I assume, the form) are not initialized as new instances.
Re-initialization can be accomplished by putting me.dispose() in the FormClosed event, or by using an explicit instance of the form:
Using frm As New Form2
frm.ShowDialog()
End Using
Is there a good reason to use one of these methods over the other, or is there another method that should be used to cause a form to be initialized when it is reloaded?
Dispose will be called automatically if the form is shown using the Show method. If another method such as ShowDialog is used (your case it is), or the form is never shown at all, you must call Dispose yourself within your application. You can also handle the dispose by moving it from the designer file into the code file and handle things there as well.
On the other hand, Using statement typically makes your application safer to maintain and less prone to deadlocks and other misbehavior related to the lifecycle of the resource. I would stick by using this approach.
Also you cant put Me.Dispose in the Form Closed event (possible issues). If your using ShowDialog it will fail as it will dispose your objects first, if you need them they are gone.
Here's more on dispose: https://msdn.microsoft.com/en-us/library/aw58wzka(v=vs.110).aspx
The Form object and its child controls are not automatically disposed when you display the form with ShowDialog(). That sounds pretty quirky but this was done for a very good reason. After ShowDialog returns DialogResult.OK, you are normally going to obtain the dialog results. What nobody likes is that failing because of a ObjectDisposedException. Which would be likely to occur since the dialog results are often stored in controls.
You should always use the Using statement to ensure the form object and all of its controls are disposed.
A possible corner case is intentionally not disposing it because you like the redisplay the dialog with the original entered values. Which is not completely wrong, it is however a very expensive way to preserve those values. Those undisposed window objects cost an arm and a leg in system resources.
Pretty clear explanation from MSDN
Unlike non-modal forms, the Close method is not called by the .NET
Framework when the user clicks the close form button of a dialog box
or sets the value of the DialogResult property. Instead the form is
hidden and can be shown again without creating a new instance of the
dialog box. Because a form displayed as a dialog box is hidden instead
of closed, you must call the Dispose method of the form when the form
is no longer needed by your application.
When ShowDialog() called and closed, instance of the form will remain in the memory, and can be used again, for example get a result from some public property.
If you not using anymore this form, you need to call Dispose method to dispose form and form's controls
Dim myform As New MyDialogForm()
myform.ShowDialog()
Dim result As Object = myForm.SelectedResult()
myform.Dispose() 'need to call manually, if instance not used anymore
When you use Using keyword then Dispose method will be executed automatically at the end of the Using block
Dim result As Object
Using myform As New MyDialogForm()
myform.ShowDialog()
result = myForm.SelectedResult()
End Using 'myform.Dispose will be called
Bottom line: Both methods doing a same things.
But Using block will call Dispose method automatically
P.S. Putting Me.Dispose in the FormClosed eventhandler then
- instance of the form will stay in the memory even form was closed
- and will work only until you tried using disposed controls again. If you will try to show disposed object then ObjectDisposedException will be thrown.
If you not using form anymore then Using block will be best method
I'm quite new to vb.net, and windows forms developement as a whole, so this might all be very basic, but here goes.
I would like to open a new form from some other form, and pass some selected object from a control on that form to the new form. The sensible way to do this, I thought, was as a parameter to the forms constructor. Now I know that the visual studio GUI creates partial classes for my forms, that hold the properties that I can drag onto there in the designer. I assume it also holds a default constructor. Since it might do all sorts of stuff that is needed to initialise the form, I figured I should call it from my custom constructor ala
public sub new(byval my_parameter as Foo)
Me.new()
Me.my_parameter = my_parameter
do_some_initialisation()
end sub
That clearly wasn't it, because it can't find a default constructor. The thing is, visual studio goes trough great lengths to prevent me from seeing the generated constructor, so I know how to access it. This leads me to believe that I am actually doing it wrong, and should have set out on some different path, as the path you are forced in to usually is the sensible thing to do, which I usualy find out way too late.
So how should I be doing something like this?
This is a fairly simple example.
This goes into your "main" form (the one you want to call your new form from):
Dim childForm1 As New form2Name(item)
childForm1.Text = "Title of your new form"
Call childForm1.Show()
form2Name(item) breaks up like "form2Name" is the name of the form you want to open and "item" is the parameter to be passed.
In your new form (form2Name) add this code:
Public Sub New(ByVal item As String)
InitializeComponent() ' This call is required by the Windows Form Designer.
MsgBox(item)
End Sub
You can do whatever else you need in your form.
Hope this helps.
For VB.Net I think the call you are after is
MyBase.New()
Your derived form class automatically inherits the default constructor for System.Windows.Forms.Form. This default constructor is invoked automatically before your derived constructor code executes. The reason you can't find any code for the default constructor is because the derived class does not specialize the default constructor. If you wish to define your own default constructor, you may. You can also define a constructor without parameters.
You code should work fine if you remove this line:
Me.New()