|
Congratulations!
Do you have a question or did you just want to share?
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
hello,
how are you dudes
I have a problem that has been annoying me for quit some time now, and I was hoping that any one can help me with it.
it is as follows:
Let say we have a main form in windows application form and I have on it some text boxes and buttons and so on, and also I have other classes so each class is specialized in doing something.
so I want on of the text boxes to accessible by all of the other class so they can write to it every thing that happen (status, error.. etc).
any ideas ?
if you can provide an example it would be great.
Note: I already post this question in msdn.microsoft.com, but most of the answers was too advanced for me; if it will help this is the link for the question
http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/7655aed2-9df2-4558-add7-d741fbd49fc7[^]
Thank you,
Mohammed
|
|
|
|
|
You want to access the controls of another form? You can store those items in an object, or you can use properties to access / change them...
|
|
|
|
|
this is the question ?
|
|
|
|
|
Change the modifier property of your text box to public to get it accessible to all the class.
Now in other class you can access the textbox just like any other class object.
Hope this helps U
With Regards,
B.Ananthvivek
|
|
|
|
|
already tried that.. not working.
you know this can be done very easily in VB.NET this way, but my whole work is in C#
|
|
|
|
|
Yes, Vb.NET is designed for stupid people. Perhaps if you were to post some code, then we could work out why you can't make it work. Best guess - you don't know C# and so can't write the ( very simple ) code to do this, even after you've been told how to do so.
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
hi, watch your manner, you are very rude aren't you ?
I guess you don't have any manners to watch... since you weren't very helpful.
as the saying say "The barking of the dogs will never harm the clouds".
you have shown your hatreds and what you hold is much much more...
you and I know exactly why is that...
|
|
|
|
|
This is a terrible idea. Don't expose the control, only the part you need to get to, such as the text property
Christian Graus
Driven to the arms of OSX by Vista.
|
|
|
|
|
It's not necessarily a good idea to directly update form's controls from several places. However, there are several approaches to this. Since this is your main form, I take it there can be only 1 instance at all time.
One possibility is to make it a singleton. In that case you would always have access to the form itself. The form would look like:
public partial class MainForm : Form {
private static MainForm _theForm;
private MainForm() {
InitializeComponent();
_theForm = this;
}
public static MainForm Instance {
get {
if (_theForm == null) {
_theForm = new MainForm();
}
return _theForm;
}
}
...
Now when you start the application instead of creating the form you refer to it's Instance:
Application.Run(MainForm.Instance);
When you want to access it's properties or methods you always use Instance. For example if you want to get Height, you would have:
System.Windows.Forms.MessageBox.Show(MainForm.Instance.Height.TowString());
So now you can write your own properties on the main form and access them via Instance.
Hope this helps.
|
|
|
|
|
wow, it really worked fine,
Thanks a lot man this really helps so much
This post should be in a separate article..
|
|
|
|
|
|
I'm not sure that this is the best way in this particular circumstance but it will work. Based on the fact that you've referred to it as a 'main form', I'm assuming all your other classes are instanciated either in the main form or from an instance that originated there. If so, You can use a simple events hierachy system.
Parent
----Child (Raises events. Parent subscribes on instanciation)
--------Grandchild (Raises events. It's Parent(Child) subscribes on instanciation and passes them on to the grandparent(Parent))
The downside of this system is that many events may have to be raised if the 'family tree' is deep. I'm not sure how memory hungry this can become as it seems that instances in the hierachy may not be released while there are subscribers to it. In the above, if the Child is closed, the Grandchild can still pass events to it which are in turn passed to Parent so the Child must be being kept alive. I've never had to consider this before - time for more investigation!
Anyway, here's a simple example based on the above using 3 forms and an EventArgs class.
using System;
using System.Drawing;
using System.Windows.Forms;
public partial class FormParent : Form
{
private ListBox listBox1;
private Button button1;
public FormParent()
{
InitializeComponent();
Width = 430;
listBox1 = new ListBox();
listBox1.Location = new Point(12, 12);
listBox1.Size = new Size(400, 200);
Controls.Add(listBox1);
button1 = new Button();
button1.Click += new EventHandler(button1_Click);
button1.Location = new Point(12, 224);
button1.Text = "Open &Child";
Controls.Add(button1);
}
void button1_Click(object sender, EventArgs e)
{
FormChild child = new FormChild();
child.StatusUpdate += new EventHandler<StatusEventArgs>(child_StatusUpdate);
child.Show();
}
void child_StatusUpdate(object sender, StatusEventArgs e)
{
listBox1.Items.Add(sender.ToString() + ": " + e.Message);
}
}
using System;
using System.Drawing;
using System.Windows.Forms;
public partial class FormChild : Form
{
public event EventHandler<StatusEventArgs> StatusUpdate;
private Button button1;
public FormChild()
{
InitializeComponent();
button1 = new Button();
button1.Click += new EventHandler(button1_Click);
button1.Location = new Point(12, 12);
button1.Width = 100;
button1.Text = "Open &Grandchild";
Controls.Add(button1);
}
void button1_Click(object sender, EventArgs e)
{
FormGrandChild grandchild = new FormGrandChild();
grandchild.StatusUpdate += new EventHandler<StatusEventArgs>(grandchild_StatusUpdate);
grandchild.Show();
OnStatusUpdate(this, new StatusEventArgs("Grandchild created"));
}
void grandchild_StatusUpdate(object sender, StatusEventArgs e)
{
OnStatusUpdate(sender, e);
}
protected virtual void OnStatusUpdate(object sender, StatusEventArgs e)
{
EventHandler<StatusEventArgs> eh = StatusUpdate;
if (eh != null)
eh(sender, e);
}
}
using System;
using System.Drawing;
using System.Windows.Forms;
public partial class FormGrandChild : Form
{
public event EventHandler<StatusEventArgs> StatusUpdate;
private Button button1;
public FormGrandChild()
{
InitializeComponent();
button1 = new Button();
button1.Click += new EventHandler(button1_Click);
button1.Location = new Point(12, 12);
button1.Width = 100;
button1.Text = "&Send Status";
Controls.Add(button1);
}
void button1_Click(object sender, EventArgs e)
{
OnStatusUpdate(new StatusEventArgs("Button Clicked"));
}
protected virtual void OnStatusUpdate(StatusEventArgs e)
{
EventHandler<StatusEventArgs> eh = StatusUpdate;
if (eh != null)
eh(this, e);
}
}
using System;
public class StatusEventArgs : EventArgs
{
private string m_Message;
public StatusEventArgs(string message)
{
m_Message = message;
}
public string Message
{
get { return m_Message; }
}
}
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
nope, this will not do me any good.
I already tried inheritance doesn't work for me, plus it consume memory with no use
Thanks for the effort
|
|
|
|
|
Have a look at this MSDN page[^] that explains the observer pattern, it could be ideal for your purpose.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
we'll do
Thank you
|
|
|
|
|
OK, I've thought about this a little more and experimented. Another (maybe preferable) alternative is to create a singleton. Give the singleton an event that the main form can subscribe to, and a method that your other classes can call which will in turn raise the event. Much better than my previous suggestion and more maintainable.
I'll shut up now
using System;
using System.Windows.Forms;
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
Singleton.Instance.SingletonEvent += new EventHandler(Instance_SingletonEvent);
Form2 frm2 = new Form2();
frm2.Show();
}
void Instance_SingletonEvent(object sender, EventArgs e)
{
Console.WriteLine("Singleton Event");
}
}
using System;
using System.Windows.Forms;
public partial class Form2 : Form
{
public Form2()
{
InitializeComponent();
}
private void Form2_Load(object sender, EventArgs e)
{
Singleton.Instance.SingletonMethod();
}
}
using System;
public class Singleton
{
public event EventHandler SingletonEvent;
static readonly Singleton instance = new Singleton();
static Singleton() { }
Singleton() { }
public static Singleton Instance
{
get { return instance; }
}
public void SingletonMethod()
{
OnSingletonEvent(new EventArgs());
}
protected virtual void OnSingletonEvent(EventArgs e)
{
EventHandler eh = SingletonEvent;
if (eh != null)
eh(this, e);
}
}
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
I'll try it
Thanks again
but I have to admit Mika Wendelius answer is the easiest and better
|
|
|
|
|
You're welcome.
Mika's answer is basically the same, except he's making the main form a singleton instead of a seperate object that communicates with the main form.
His way is easiest if the main form is always going to be needed (which it normally is of course). I think a seperate 'Notifier' singleton class that raises events that the main form (or anything else for that matter which is a big plus) can subscribe to may, in the long term, have advantages - and is maybe a little more OO. Just like Mika's solution, it can have properties and methods that will be accessisble to all objects in your application.
DaveBTW, in software, hope and pray is not a viable strategy. (Luc Pattyn)Visual Basic is not used by normal people so we're not covering it here. (Uncyclopedia)
|
|
|
|
|
As I mentioned in my post, I didn't like the idea that the logic is scattered throughout the application and the combining element is a form (main form or any other). So I fully agree with you that it would be benefitial to have separate controller class and the form is used only for viewing.
So basically both main form and the controller may be singletons, although I think there would be a point if controller is even static, if possible. Do you see any downsides on that?
And also you're definitely right when saying that it would be more OO
Mika
|
|
|
|
|
your both right, I changed all of the the modifiers in the main form to private, it was public, and I Invoked all of the texts through a delegate without touching the form control, this is better than accessing the components directly, even if we say lets try this you can't access the component unless you change the modifiers to public, internal or protected internal.
by the way, don't think that the program should divided into separate parts (classes) you call each part with a new object and when you done just close it ? beside it is for less memory consumption and faster for the program to run .
if you see a better way for ding this, let me know
in any case Thank you all
|
|
|
|
|
You have already got enough replies. Here is my thoughts.
You need to update a control(textbox or button) on a form from a separate class, right? As others suggested, delegates is good. But for your problem, I think the most obvious method is to hide the control update behind a well defined interface and pass that interface to your class. Following code shows what I meant.
public interface IMainForm
{
void UpdateTextBoxText(string text);
....
}
public class MainForm : Form, IMainForm
{
public void UpdateTextBoxText(string text){
}
void button_click(object sender,EventArgs args)
{
ASeparateClass a = new ASeparateClass(this);
}
}
public class ASeparateClass
{
IMainForm form;
public ASeparateClass(IMainForm form){
this.form = form;
}
} Delegate approach also will work well.
|
|
|
|
|
I want to design my programs so that they can accept plugins that may be installed later. How should I design my program and how should plugins structure be? Should I use reflection?
Thanks,
Artmansoft
|
|
|
|
|
like this
example coder:
[System.Runtime.InteropServices.DllImport("user32.dll", EntryPoint = "GetWindowLong")]<br />
public static extern Int32 GetWindowLong(Int32 hWnd, Int32 nIndex);
"user32.dll" is the filename whitch you want to plugin.
"GetWindowLong" is a method in this file.
|
|
|
|
|
This code is used when we know the name of the plug-in in advance. What if we are not aware of future plugin's name?
|
|
|
|