C# static components

[Journer]

ok, i think it would be easiest to explain my problem like this:

i have two forms, form1, form2.

form1 is the main form...it can open form2, do some other stuff like take input, etc.

form2 is just a form with a text box.

i want some info put it in form1 to be transfered to form2's text box

but no matter what i do, i cannot update (or see) the text box component on form2. i've tried creating a public static method inside of form2's class that would take in a string and update the text box, but as soon as i make it public or static, it no longer allows access. I've tried setting the accessible role to static text and few other things but nothing works...

anyone know of some articles or something that explains how to make stuff globally accessible in C#

also, not sure that it matters, but this program is in .net 2.0 compatibility mode and has to stay that way

 

[oog]

a method that is marked as static does not have instance-level scope. i think you just want to create a public method and you should be able to call it on the particular instance of form2.

 

[AgentZap]

oog's advice is sound

 

[Crusty]

I would advise you to pick up a book on Object Oriented programming as well as a book C# if you are planning on being serious about writing C# applications.

Unfortunately, I learned all my OO concepts with C++/Java so I don't know of any tailored to a .NET or C#. I'm sure someone else could give you some good recommendations though.

 

[Journer]

ok, i am a bit confused with that answer, but here is (in a nutshell) what w want to do:

class form1{

public static Form form2 = new form2();
//this is because i can't ever update anything on form 2... >_<

private void saveReportToolStripMenuItem_Click(object sender, EventArgs e)
{
form2.mdiparrent = this;
form2.show();
textbox1.append("blablabla");
}

}

class form2{

//all forms and crap declared and setup by VS2008
//inside of here is a form with a textbox called texbox1

}


what do i have to do to get that to work?

ive tried something like:

class form2 {

public static class update(string s){
textbox1.append(s);
}
}

but that doesn't work because it is public static

i r fail :'(

 

[oog]

Originally posted by: Journer
ok, i am a bit confused with that answer, but here is (in a nutshell) what w want to do:

class form1{

private void saveReportToolStripMenuItem_Click(object sender, EventArgs e)
{
textbox1.append("blablabla");
}

}

class form2{

//all forms and crap declared and setup by VS2008
//inside of here is a form with a textbox called texbox1

}


what do i have to do to get that to work?

ive tried something like:

class form2 {

public static class update(string s){
textbox1.append(s);
}
}

but that doesn't work because it is public static

i r fail :'(

inside form2, you want: public void update(string s) { textbox1.append(s); }

the "static" designation means that it's not a method that access anything on an instance. the "class" designation is just confusing--it means you're declaring a class, not a method.

 

[Journer]

generate code:

