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.
Related
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.
I'm trying to create a user control in my code behind, and then respond to events in that control. Presumably because the control doesn't exist at compile time, Visual Studio can't compile the handler subroutine I created to catch my control's event. Importantly, I want to decide the type of control at runtime (which is why I'm not just hard-coding it).
[before going on, the controls work correctly, including events and event handlers when used in the 'normal' way of creating the controls in XAML. I want to create the control instances in code behind so I can avoid duplicating pages that are 99% identical]
This 'works' (but doesn't give me the flexibility I need):
Public WithEvents AnswerPanel As MyControls.ScrollerControl
... (and the initialisation in the New() sub):
AnswerPanel = New MyControls.ScrollerControl
ItemStack3.Children.Add(AnswerPanel)
AddHandler AnswerPanel.GuessMade, AddressOf CheckAnswer
... (this is the handler sub responding to a custom event in the ScrollerControl)
Public Sub CheckAnswer(answer As String) Handles AnswerPanel.GuessMade
With the code above everything works as I expect: the control is created at runtime and its event is handled correctly.
What I want to achieve is to be able to choose a different user control when I initialise my control (e.g. ScrollerControl2, ScrollerControl3, etc.) I can create the controls this way by changing the first line to:
Public WithEvents AnswerPanel As UserControl
But once that change is made I can no longer reference the custom event in my handler as (presumably) the compiler sees it as a generic UserControl, which doesn't include my custom GuessMade event. The compiler errors on the event name and tells me it doesn't exist.
I'm sure I'm doing something wrong here. I think it's a theory/concept issue rather than my code.
Am I on the right track or going about this in the wrong way?
If I am reading this right, you have a user control that fires an event and you want the parent page to catch that even? If so, you need to raise the event, which will cause the event to bubble to the the parent. IE:
Partial Class user_controls_myControl
Inherits System.Web.UI.UserControl
Public Event DataChange As EventHandler
End Class
This creates a control with a public event called DataChange. Now, if you look at the code in the parent page that instantiates the user control, you will see that it has an event called "OnDataChange". Just like an onCLick event, you can assign this a method in the parent page. Now, you just need to raise the event in the user control. This can be added in some event in the control, like a button click or radio button change event:
RaiseEvent DataChange(Me, New EventArgs)
This takes two objects, the sender and event arguments. Typically I pass ME, which is the user control. This is great because you can use reflection to get all the controls public properties. You can also use this to cast objects to your control type. I rarely pass event arguments but you certainly could.
I answered a similar question here: Handling events of usercontrols within listview
If this is not what you had in mind, let me know
EDIT: To add a user control dynamically and attach the event:
First, in the page that will be using the control, you will need to add a place holder:
<asp:PlaceHolder ID="placeholder1" runat="server"></asp:PlaceHolder>
as well as a reference to the user control at the head of the page (depending on how the page is setup, you may not need this. If you get a page directive error, remove it):
<%# Reference="" Control="~/user_controls/myControl.ascx"%>
In the parent page, you can then create a user control and add it to the place holder. You must declare the user control with events like this:
Private WithEvents myNewControl As New user_controls_myControl
then, in some method you can add it to the page like this:
Dim getPh As New PlaceHolder
'create an instance of the user control
newMyControl = CType(LoadControl("~/user_controls/myControl.ascx"), user_controls_myControl)
'get a handle on the place holder
getPh = me.placeHolder1
'add the user control to the place holder
getPh.Controls.Add(newMyControl)
Then, make sure you have event method:
Protected Sub myEvent(ByVal sender As Object, ByVal e As EventArgs) Handles myNewControl.DataChange
End Sub
So, if you added the RaiseEvent to the user control like I suggested earlier, this should work for you.
I have an answer to this now. As I suspected I was sort of thinking about the problem from the wrong angle.
In a nutshell I was trying to raise an event from my user controls, but I needed to be raising the events in the base class and calling that from my user controls.
So my base class (which my user controls inherit from), now contains the following:
Public Event GuessMade(answer As String)
Protected Sub RaiseGuessEvent(answer As String)
RaiseEvent GuessMade(answer)
End Sub
Then, in my user control(s), when I need to raise the event, I simply call the RaiseGuessEvent sub like this:
Me.RaiseGuessEvent(CurrentValue)
And additionally, I had to remove the event from my subclasses/user controls, of course.
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()
I am developing a Windows Forms application.
I have four forms which is inherited from Baseform in another project.
In all four forms I am using a label to show some transaction count based on network status. I have implemented a thread which gets the active form of application and setting up the text. The code works fine if application screen is active. If I minimize and open any other application, I am getting an null error exception.
How do I get the active form of an application?
Private Sub StartThread()
pollThread =New Thread(AddressOf PollfileStatus)
pollThread.IsBackground =True
running =True
pollThread.Start()
End Sub
Private Sub PollfileStatus()
While (running)
Try
For Each e As Control In Me.ActiveForm.Controls
If (e.Name = "pbStatus") Then
e.Invoke(New SetTextCallback(AddressOf Settext),
New Object() {e, 10})
End If
Next
Catch ex As Exception
Throw New ApplicationException(ex.Message)
End Try
Thread.Sleep(6000)
End While
End Sub
Understandably Me.ActiveForm is empty, since minimizing your form makes it inactive. You have two options:
Test if Me.ActiveForm is empty, and if so, do not update the label. This will effectively 'pause' label updates, until the user restores the window again.
Create a property on your class that contains your thread, to pass a reference of the form you have to update. This way the label on the given form will update even if it is not the active form. This might be a better option, it will update even if the form is inactive in the background, for example.
You should look into the Application.OpenForms shared property. It contains a collection of all forms in your application.
EDIT: Since you're working with .net 1.1 and don't have access to Application.OpenForms, here are some suggestions:
Implement your own shared class (module) that contains an ArrayList of forms. You could then create a base class inheriting from Form, handle the Load event to add the current form to the list of forms and the Closed event to remove it. Once you have that class, have all your real forms derive from it. BTW, it's (almost) how it is done in .Net 2.0.
Turn the problem around and have the working thread raise events when the values change that you can handle in each form to update it.
An old question, but I'd thought I'd offer a suggestion as well: you could implement a Public Shared CurrentForm As Form that you set in the Form.Activated event of a base form class all your forms inherit from. From the thread you could then use CurrentForm to access the desired form.
This is very easy like this in vb.net
Dim MYFormName As String = Me.Name.ToString
You have many solutions for this situation:
first of all you should consider checking if the current form is null before proceeding in any action.
second: if that condition passes, a good approach to store the last active form's reference.
This might work but I cannot test it right now.
For Each frm As Form In Application.OpenForms
If frm.ContainsFocus Then
Return frm
End If
Next
I have a windows form application that uses a Shared class to house all of the common objects for the application. The settings class has a collection of objects that do things periodically, and then there's something of interest, they need to alert the main form and have it update.
I'm currently doing this through Events on the objects, and when each object is created, I add an EventHandler to maps the event back to the form. However, I'm running into some trouble that suggests that these requests aren't always ending up on the main copy of my form. For example, my form has a notification tray icon, but when the form captures and event and attempts to display a bubble, no bubble appears. However, if I modify that code to make the icon visible (though it already is), and then display the bubble, a second icon appears and displays the bubble properly.
Has anybody run into this before? Is there a way that I can force all of my events to be captured by the single instance of the form, or is there a completely different way to handle this? I can post code samples if necessary, but I'm thinking it's a common threading problem.
MORE INFORMATION: I'm currently using Me.InvokeRequired in the event handler on my form, and it always returns FALSE in this case. Also, the second tray icon created when I make it visible from this form doesn't have a context menu on it, whereas the "real" icon does - does that clue anybody in?
I'm going to pull my hair out! This can't be that hard!
SOLUTION: Thanks to nobugz for the clue, and it lead me to the code I'm now using (which works beautifully, though I can't help thinking there's a better way to do this). I added a private boolean variable to the form called "IsPrimary", and added the following code to the form constructor:
Public Sub New()
If My.Application.OpenForms(0).Equals(Me) Then
Me.IsFirstForm = True
End If
End Sub
Once this variable is set and the constructor finishes, it heads right to the event handler, and I deal with it this way (CAVEAT: Since the form I'm looking for is the primary form for the application, My.Application.OpenForms(0) gets what I need. If I was looking for the first instance of a non-startup form, I'd have to iterate through until I found it):
Public Sub EventHandler()
If Not IsFirstForm Then
Dim f As Form1 = My.Application.OpenForms(0)
f.EventHandler()
Me.Close()
ElseIf InvokeRequired Then
Me.Invoke(New HandlerDelegate(AddressOf EventHandler))
Else
' Do your event handling code '
End If
End Sub
First, it checks to see if it's running on the correct form - if it's not, then call the right form. Then it checks to see if the thread is correct, and calls the UI thread if it's not. Then it runs the event code. I don't like that it's potentially three calls, but I can't think of another way to do it. It seems to work well, though it's a little cumbersome. If anybody has a better way to do it, I'd love to hear it!
Again, thanks for all the help - this was going to drive me nuts!
I think it is a threading problem too. Are you using Control.Invoke() in your event handler? .NET usually catches violations when you debug the app but there are cases it can't. NotifyIcon is one of them, there is no window handle to check thread affinity.
Edit after OP changed question:
A classic VB.NET trap is to reference a Form instance by its type name. Like Form1.NotifyIcon1.Something. That doesn't work as expected when you use threading. It will create a new instance of the Form1 class, not use the existing instance. That instance isn't visible (Show() was never called) and is otherwise dead as a doornail since it is running on thread that doesn't pump a message loop. Seeing a second icon appear is a dead give-away. So is getting InvokeRequired = False when you know you are using it from a thread.
You must use a reference to the existing form instance. If that is hard to come by (you usually pass "Me" as an argument to the class constructor), you can use Application.OpenForms:
Dim main As Form1 = CType(Application.OpenForms(0), Form1)
if (main.InvokeRequired)
' etc...
Use Control.InvokeRequired to determine if you're on the proper thread, then use Control.Invoke if you're not.
You should look at the documentation for the Invoke method on the Form. It will allow you to make the code that updates the form run on the thread that owns the form, (which it must do, Windows forms are not thread safe).
Something like
Private Delegate Sub UpdateStatusDelegate(ByVal newStatus as String)
Public sub UpdateStatus(ByVal newStatus as String)
If Me.InvokeRequired Then
Dim d As New UpdateStatusDelegate(AddressOf UpdateStatus)
Me.Invoke(d,new Object() {newStatus})
Else
'Update the form status
End If
If you provide some sample code I would be happy to provide a more tailored example.
Edit after OP said they are using InvokeRequired.
Before calling InvokeRequired, check that the form handle has been created, there is a HandleCreated property I belive. InvokeRequired always returns false if the control doesn't currently have a handle, this would then mean the code is not thread safe even though you have done the right thing to make it so. Update your question when you find out. Some sample code would be helpful too.
in c# it looks like this:
private EventHandler StatusHandler = new EventHandler(eventHandlerCode)
void eventHandlerCode(object sender, EventArgs e)
{
if (this.InvokeRequired)
{
this.Invoke(StatusHandler, sender, e);
}
else
{
//do work
}
}