• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

How to update label from different form?

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

lil layzie

Registered
Joined
Aug 30, 2004
This is for Visual Studios 2005.

I was wondering how would I go about updating a label from another form's click event? Assuming the form is already loaded with the label that I wanted to be updated.

example:
form1 and form2 is loaded

form2 displays "1" in a label

clicking a button in form1 changes the number in form2 to "2"
 
I would use a seperate class which can be accessed by both forms. You could then set/get members and display them on both forms. However if you do this be aware of thread synchronisation, look up mutex's and atom functions.

Reason being say for example u has one thread (form) updating a value but half way through this the cpu jumps to the next thread which also tries to update/read the value. Then the cpu would go back to ur initial thread and complete the function meaning the value read/set by thread 2 is no longer correct.

Am I right in assuming this is in VB?
 
The easiest way to do this is to declare a form object (variable) that can be accessed from both forms (in common scope). For instance a static global object. Then you simply access that object (of that form's type) to interact with it. If said Label control is declared as public or shared (forget the VB keyword for that) then you can just access its properties such as Text directly otherwise you can create a public procedure or property inside of Form1 object that you will use to pass the new data to from your Form2's event handler.

Another way is by passing the Form1 object to the Form2 first. Of course the Form1 class must itself be accessible to the Form2 (be in the same scope). So after you have initialized Form1 and Form2 as MyForm1 and MyForm2 respectively, you call MyForm2.SetRelative(MyForm1) procedure which you'd create in Form2 object as Sub SetRelative(relative As Form1). MyForm1 parameter then can be assigned to a Form2's local object of type Form1 thus giving you access to its public or shared properties or methods.

BTW, no you don't have to worry about any thread synchronization nonsense, the CPU doesn't just jump out from behind the bushes to do stuff behind your back.
 
BTW, no you don't have to worry about any thread synchronization nonsense, the CPU doesn't just jump out from behind the bushes to do stuff behind your back.

??? What do u mean a CPU doesnt jump out from behind the bushes?!? Do u understand how a CPU works in regard to the threads etc?

You can use global variables but this would be very much frowned upon in industry, global variables are a quick fix if u havent a clue what ur doing. IMO if ur gonna learn to do something do it properly
 
Not to hijack the thread, and I don't mean to be rude but:
1) The guy is obviously new to programming. Baby steps.
2) WTF does threading have to do with his problem. I do indeed understand how the CPU works, question is do you understand how does the .NET framework work? The guy is not doing any multi-threaded coding here. See #1
3) Frowned upon in the industry? What industry? See #1. In order to solve any problem properly first you have to solve the problem period and understand how things might work. Then you can think up refinements.
 
Wow...

Here is the easy way to do it.

Code:
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
        Form1.Label1.Text = "Whatever"
End Sub

You just have to fully reference the label by including the name of the form it's on.
 
Threading and global objects. If those are easy ways i wouldnt want to try it the hard way :D
 
Not to hijack the thread, and I don't mean to be rude but:
1) The guy is obviously new to programming. Baby steps.
2) WTF does threading have to do with his problem. I do indeed understand how the CPU works, question is do you understand how does the .NET framework work? The guy is not doing any multi-threaded coding here. See #1
3) Frowned upon in the industry? What industry? See #1. In order to solve any problem properly first you have to solve the problem period and understand how things might work. Then you can think up refinements.


1) I agree with, maybe went a bit too advanced. I'm not used to VB the bulk of my programming is C/C++/C#, amongst others. Where u dont have the luxury of so much being done for u and therefore u would use a new thread when making a new form.

2) Whats .net got to do with it? He's not doing any remote calling or anything of the like so none of the .net classes will be needed. If you knew how the CPU works you would in fact understand that when using several threads unless u use ATOM functions then the cpu could jump to another process before completing it, therefore synchronising is needed where a value can be changed by more than one thread.

3) I thought would be pretty obvious. In the software implementation industry. I assume that most including myself do programming as we enjoy it but also to go into industry and earn money. Therefore learning stuff that cant be used is totally pointless (i.e. using globals). As a software engineer if I were to give to my boss some software with global variables all over the show he'd chuck it back at me and tell me to do it again.
 
1. Before talking anything else, please learn about Windows event handling. Please
2. .net is more than RPC
3. I hope you don't give any code to your boss or anyone else. If you do, please tell me the name of the program so I can avoid it.
 
Using C#... If you are opening a form to say make some settings, or open a window to enter some details, remember that a form is just a class.

Code:
public void OpenTheOtherWindow()
{
  MyForm MyNewForm = new MyForm();

  if(MyNewForm.ShowDialog() == DialogResult.OK)
  {
    this.nameTextBox.Text = MyNewForm.MyName;
  }
  MyNewForm.Close();
}

and in your second form -

Code:
public class Form2
{
  // add a textbox called nameTextBox in your IDE
  public string MyName
  {
    get
    {
      return this.nameTextBox.Text;
    }
  }
  }
  // add a method for your OK button by double clicking it in your IDE and -
  private void OKButton(object sender, EventArgs e)
  {
    this.DialogResult = DialogResult.OK;
    // (you may also wish to do a cancel button and set this same line in that one to DialogResult.Cancel...
  }
  // find your constructor
  public Form2()
  {
    // just to make sure!
    this.DialogResult = DialogResult.None;
  }
}

So here, you design your second form, add something that you can pull out of it (a public class) and only when it is specifically supposed to (by using the dialogResult property). Because you instantiate the class/form, it's gonna be there even after you 'close' the window by clicking ok. You programmatically destroy the Form2 after you've seen what happens.
 
Last edited:
Back