[RESOLVED] Form class variables and static functions

I'll start by saying that I'm new to C# and to .NET, I'm used to VB6 where I've never worried about alot of this stuff much.

So, I have a class, say, Form1. Form1 has some public variables, say, variable1, and variable2. Now I also have a static function: public static int function1(int input1). Within function1's definition, I cannot access Form1.variable1, or Project1.Form1.variable1, and I was confused as to why. To work around, I added to the beginning of function1:

C# Code:

Form1 TempForm = (Form1)Form1.ActiveForm;

This works, but only to a point, and it comes down to the ActiveForm, I think. If I run the project and the activeform changes (in my case an activex control can open a form with settings for that control), the program crashes with a NullReferenceException at the point where it attempts to access TempForm.variable1. Presumably this is because the active form does not have this variable?

So my question is, how could/should I be accessing variables within a Form Class? Are you not meant to? This isn't limited to static functions either, I don't think, I really can't access them ever without using this or creating an instance like I did inside my example of function1. If what I did is alright to do, then how should I handle the activeform changing when you select a different form within the same project?

I guess I'm really just unfamiliar with creating instances properly in general, but since I've been using Forms alot, I've found it frustrating to access their variables, etc.

I also forgot to mention that I get warnings doing it the way I'm doing, talking about the possibility of a runtime exception regarding accessing the variables because they are fields of a Marshal-by-reference class. Can someone explain Marshaling briefly and how it is used?

I know this is alot to ask, but I think some simple code that works and is "right" can clear this all up for me.

Andrew

Yet another way to pose this question, more concisely, but I'm not sure if it is valid to ask:

How do you access an instance of a Form that is not currently active?

There is nothing special about a form. It's just an object like anything else.

If a static method needs to access instance data, it probably shouldn't be a static method. You need to evaluate carefully whether it makes more sense to make a method static or not.

Quote:

---

Originally Posted by penagate

There is nothing special about a form. It's just an object like anything else.

If a static method needs to access instance data, it probably shouldn't be a static method. You need to evaluate carefully whether it makes more sense to make a method static or not.

---

Yeah, I think the whole object thing was tripping me up a little.

I think now that what I was looking for was a workaround for bad programming. The functions and classes that I wanted accessing the Form's properties and variables probably shouldn't be accessing them anyway. It would be nice to know how to make them do that (gain access to a Form instance that is not active), just for my own undestanding, but in the end, I "fixed" my problem by removing the calls to the Form's variables/properties within the static functions/classes, making that function general, and doing the Form-specific work (that the functions/classes were doing) inside the Form itself, which is what I should have done in the first place.

If anyone still knows how to access a Form instance that is not active, I would still like to know, anyway.

Have a look at this

In answer to your question about referencing a form thats not active, you would need to use the following code:

Code:

---

            foreach (Form1 myForm in Application.OpenForms)
            {
              //basing it on only having 1 form1 open
                int myVar = myForm.Varible1;
            }

---

If your form is using variables that are used globally then maybe you should think about storing them in a shared class...

Woka

Quote:

---

Originally Posted by Wokawidget

In answer to your question about referencing a form thats not active, you would need to use the following code:

Code:

---

            foreach (Form1 myForm in Application.OpenForms)
            {
              //basing it on only having 1 form1 open
                int myVar = myForm.Varible1;
            }

---

If your form is using variables that are used globally then maybe you should think about storing them in a shared class...

Woka

---

Would you mind a quick explantion of a shared class? I'm not familiar with classes, I'm just beginning to understand them, so I don't really know the difference between partial, shared, etc, and how/when/why to use each.

Ignore partial classes. They are just used to write a class that spans multiple physical files...can't see the point in them myself.

A shared class replaces a module in VB6.

Code:

---

Public Shared Class MySharedClass
 
  Private _data as string

  Public Property Data() As String
      Get
        return me._data
      End Get
      Set(Byval value as string)
        Me._data = value
      End Set
  End Property
End Class

---

Then anywhere in your app you can do:

Code:

---

MySharedClass.Data = "Mooooo"

---

or

Code:

---

Dim myData as string = MySharedClass.Data

---

No need to declare an instance to the class because it's shared


Hope that helps.

Woof

Personally I do not see the point of making static classes. You can put static members within normal classes anyway. For most classes, it is ideal to have a mixture of both. When you add a method you should already have an idea in your mind of whether it should be static or instance. If it is not immediately obvious then you need to evaluate which would make more sense.

Have a look at the Framework classes such as String and Array for some examples of the different applications of static and instance methods.

Quote:

---

Originally Posted by penagate

Personally I do not see the point of making static classes. You can put static members within normal classes anyway. For most classes, it is ideal to have a mixture of both. When you add a method you should already have an idea in your mind of whether it should be static or instance. If it is not immediately obvious then you need to evaluate which would make more sense.

