public partial class frmMain : Form
{
public frmMain()
{
InitializeComponent();
}
private void frmMain_Load(object sender, EventArgs e)
{
RichTextBoxWordWrap.Test(rtbConsole);
Write("Console", "Welcome!");
}
//This is the void I need to call, I can't make it static because of the TextBox..
public void Write(string User, string Text)
{
rtbConsole.SelectionColor = Color.Black;
rtbConsole.SelectedText = "Test";
}
}
public partial class frmSettings : Form
{
public frmSettings()
{
InitializeComponent();
}
//This is how I would like to be able to call it in any class.
private void frmSettings_Load(object sender, EventArgs e)
{
frmMain.Write("Settings", "Saved");
}
}
10 Replies - 816 Views - Last Post: 13 September 2012 - 10:25 PM
#1
Calling a Void That Edits a TextBox From Another Class
Posted 24 August 2012 - 01:03 PM
I know this has been asked millions of times and I apologize, I have been looking for a week and can't find a viable solution. Basically I have a TextBox in my main form and in that forms code I have a void called write which outputs to the TextBox. I am trying to figure out how I can call this void from any class in my program. Here is an example.
Replies To: Calling a Void That Edits a TextBox From Another Class
#2
Re: Calling a Void That Edits a TextBox From Another Class
Posted 24 August 2012 - 01:11 PM
#3
Re: Calling a Void That Edits a TextBox From Another Class
Posted 24 August 2012 - 01:16 PM
It's all about object and scope. You need to have the instantiated object of "frmMain" so you can call that method.
Ideally it would be something like:
.. just like any other object you would use.
I am guessing your form automatically comes up with the app is ran? If that's the case you may want to think about putting that public method in it's own utility class... and call it that way.
Ideally it would be something like:
frmMain foo = new frmMain();
foo.Write("user", "stuff");
.. just like any other object you would use.
I am guessing your form automatically comes up with the app is ran? If that's the case you may want to think about putting that public method in it's own utility class... and call it that way.
#4
Re: Calling a Void That Edits a TextBox From Another Class
Posted 24 August 2012 - 01:20 PM
modi123_1, on 24 August 2012 - 02:16 PM, said:
It's all about object and scope. You need to have the instantiated object of "frmMain" so you can call that method.
Ideally it would be something like:
.. just like any other object you would use.
I am guessing your form automatically comes up with the app is ran? If that's the case you may want to think about putting that public method in it's own utility class... and call it that way.
Ideally it would be something like:
frmMain foo = new frmMain();
foo.Write("user", "stuff");
.. just like any other object you would use.
I am guessing your form automatically comes up with the app is ran? If that's the case you may want to think about putting that public method in it's own utility class... and call it that way.
I have looked into putting it in a seperate class and would like to but am still having problem referencing the TextBox.
And to clear things up frmMain is always open and frmSettings is opened above it with a button click.
#6
Re: Calling a Void That Edits a TextBox From Another Class
Posted 24 August 2012 - 01:58 PM
I just picked the first one that popped up in the C# Tutorials section.
#7
Re: Calling a Void That Edits a TextBox From Another Class
Posted 24 August 2012 - 03:29 PM
How do I?
Q: ...get Form 'A' to make a change or talk to Form 'B'
NOTE: Don't try to access GUI controls across forms. Its wrong. Nobody will hire you if you do this sort of crap. It violates every guideline for 'black box' programming, Separation of Responsibility, loose binding of components, and event driven programming. Read the tutorials and learn to do it right the first time so you don't develop bad habits that you just have to un-learn later.
A:
Q: ...get Form 'A' to make a change or talk to Form 'B'
NOTE: Don't try to access GUI controls across forms. Its wrong. Nobody will hire you if you do this sort of crap. It violates every guideline for 'black box' programming, Separation of Responsibility, loose binding of components, and event driven programming. Read the tutorials and learn to do it right the first time so you don't develop bad habits that you just have to un-learn later.
A:
- See this thread for the simplest of example code between two forms.
The tutorials below actually teach and explain it further. - Passing values between forms/classes
- Bulding an application - Part 1
- Building an application - Part 2
- Quick and easy custom events
- Delegates, Lambdas and Events
- http://www.codeproje...g-Windows-Forms
#8
Re: Calling a Void That Edits a TextBox From Another Class
Posted 27 August 2012 - 06:06 AM
This is driving me insane, I figured I could use a get set variable but I still can't figure out how to have a globally avaliable item that can still modify local form controls
#9
Re: Calling a Void That Edits a TextBox From Another Class
Posted 27 August 2012 - 07:29 AM
We've already told you that's the wrong approach. Read the links we've provided to learn how to do it right.
#10
Re: Calling a Void That Edits a TextBox From Another Class
Posted 13 September 2012 - 05:55 PM
Been trying to get this again, I can get it to work but I would like to have a class that handles everything that way I don't need 10,000 events for every class I add.
If I have this code in a form I can communicate between forms perfectly but when I try to isolate it in it's own class to reuse it won't let me subscribe any more, the event is always null.
Main Form:
Secondary Form:
Event Class:
If I have this code in a form I can communicate between forms perfectly but when I try to isolate it in it's own class to reuse it won't let me subscribe any more, the event is always null.
Main Form:
public partial class Form1 : Form
{
ConsoleText cl = new ConsoleText();
public Form1()
{
InitializeComponent();
this.cl.ConsoleUpdate += new System.EventHandler(OnMessageReceived);
}
public void OnMessageReceived(object sender, System.EventArgs e)
{
}
}
Secondary Form:
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
ConsoleText cl = new ConsoleText();
cl.Update("1");
}
}
Event Class:
ublic class ConsoleText
{
public class ConsoleTextEventArgs : EventArgs
{
public string Text;
}
public void Update(string Text)
{
TriggerUpdate(Text);
}
public event EventHandler ConsoleUpdate;
protected virtual void TriggerUpdate(string Message)
{
EventHandler ConsoleHandle = ConsoleUpdate;
if (ConsoleHandle != null)
{
ConsoleTextEventArgs e = new ConsoleTextEventArgs();
e.Text = Message;
ConsoleHandle(this, e);
}
}
}
#11
Re: Calling a Void That Edits a TextBox From Another Class
Posted 13 September 2012 - 10:25 PM
It's because you're creating a new instance of the class in both forms. A class is like a blueprint, instances are the things built from the blueprint. new does the building. You've created two copies of the same thing, then modified one. The second won't reflect the changes to the first.
There are a few ways to handle this. If Form1 is the one that creates Form2, you could change Form2 to have a constructor parameter to pass the instance of your ConsoleText class from the first to the second. Or, you could read up on the Singleton pattern, and change your ConsoleText class so that there is only ever one instance, and that instance is available statically from the class itself. Static properties/methods/fields are shared across all instances of a class. If you're going to have lots of forms all subscribing to the same event triggered from a single form, the Singleton may be the way to go. If you just want one form to listen to the other, it might be smarter (or at least simpler) to pass the reference to Form2.
There are a few ways to handle this. If Form1 is the one that creates Form2, you could change Form2 to have a constructor parameter to pass the instance of your ConsoleText class from the first to the second. Or, you could read up on the Singleton pattern, and change your ConsoleText class so that there is only ever one instance, and that instance is available statically from the class itself. Static properties/methods/fields are shared across all instances of a class. If you're going to have lots of forms all subscribing to the same event triggered from a single form, the Singleton may be the way to go. If you just want one form to listen to the other, it might be smarter (or at least simpler) to pass the reference to Form2.
Page 1 of 1
|
|

New Topic/Question
Reply




MultiQuote








|