public partial class consoleForm : Form
{
public consoleForm()
{
InitializeComponent();
}

public void updateConsole(string s)
{
consoleBox.AppendText("CRLF" + s);
}

private void consoleForm_FormClosing(object sender, FormClosingEventArgs e)
{
e.Cancel = true;
this.Hide();
}


///in form1
private void saveReportToolStripMenuItem_Click(object sender, EventArgs e)
{
//i want consoleForm.updateConsole("text"); here
}

still not getting it...

i changed that function to public, public static, etc. and no matter what i do i can't access it from my other form :/

edit: just so you know, there is a whole other class form that is consoleForm.design.cs which has everything generated by VS08

 

[oog]

for the call itself, you can't use the class name "consoleForm" when you call updateConsole. you need a variable that contains the specific instance of consoleForm and you would call the function that way.

so, if you created the form with something like:

consoleForm foo = new consoleForm();

then later, you could call it with foo.updateConsole("text");

 

[Journer]

yes, i did that, but when you try to call:

foo.updateConsole("text");

it doesn't recognize it with intellitext. when you compile, it errors out saying it doesn't exit, bla bla bla

 

[imported_Dhaval00]

Why don't you create public properties in the first form and set them in Form2? In the properties' set accessors, you use the 'value' to your liking. The other way I have done this is via delegates, but that path might get too confusing if you're doing something simple.

 

[Crusty]

Originally posted by: Dhaval00
Why don't you create public properties in the first form and set them in Form2? In the properties' set accessors, you use the 'value' to your liking. The other way I have done this is via delegates, but that path might get too confusing if you're doing something simple.

Well, you're only going to need to use a delegate if the threat thad you are accessing the GUI elements on is NOT the thread that they were created on. Whenever I am doing something like this I always check InvokeRequired and call the delegate if I need to, saves me time later if someone changes something and it's just safer in general.

 

[imported_Dhaval00]

Originally posted by: Crusty

Originally posted by: Dhaval00
Why don't you create public properties in the first form and set them in Form2? In the properties' set accessors, you use the 'value' to your liking. The other way I have done this is via delegates, but that path might get too confusing if you're doing something simple.

Well, you're only going to need to use a delegate if the threat thad you are accessing the GUI elements on is NOT the thread that they were created on. Whenever I am doing something like this I always check InvokeRequired and call the delegate if I need to, saves me time later if someone changes something and it's just safer in general.

Not quite... that's the technique "they" show you. The native way of handling delegates allows you to do some advanced programming. Take this for instance:

Form1 has a delegate, a button, and a textbox. Here is the delegate's signature:
public delegate void ExchangeData(String text);

Form2 has a label, and the delegate handler:
public void HandleData(String text)
{
label1.Text = text;
}

The way you'd pass data to Form2 from Form1 is by hooking into the delegate. So in Form1, you could have:
protected void button1_Click(object sender, EventArgs e)
{
delegate passString = new ExchangeData(Form2.HandleData);
passString(textBox1.Text);
}

Of course, this is neither compiled nor tested. It's been sometime since I last worked on a forms project, but that should give you the general idea.

Edit: Yet another approach is to use Application.OpenForms... Google it.

 

[Journer]

ill try this when i get back to work. not really sure what you all are talking about though, lol.

anyways, i don't understand why it has to be so difficult just to update something from the same damned application. it's not like i'm exchanging data with another program :/

 

[Crusty]

Originally posted by: Dhaval00

Originally posted by: Crusty

Originally posted by: Dhaval00
Why don't you create public properties in the first form and set them in Form2? In the properties' set accessors, you use the 'value' to your liking. The other way I have done this is via delegates, but that path might get too confusing if you're doing something simple.

Well, you're only going to need to use a delegate if the threat thad you are accessing the GUI elements on is NOT the thread that they were created on. Whenever I am doing something like this I always check InvokeRequired and call the delegate if I need to, saves me time later if someone changes something and it's just safer in general.

Not quite... that's the technique "they" show you. The native way of handling delegates allows you to do some advanced programming. Take this for instance:

Form1 has a delegate, a button, and a textbox. Here is the delegate's signature:
public delegate void ExchangeData(String text);

Form2 has a label, and the delegate handler:
public void HandleData(String text)
{
label1.Text = text;
}

The way you'd pass data to Form2 from Form1 is by hooking into the delegate. So in Form1, you could have:
protected void button1_Click(object sender, EventArgs e)
{
delegate passString = new ExchangeData(Form2.HandleData);
passString(textBox1.Text);
}

Of course, this is neither compiled nor tested. It's been sometime since I last worked on a forms project, but that should give you the general idea.

Edit: Yet another approach is to use Application.OpenForms... Google it.

That would work, but I don't think that won't overcome the threading problem.

 

[imported_Dhaval00]

Believe me, it works. The folks on my team and I have done it on numerous occasions . And no, there are no threading issues, unless of course, the forms themselves implement multithreading [which most real world applications do to keep the GUI responsive]. In that case, assuming you're using a BackGroundWorker or a custom threading logic, things will get cumbersome. If you don't explicitly mention, all the objects (forms, controls, etc.) will execute within the context of the current thread. The above method is somewhat synonymous to creating your events in a custom manner [this is how COM used to work anyway... at even a lower level, they used interfaces as sinks to raise/maintain events]. Formally, to take the idea even further, you could end up using an event-delegate model [even lambdas in .NET 3.5 AKA fancy anonymous methods in .NET 2.0], but that would result in over-engineering this situation.

 

[Crusty]

Originally posted by: Dhaval00
Believe me, it works. The folks on my team and I have done it on numerous occasions . And no, there are no threading issues, unless of course, the forms themselves implement multithreading [which most real world applications do to keep the GUI responsive]. In that case, assuming you're using a BackGroundWorker or a custom threading logic, things will get cumbersome. If you don't explicitly mention, all the objects (forms, controls, etc.) will execute within the context of the current thread. The above method is somewhat synonymous to creating your events in a custom manner [this is how COM used to work anyway... at even a lower level, they used interfaces as sinks to raise/maintain events]. Formally, to take the idea even further, you could end up using an event-delegate model [even lambdas in .NET 3.5 AKA fancy anonymous methods in .NET 2.0], but that would result in over-engineering this situation.

Any programmer worth anything will know to keep your business logic outside of your GUI code. As soon as you want to update your display from the outside code you'll run into threading issues unless you want to run your own message loop(bleh).

In fact, I substituted your code into some of our production code to test it and .net 2.0 and above throw exceptions!

 

[imported_Dhaval00]

Here try this (compiled and tested):

public partial class Form1 : Form
{
public delegate void PassData(TextBox text);

public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("In Form1, Current Thread ID: " +
System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
Form2 handler = new Form2();
PassData myData = new PassData(handler.AcceptData);
myData(textBox1);
handler.Show();
}
}

public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}

public void AcceptData(TextBox text)
{
MessageBox.Show("In Form2, Current Thread ID: " +
System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
label1.Text = text.Text;
}
}

Assumptions: Form1 has 2 controls - textBox1 and button1 (with its event handler set to button1_Click); Form2 has a label control - label1.
Let me know if you want me to send you the project. As I said, unless you have your custom threading logic, it will work.

Edit: Added calls to Threading API to assert that you're still on the same thread stack (could be a different fiber at the OS level).

 

[Crusty]

Originally posted by: Dhaval00
Here try this (compiled and tested):