Have a look at the Framework classes such as String and Array for some examples of the different applications of static and instance methods.

---

I was following some examples for using APIs from user32.dll in C#. They used static functions/classes. I've never messed with them before, and it seems like a real headache. I really can't see where they would be useful either?

Sometimes it makes sense to make a function a member of an object. Other times it makes more sense to make it a member of a class.

Consider Array.Join and Array.Length. One's static and one's not. Do you see how it makes more sense for Join to be static, and Length to be an instance member?

Boooo...forgot u're doing c#.

Code:

---

Public Class MySharedClass
{
  private string _data;

  public string Data
  {
      get { return this._data; }
      set { this._data = value }
  {
}


}

---

Quote:

---

Originally Posted by penagate

Sometimes it makes sense to make a function a member of an object. Other times it makes more sense to make it a member of a class.

Consider Array.Join and Array.Length. One's static and one's not. Do you see how it makes more sense for Join to be static, and Length to be an instance member?

---

I agree...
However, if you have a set of varibles that are available to the application at a global level, and you don't have any specific class they can sit in, then a shared (static) class works just great.
It's not bad design, or bad functionality, it's just the way it is...not all variable.

Woof

Quote:

---

Originally Posted by penagate

Sometimes it makes sense to make a function a member of an object. Other times it makes more sense to make it a member of a class.

Consider Array.Join and Array.Length. One's static and one's not. Do you see how it makes more sense for Join to be static, and Length to be an instance member?

---

To be honest, no, I don't see, lol. I don't think I fully undestand static. My general understanding is that if a function is static, any variables, classes, etc must be fully written out?

Think of static function as being a function in a module in VB6.
Anywhere in your app you can simply call:

Code:

---

MyModule.MyFunction("Woof")

---

This function is generic and not really accociated to a physical object.

Think of a class as a class in VB6...almost the same.

A class in .NET can have both class functions and static functions.

so I could do:

Code:

---

User newUser = new User("Woka");
string username = newUser.Username;

---

but if i had a static function in the object User then I could also do:

Code:

---

User.SomeFunction("moo");

---

and I wouldn't have to create an instance of it.

I see it as a module overlaying a class if that makes sense :D


Pen - Why should Join be static...in fact...I think it should be an instance member imo...i think you may have given a bad example there....always a 1st for everything ;)

Moooooooo

Join should be static because the operation of joining two arrays (resulting in a new array) doesn't really belong to either of the original arrays. If it was "Append", that would make sense as an instance member.

Alright... another example:- a static 'constructor'. In some cases it makes sense to use a static method to create an object, rather than the New operator. For example, if you had a File class, you'd expect the new operator to create a new file. To get an object representing an existing file, you'd use a static method.

pseudo Code:

File
{
  public static File FromPath(Path path): return new File(path);
  protected File(Path path): // open the file yada yada
 
  public File(String filename): // create a file
};
 
// Create a file:
File woof = new File('woof');
woof.SaveTo('\\catsanddogs\woof');
 
// Get file information:
File moo = File.FromPath('\\badgerbadgerbadger\oddsandends\moooooooo');
moo.Attributes += FileAttributes.ReadOnly; //etc.

Now that's a better example ;)
...oh and I love the naming convention...lol

Code:

---

File
{
  public static File FromPath(Path path): return new File(path);
  protected File(Path path): // open the file yada yada

  public File(String filename): // create a file
};

// Create a file:
File woof = new File('woof');
woof.SaveTo('\\catsanddogs\woof');

// Get file information:
File woof = new File();
woof.Fetch('\\badgerbadgerbadger\oddsandends\moooooooo');

---

I think that is what 76.9% of people would do...I made up the 76.9% stat off the top of my head, but it's probably true.

I like the strictness of your code and the way it "gets around" a way to have 2 constructors with the same params.

But...that saying...there is still no reason for a 100% shared class...your method is great and a good example to go with it, but it still doesn't mean that you are forced to add shared functions in an instance class...I still see no reason why a 100% share class would be a bad thing.

Dancing Badgers

Quote:

---

Originally Posted by Wokawidget

Think of static function as being a function in a module in VB6.
Anywhere in your app you can simply call:

Code:

---

MyModule.MyFunction("Woof")

---

This function is generic and not really accociated to a physical object.

Think of a class as a class in VB6...almost the same.

A class in .NET can have both class functions and static functions.

so I could do:

Code:

---

User newUser = new User("Woka");
string username = newUser.Username;

---

but if i had a static function in the object User then I could also do:

Code:

---

User.SomeFunction("moo");

---

and I wouldn't have to create an instance of it.

I see it as a module overlaying a class if that makes sense :D


