I'm sure this is the most pathetic question in C#...But I have a GUI on my form frmMain (go figure :P) and then I have another class, that I want to control the text of frmMain, so I in frmMain.Designer.cs I made my GUI controls publics so I could alter the text. So in one of my voids, I put
frmMain Main = new frmMain();
Main.TabPage1.Text = "Blah";
To append text, I also use my AddChat function, which is in my frmMain.cs and nothing is working, I compile, and get no errors, nothing happens though...
I hope this wasn't too confusing.. I have such a headache..
I've got a neat solution but I can't attach it for some reason. Anyhow, IM me and I'll send it.
Methods, not public fields :P aka data encapsulation. Granted, encapsulation can sometimes be a nuisance for things like setUsername() getUsername() etc., but in a situation like this, i.e. modifying the output on a GUI, I believe encapsulation is warranted.
I think learning some of the basics of OOP and software design would highly benefit.
Quote from: dlStevens on June 30, 2007, 08:57:17 PM
I'm sure this is the most pathetic question in C#...But I have a GUI on my form frmMain (go figure :P) and then I have another class, that I want to control the text of frmMain, so I in frmMain.Designer.cs I made my GUI controls publics so I could alter the text. So in one of my voids, I put
frmMain Main = new frmMain();
Main.TabPage1.Text = "Blah";
To append text, I also use my AddChat function, which is in my frmMain.cs and nothing is working, I compile, and get no errors, nothing happens though...
I hope this wasn't too confusing.. I have such a headache..
Sounds like you're talking to the wrong object, i.e. you're instantiating a new object different from the one that displays your GUI, and telling that object to addChat, modifying variables that never come into play. You have to pass a reference around your program to the original GUI object (there really should be no more than one). There are many ways to do this, such as passing by constructors, passing by methods, Singletons, etc.
Quote from: Ender on July 01, 2007, 05:02:19 AM
Methods, not public fields :P aka data encapsulation. Granted, encapsulation can sometimes be a nuisance for things like setUsername() getUsername() etc., but in a situation like this, i.e. modifying the output on a GUI, I believe encapsulation is warranted.
I think learning some of the basics of OOP and software design would highly benefit.
private string c_sUsername;
public string Username
{
set { this.c_sUsername = value; }
get { return this.c_sUsername; }
}
You need to learn object-oriented programming, as Ender said, before you try to tackle a bot or something similar in C#.
Quote from: Joex86/64] link=topic=9724.msg123523#msg123523 date=1183309102]
private string c_sUsername;
public string Username
{
set { this.c_sUsername = value; }
get { return this.c_sUsername; }
}
Sorry to hijack this a bit.
Does this method work in java? (I'm at the library, no place to test)
I've never seen it done in java so.. ?
If it does this will help emensly in memory consumption of things i'm writing.
~Hdx
Quote from: HdxBmx27 on July 03, 2007, 02:14:23 PM
Quote from: Joex86/64] link=topic=9724.msg123523#msg123523 date=1183309102]
private string c_sUsername;
public string Username
{
set { this.c_sUsername = value; }
get { return this.c_sUsername; }
}
Sorry to hijack this a bit.
Does this method work in java? (I'm at the library, no place to test)
I've never seen it done in java so.. ?
If it does this will help emensly in memory consumption of things i'm writing.
~Hdx
It should, or at least a variant of it. Most OO programming languages should have Property modifiers. (Hell, even VB has them)
Java doesn't have property modifiers like that. I haven't tested it but I'm 99.9% sure :P
You're right, Java isn't as advanced as C#. =/
We could reverse that on you and say that C# is more complicated than Java and a pain in the ass to use. Please leave your bias at the door.
@Hdx: No. If you just do set and get methods though it shouldn't be too intensive. Perform some sanity checks where needed if you want a little edge.
Quote from: Joex86/64] link=topic=9724.msg123891#msg123891 date=1183812929]
We could reverse that on you and say that C# is more complicated than Java and a pain in the ass to use. Please leave your bias at the door.
@Hdx: No. If you just do set and get methods though it shouldn't be too intensive. Perform some sanity checks where needed if you want a little edge.
I can reverse this and say you're an idiot. Try to leave that at the door.
Also, who's "we" you're one person.
Shut up.
Quote from: Joex86/64] link=topic=9724.msg123891#msg123891 date=1183812929]
We could reverse that on you and say that C# is more complicated than Java and a pain in the ass to use. Please leave your bias at the door.
Not really. Here's why.
C# is a superset of Java. Everything that you can do in Java, you can do in C# with minimal modification (such as type name changes). A java class will be valid C#.
However, C# supports treating primitives like objects. Java's type system does not. In Java you have (as types that can be represented by literals):
byte
short
int
long
float
double
Object
|-> String
In C# you have:
Object
|-> byte
|-> sbyte
|-> short
|-> ushort
|-> int
|-> uint
|-> long
|-> ulong
|-> float
|-> double
|-> decimal
|-> string
(Technically, all of the numerics in C# inherit from System.ValueType, but that's an internal compiler detail since ValueType isn't really used in any instance ever).
Because in C# all primitives are actually Objects, we can do something like so:
ArrayList al = new ArrayList();
al.Add(1);
al.Add(4485);
al.Add("This is a string.");
In Java, you can't; you have to provide the class wrapper (except in the case of strings):
al.add(new Integer(1));
al.add(new Integer(4485));
al.add("This is a string.");
Also, because C# supports overloaded operator this[], ArrayList can be treated like an array, which makes its syntax cleaner. Example:
int val = (int)al[0];
int val2 = (int)al[1];
string val3 = al[2] as string;
In Java you'd have to:
int val = ((Integer)al.get(0)).intValue();
int val2 = ((Integer)al.get(1)).intValue();
String val3 = (String)al.get(2);
Note also that the semantic difference between the C# and Java implementations of getting "val3" are important. In C#, if the third ArrayList element is not a String-compatible type, val3 will be null. In Java, because you're forced to do typecasting in this way, you run the risk of generating a ClassCastException. If you cast that way in C# you can generate an InvalidCastException as well. The point is that you don't need to cast reference types in a way that generates an unnecessary exception.
I haven't even begun to talk about all other ways that Java is a pain in the ass - such as the necessity of an additional class where function pointers would suffice (Runnable, for example, vs. a ThreadStart calback in C#).
I can tell you enjoyed that.
Quote from: MyndFyrex86/64] link=topic=9724.msg123915#msg123915 date=1183844796]
Because in C# all primitives are actually Objects, we can do something like so:
ArrayList al = new ArrayList();
al.Add(1);
al.Add(4485);
al.Add("This is a string.");
In Java, you can't; you have to provide the class wrapper (except in the case of strings):
al.add(new Integer(1));
al.add(new Integer(4485));
al.add("This is a string.");
I know this post is a bit old, but I just want to point out that this is entirely wrong. Clicky (http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html).
Though currently the code should look something like this:
ArrayList<Object> al = new ArrayList<Object>();
al.add(1);
al.add(4485);
al.add("This is a string.");
You can specify a type, but I'm pretty sure that the default is Object.
Quote from: Sidoh on August 16, 2007, 02:04:33 PM
You can specify a type, but I'm pretty sure that the default is Object.
Yeah, but you're not supposed to do it without a type (as of java 5). The compiler will give you a warning!
Sorry, I thought that was the entire point of your post. I must've missed the rest of that.
That being said, I still think what MyndFyre said is very true. C# is a superset of Java.
Quote from: Sidoh on August 16, 2007, 05:02:24 PM
That being said, I still think what MyndFyre said is very true. C# is a superset of Java.
I don't care either way about the whole java vs. C# battle, I was just pointed out that one of his examples was wrong. Well, it's not even really wrong, just outdated.
Quote from: Hitmen on August 16, 2007, 06:13:56 PM
Quote from: Sidoh on August 16, 2007, 05:02:24 PM
That being said, I still think what MyndFyre said is very true. C# is a superset of Java.
I don't care either way about the whole java vs. C# battle, I was just pointed out that one of his examples was wrong. Well, it's not even really wrong, just outdated.
It's not even really outdated. Here's why:
Quote from: Hitmen on August 16, 2007, 11:14:15 AM
I know this post is a bit old, but I just want to point out that this is entirely wrong. Clicky (http://java.sun.com/j2se/1.5.0/docs/guide/language/autoboxing.html).
Though currently the code should look something like this:
ArrayList<Object> al = new ArrayList<Object>();
al.add(1);
al.add(4485);
al.add("This is a string.");
Autoboxing is a feature of the
compiler, not the
runtime. The compiler itself emits the "new Integer(1)" code intrinsically whenever a reference type is expected in place of a primitive, and so if you were to decompile, you'd see calls such as list.add(new Integer(1)); in place of your original list.add(1); call.
Why is this distinction important? Well, by putting this in the compiler rather than in the runtime, Java has effectively put a barrier to EVER supporting the declaration of custom primitive types.
In most procedural OOP languages such as C++, Java, and C#, you have two types of variables: stack and heap. Stack variables are the local variables that exist within the local function scope. Heap variables can be shared across scope. I'll give you an example.
The following types in Java and C# are always stack variables: Java (byte, short, int, long, boolean, float, double), C# (byte, sbyte, short, ushort, int, uint, long, ulong, bool, float, double, decimal).
In Java, all other classes are heap variables, which all derive from java.lang.Object. That means when you declare a heap variable, a tiny little object reference is created on the stack which is effectively a pointer (more accurately it's a handle), but all of that object's other data exists in the pointed-to location in heap memory. This is also true in C#, for all classes that are declared "class" (classes that are declared "struct" are custom stack-level variables). Heap classes in C# work exactly the same way. However, structures do not.
Consider the following C# structure declaration:
public struct Point {
public int X;
public int Y;
public Point(int x, int y) { X = x; Y = y; }
}
If I were to create a new Point, both the X and Y components of that Point would exist on the stack. Consider the same definition but with a class keyword.
public class PointClass {
public int X;
public int Y;
public PointClass(int x, int y) { X = x; Y = y; }
}
Now consider the following code:
static void Main(string[] args) {
Point point = new Point(1, 2);
PointClass pointClass = new PointClass(1, 2);
ChangePoint(point);
ChangePointClass(pointClass);
Console.WriteLine("Point: ({0}, {1}); PointClass: ({2}, {3}).", point.X, point.Y, pointClass.X, pointClass.Y);
}
static void ChangePoint(Point p) { p.X += 1; p.Y += 2; }
static void ChangePointClass(PointClass p) { p.X += 1; p.Y += 2; }
The output of this would be:
Point: (1, 2); PointClass: (2, 4).
When stack variables are passed as parameters (this is true in C#, Java, C++, etc.), they are copied onto the stack (if you disassemble native code, you'll see these as push [register] instructions). When the return value is done, the stack variable still refers to the original stack memory location. Only the copy is modified. When you push heap variables as parameters, though, the contents of the heap variable is modified. This can be better demonstrated in C++:
class Point
{
public:
int X, Y;
Point(int x, int y) { X = x; Y = y; }
}
int main()
{
Point stackVar(1, 2);
Point* heapVar = new Point(1, 2);
}
In this example, stackVar exists locally and will be copied to any functions that accept it as a parameter as a Point (as opposed to a Point&, which isn't the same thing). On the other hand, heapVar exists on the heap, which is why you need to use dereference syntax (heapVar->X = 2;) in order to get at its contents.
ANYWAY, the point of all this is: in Java, because of this design decision, you're not soon going to be able to create custom stack variable types (C# structs). Why? Because the Java compiler, in order to wrap them, must know the type of the reference type to which your stack type is boxed.
Oh, last thing - if you were to get the runtime type of a variable boxed in either Java or C#:
// java
ArrayList al = new ArrayList();
al.add(1);
al.get(0).getClass(); // returns the Type reference of Integer - you still need to cast it back to int.
// C#
ArrayList al = new ArrayList();
al.Add(1);
al[0].GetType(); // returns Int32, the C# alias for which is "int"
I don't have terribly much in the way of programming experience, was just pointing out something that I thought was wrong. Surprisingly, I think I undestood almost all of that, thanks! Learn something new every day :)
Quote from: MyndFyrex86/64] link=topic=9724.msg127825#msg127825 date=1187339816]
Oh, last thing - if you were to get the runtime type of a variable boxed in either Java or C#:
// java
ArrayList al = new ArrayList();
al.add(1);
al.get(0).getClass(); // returns the Type reference of Integer - you still need to cast it back to int.
Yeah. If it was of the paramaterized type ArrayList<Integer> the compiler would handle the casting for me though!