public partial class Form1 : Form
{
public delegate void PassData(TextBox text);

public Form1()
{
InitializeComponent();
}

private void button1_Click(object sender, EventArgs e)
{
MessageBox.Show("In Form1, Current Thread ID: " +
System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
Form2 handler = new Form2();
PassData myData = new PassData(handler.AcceptData);
myData(textBox1);
handler.Show();
}
}

public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}

public void AcceptData(TextBox text)
{
MessageBox.Show("In Form2, Current Thread ID: " +
System.Threading.Thread.CurrentThread.ManagedThreadId.ToString());
label1.Text = text.Text;
}
}

Assumptions: Form1 has 2 controls - textBox1 and button1 (with its event handler set to button1_Click); Form2 has a label control - label1.
Let me know if you want me to send you the project. As I said, unless you have your custom threading logic, it will work.

Edit: Added calls to Threading API to assert that you're still on the same thread stack (could be a different fiber at the OS level).

And what I'm saying is that we do have custom threading logic, as will any production ready application that's not extremely simple. I can't go into too many details, but our applications must have a real time display w/ a real time engine sitting behind it. The two parts of the application are completely decoupled in terms of functionality.

We really are getting away from the OP though. My advice still holds for the OP though. I really think getting some books and learning a bit about OO programming will help him far more then sitting here asking questions

 

[Journer]

still isn't working. whenever i use the code dhavel00 gave, intellitext doesnt recognize acceptData or PassData therefor compiling fails.

honestly, i think this is being over-complicated. there has got to be a simplistic way to update this stupid thing. i believe i've done it before i just cant find the project i did it in. also, this isnt some fancy live-world tool. its just a simple app i'm developing in my free time to help my dept.

anywho, there is no threading or custom threading...wouldn't know how to do that. i do wish i could find a way to make every component and form public static...that would be handy :laugh:

honestly, i think there is some setting i have screwed up or something. i don't really give a shit how secure this app is because it doesnt access anything important and it will only ever be used by a few people :/

 

[Journer]

argghhh...damn, i figured it out :'(

<-newb

this is what i had in form1's class to create form2:

public static new form consoleForm = new consoleForm();

///


this is what i changed it to:

consoleForm consoleForm = new consoleForm();

note: originally i made it: consoleForm f = new consoleForm();

works that same way except now i only call the instance of the form that i want

now the problem is getting it work with a 3rd form (and more )

 

[Journer]

well, now my problem is accessing the instance of consoleForm that form1 created from form3 :/

i tried this in form 3

mainForm = (mainForm)Application.OpenForms["mainForm"];

//button click function{

mainForm.updateConsole("weee");
}

now, it compiles just fine, but when you click that button it gives a null pointer reference error :/

 

[Journer]

ok, figured it out again

i changed:

consoleForm consoleForm = new consoleForm();

to

public static consoleForm consoleForm = new consoleForm();

now it works fine. i can access from form1 and form3. w00t!

so, in the end, all i REALLY did was change

form consoleForm

to

consoleForm consoleForm

newbness FTL :/


now...since i've ran this thread into the ground...anyone want to help me tell the close button to hide instead of close a form :laugh: ?

currently i have a method that when the form tries to close, it cancels the close and hides it, but the problem is, if you have the form open and try to close the app...it just hides the form :/

 

[imported_Dhaval00]

Did you use Application.OpenForms ultimately?

You want to subscribe to the ApplicationExit event, and do all your clean up in the delegate handler (closing, exiting forms, etc). At higher level, though, closing the application should be sufficient... again, been a long time, so I could be wrong. Web apps are the new Windows Forms for me.

 

[Journer]

Originally posted by: Dhaval00
Did you use Application.OpenForms ultimately?

You want to subscribe to the ApplicationExit event, and do all your clean up in the delegate handler (closing, exiting forms, etc). At higher level, though, closing the application should be sufficient... again, been a long time, so I could be wrong. Web apps are the new Windows Forms for me.

nope. it never worked right for me :/

i did subscribe an application exit event (form closing) and it works fine. the problem is, if that form is open and you wan to close the entire application. it will first hide the form. then you have to click close again to close the app. i can disable the close button on that form, but the problem is i need it...the close button needs to HIDE instead of send a close.

i'm guessing the only way to do this is with the return args from form closing

right now it is:

private void consoleForm_FormClosing(object sender, FormClosingEventArgs e)
{
e.Cancel = true;
this.Hide();
}

i'm guessing there is a way i can determine if the sender is consoleForm or the application...not sure yet though :/

well, now i found out that when you close the program, the consoleForm closes itself...so the send is itself. but, if i want to hide it, the sender is still itself. man this is dumb :/

 

[Journer]

ok...i kind of fixed this one too...its not pretty, but it works:

private void consoleForm_FormClosing(object sender, FormClosingEventArgs e)
{
if(!MainForm.forceClose)
e.Cancel = true;
this.Hide();
}


form1

public static bool forceClose = new bool();
private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
forceClose = false;

private void MainForm_Load(object sender, EventArgs e)
{
forceClose = true;
}

weee