Printable View
Is there a way to globally access a form (or form instance) with all it's controls accessible too? The singleton pattern does that by Form.Instance.(Control), but what if I want an App.Form.(Control) or even just Form.(Control) access path?
Also, if it's possible to do like that with a form that can be duplicated it's even better... (ie Form1a.(Controls), Form1b.(Controls))
Because other people might be conserned too, I've discovered that the SharpDevelop IDE supports public-declared controls in the designer (which is why I couldn't solve it that way with VS), which solves the problem of access....
I should have explained why I couldn't do it that way before. How to get rid of .Instance or other quirks in access path I haven't figured out yet (I want to access forms as in VB6).
Please note that accessing forms like in VB6 violates about half of all OOP rules. That's probably why VS won't let you do it. It might be easy, but there will probably a way to solve your problem and follow the OOP rules. Maybe you can explain why you would need such a behaviour.
Object orientation, if not working the way that comes natural to people, is stupid. It's not for the computers, it's for the programmer...
However, though one can't have a form instance "hanging in the air" everywhere, it's possible to use App.FormInstance or Form.Instance and make sure all controls in the form class are declared public, so I have so to speak solved the problem...
...but it would be nicer if the form instance could be "lose" and exist like a global var.
VB is better in that way because it allows that. But you'll get the annoying Microsoft.VisualBasic somehow involved in any exe you create with it which makes the app look less professional (vb not beeing as much a real programmers language as C#) if someone ILDASMs it...
I should add that what I wrote in the begining of this thread was wrong - singleton does nothing for control accses, nor is it unique for singleton to keep a form instance (of course), but I want to correct these errors. I also said that VS does not allow public controls in the designer, but it does. Must have confused it with some other declaration kind I've tried.
Could you explain what you mean? Because Form1 is a class and not an instance? Why not include "default instance" as an OO concept?Quote:
Please note that accessing forms like in VB6 violates about half of all OOP rules.
If you say Form1.Text = "xx" it can't mean changing that on the class (not allowed) so it has to mean an instance. I'm not saying it's terrible trouble to use Form1.Instance, just a little weird if there's only one instance... (esp if it's a singleton).
Basically why bother to even work with objects then, if I would follow your way of thinking every method I would ever write would be static and be called ClassName.StaticMethodName();.
If you dont see the advantages of OOP now maybe itŽll come later...
Really youŽll find out soon enough i guess...
and im not too familiar with all these names like instances and so on but
Maybe I misinterpreted you but IŽd say .Text is a property of Form1 and not an instance.Quote:
If you say Form1.Text = "xx" it can't mean changing that on the class (not allowed) so it has to mean an instance.
Because, simply put, you should never have public member variables in any class. Never ever.Quote:
Could you explain what you mean? Because Form1 is a class and not an instance? Why not include "default instance" as an OO concept?
The reason many programmers look down on VB is because VB supports bad programming style and spaghetti code. I agree that it seems easier at first and it might be easier for very small programs. But people using it "professional" tend to write large applications, maybe even in teams and in this environment, it is very important to have "proper" code. In the long run, "proper" code is worth more than "quick" code. Because it's only quick right now... 2 years from now, you will spend hours after hours wondering what the hell your program does and how it can do this.Quote:
VB is better in that way because it allows that. But you'll get the annoying Microsoft.VisualBasic somehow involved in any exe you create with it which makes the app look less professional (vb not beeing as much a real programmers language as C#) if someone ILDASMs it...
First you're violating the encapsulation principle. Each "Form" is a "black box" - you create a form, tell it to show itself, and let it worry about how it'll do it. If you want to interact with the form, you send "messages" to it. So for instance, if you want to change the text in a TextBox on a form from outside the form, you would have a method called "SetText()" which sets the underlying text property. You don't just expose the text box.
You method is great for small applications. If I was writing a little hacky program, I'd even prefer it. That's why you can do it in VB6. But in the case of large software it can be very difficult to maintain.
I can't think of a single case where your method would result in a better designed application than doing it the correct, object oriented, way. To rely on such a method would be proof that your design needs work.
>> Object orientation, if not working the way that comes natural to people, is stupid
Well, it's actually a lot more natural. Lets say you are a form. I am also a form. Your brain and way of thinking is "private", that is I can't simply make you change your mind directly. I can influence you by saying things that might make you reconsider your poor ideas about not using OO in C#, which might (hopefully) change your mind indirectly, but I can't just change your mind for you. Likewise, as a Form, I shouldn't be able to update a DataGrid you have displayed. I could however, ask you to update it, and let you handle how the grid should be updated.
If you want to expose the text in a TextBox, expose public properties:
Now, lets say you use this method. Everywhere you might want to change the displayed "username" in a text box, you could set the Username property on the form. Lets say you're doing it from 3 different places. You then change usernameTextBox so that it's a dropdown box. You'll change the name of it to usernameDropDown. But oh no, you're calling that field from 3 different places, and seting the value in a text box is much different to setting it in a dropdown, so thats 3 places you're going to copy that code.Code:public class Form1
{
.....
public string Username
{
get { return usernameTextBox.Text; }
set { usernameTextBox.Text = value; }
}
}
Contrast that to using the property getters and setters. In my method, you're simply saying "set the username to PaulS". You don't give a flying hoola hoop about what setting that name is actually going to change. In the properties setter on Form1, you would put the code to set the dropdown. You've just reduced code, made it easier to maintain, and you're not going to get laughed at when you reveal the code to anyone.
So while the OOP way might seem harder (creating the public properties for everything you want to set) it's actually a lot better and makes it a thousand times easier to maintain when you change the underlying controls on the form. Each form is a seperate object, and only it should be able to change it's internals.
That's the part of traditional OO that was not so OO after all so languages like C# and D have properties instead of getter and setter functions (altought they are ofcourse made up of getter and setter funcs in practice).Quote:
if you want to change the text in a TextBox on a form from outside the form, you would have a method called "SetText()" which sets the underlying text property. You don't just expose the text box.
Ok, so you're not against properties. But because the form and it's controls already exist, and they have properties, creating additional properties seems unnecessary for me.Quote:
If you want to expose the text in a TextBox, expose public properties:
The world of computers have advantages over real life. Bill gates experimentally once made some computerenvironment (this might be just an urban (or let's say digital) lengend, but anyway) were one was supposed to ask and thank the virtual assistant for doing everything rather than just "ordering the slave" with commands or clicks.Quote:
Lets say you are a form. I am also a form. Your brain and way of thinking is "private", that is I can't simply make you change your mind directly. I can influence you by saying things that might make you reconsider your poor ideas about not using OO in C#, which might (hopefully) change your mind indirectly, but I can't just change your mind for you.
Wouldn't it be wonderfull if you could just plug into my brain and change my weird conceptions? Why should I not control my form like a slave robot - it's my form.
But you're right about creating public properties if something is supposed to be displayed on several controls, but most things are not. To a human, a TextBox's .Text property and the username is the same thing.
Having the username as a screen object is about as object oriented as it gets.