Pen - Why should Join be static...in fact...I think it should be an instance member imo...i think you may have given a bad example there....always a 1st for everything ;)

Moooooooo

---

So basically static functions DO NOT need an instance of the object, and class (or instance) functions DO need an instance?

And you would want to use static functions when the function does not pertain only to the class object, but if the function pertains directly to the class object you would use a regular class (instance) function?

So this would be correct to be a static, then?

C# Code:

public static bool DoAnd(bool in1, bool in2)
{
 if (in1 && in2)
   return true;
 else
   return false;
}

And then it could be used as (without needing an instance):

C# Code:

bool IsItTrue;
 
IsItTrue = WhateverClass.DoAnd(true, true);

err....yes.
errr...yes.
and...errrr..yes.


:D

Wooof

Just on the note of static classes, the point of a static class is so you can NOT create an instance. It's a statement that an instance of that type serves no useful purpose. Sure you can just have a non-static class with static members, but then it is possible to create an instance of that class. That doesn't necessarily cause a problem but if it can't serve a useful purpose then it's not a bad idea to prevent it. Note that VB.NET cannot create a Shared class. That's because VB.NET has modules. They serve the same purpose.

Quote:

---

Originally Posted by jmcilhinney

Just on the note of static classes, the point of a static class is so you can NOT create an instance. It's a statement that an instance of that type serves no useful purpose. Sure you can just have a non-static class with static members, but then it is possible to create an instance of that class. That doesn't necessarily cause a problem but if it can't serve a useful purpose then it's not a bad idea to prevent it. Note that VB.NET cannot create a Shared class. That's because VB.NET has modules. They serve the same purpose.

---

Ah, thanks. Putting it that way actually clears it up even further!

One last question guys, while I sorta have you on the topic. The shared class thing.... so based on the code woof posted, it seems that a shared class is nothing more than a regular normal old class but you can created variables that are accessible to other classes using get and set? So to make any otherwise normal class a shared class, you add one or more get/set variables?

Quote:

---

Originally Posted by pjrage

Ah, thanks. Putting it that way actually clears it up even further!

One last question guys, while I sorta have you on the topic. The shared class thing.... so based on the code woof posted, it seems that a shared class is nothing more than a regular normal old class but you can created variables that are accessible to other classes using get and set? So to make any otherwise normal class a shared class, you add one or more get/set variables?

---

I'm afraid that's not it all. What you're talking about is just a property. Properties can be Shared or not. Like I said, VB.NET cannot create Shared classes but we'll use the term all the same, because C# can create static classes, which are the same thing.

Now, a class can have properties and most do. A class can have instance properties and/or Shared properties. Shared properties are members of the class itself, while instance properties are members of each individual instance. A Shared class can have only Shared properties. You aren't supposed to create an instance of a Shared class so instance members are not allowed.

Quote:

---

Originally Posted by jmcilhinney

Like I said, VB.NET cannot create Shared classes but we'll use the term all the same, because C# can create static classes, which are the same thing.

---

How about we use the term 'static' because we're in the C# section? :)

Quote:

---

Originally Posted by pjrage

Ah, thanks. Putting it that way actually clears it up even further!

One last question guys, while I sorta have you on the topic. The shared class thing.... so based on the code woof posted, it seems that a shared class is nothing more than a regular normal old class but you can created variables that are accessible to other classes using get and set? So to make any otherwise normal class a shared class, you add one or more get/set variables?

---

You were correct in #18. Go back to that post. :)

Quote:

---

Originally Posted by penagate

You were correct in #18. Go back to that post. :)

---

How does shared play into that, though?

Shared and static are the same thing?

Static class == Shared class?

Tomato, Tomotto?

VB.NET = Tomatoe
C# and just about every other OO language = Tomato


What VB.NET calls "Shared" is static. What VB.NET calls "Static" is something completely different (local variables that persist across method calls). One of the many reasons I don't really like VB.NET, but whatever.

Quote:

---

Originally Posted by penagate

How about we use the term 'static' because we're in the C# section? :)

---

Oh b*gger! We are too. I often miss that fact when I get to a C# thread from the UserCP. :blush: Sorry about confusing the issue like that. Wherever I said "Shared" just think "static".

OK, a class can have static members and/or instance members. Static members are members of the class itself, so you call them on the class itself. Application.StartupPath is an example. You don't create an instance of the Application class and get its StartupPath property. You get the StartupPath property of the Application class itself. Instance members are members of specific instances of the class, so you must create an instance first and then access the member.

Static classes are specifically declared static. A regular class can have nothing but static members but you can still create an instance of that class. A static class cannot contain instance members and you cannot create an instance. As I said, a static class is basically equivalent to a VB module.

Now that I've repeated what everyone else said and hopefully undone any damage I did with my use of the word "Shared"...

Thanks again guys, you have really cleared things up for me :)