Results 1 to 7 of 7

Thread: [2005] Question about static(shared) classes, functions and declarations

  1. #1

    Thread Starter
    Lively Member
    Join Date
    May 2007
    Posts
    87

    [2005] Question about static(shared) classes, functions and declarations

    I dont realy have a problem or something but i am just wondering since i always have 1 class with shared(static) functions in it that dont need any other data stored or used by your program like age calculations from an vb.net DATE type or creating a "money string" from an integer or double that will always end with 2 decimals(like input 7.1 = "7.10").

    I noticed like a everyone else that if you want to use a form ,created by the designer, that you dont need to declare a NEW form wich means that forms and all of the controls are static/shared(correct me if i am wrong).

    But when i declare variables or functions then i dont declare them as static but just like: Dim myString as String. Isnt it better to use : private shared myString as string?

    Well i noticed olso that when you want to read-out or write values from your form in your own created classes that it gives a lot of trouble because sometimes(cant come up with an example atm) it just wont work.

    So this has something to do with that forms are static or?

    Maybe i didnt made myself clear enough so feel free to ask

    Greets

  2. #2
    Frenzied Member
    Join Date
    Mar 2006
    Location
    Pennsylvania
    Posts
    1,069

    Re: [2005] Question about static(shared) classes, functions and declarations

    You do have to create a new Form. The form created by Visual Basic when you create a Windows Forms Application create a class that inherits from Form. That basically makes that class a Form. In the OnCreateMainForm sub, the main form is set to your form class, which makes that form start up when the application starts.

    Not all the methods and properties in the Form class are shared, as you can see from the intellisense. Almost none of them are.

    You should not design classes with only shared variables and functions. Public shared members are able to be accessed by the class name and not the instance. The only time these are really used are with such things as calculations where creating an instance would just be cumbersome. Would it really make sense to do this?

    Dim mathHelper As New Math
    mathHelper.Abs(-5)

    It just doesn't. That's why Abs is a shared function. Usually helper classes are shared classes or contain shared methods. You'll notice that you'll have a lot of helper classes if you design a game, and that's perfectly fine, but if you want something such as Item or Monster, it only makes sense to make them instances. For example, you have 3 instances of a monster. You can access each monster's location from the monster instance variable. It just wouldn't work if Monster was a shared class.

  3. #3
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    40,109

    Re: [2005] Question about static(shared) classes, functions and declarations

    Quote Originally Posted by ovanwijk
    I noticed like a everyone else that if you want to use a form ,created by the designer, that you dont need to declare a NEW form wich means that forms and all of the controls are static/shared(correct me if i am wrong).
    This is a very unfortunate situation, in my opinion. In versions before 2005 you actually did have to create an instance of a form (with New) before you could use it. Beginning with 2005, MS decided to create default instances. When you define a form, you get a default instance. What this means is that there is one instance of the form created at startup which you can use. This instance has the same name as the class name. This is why you can do something like this:

    Form1.Property = whatever.

    Prior to 2005, you had to create a specific instance of Form1 before you can use it:

    Dim nf as New Form1

    nf.Property = whatever.

    I was really unhappy about the change because it can confuse people. If you aren't familiar with OO, you can get confused between a class and an instance. A class is just the definition for an object, it isn't an instance of the object. To create an instance of a class with that definition, you have to create an instance with New. Now, in 2005, this is true for all classes...except for forms where there is a default instance that happens to have the same name as the class. If you know what it's doing, it's just annoying, if you don't know what it's doing then this behavior is downright confusing.

    Shared members and shared classes are not like that (though they are close). A shared member is shared between all instances of a class. Therefore, if you have a class like this:

    Public Class someClass
    Public Shared Blue as integer = 1
    End class

    Then all instances have a member Blue, which is an integer, and for all instances, the value of blue is 1. If you change this value in one instance, you change it in all instances.

    This has some interesting implications. When you create an instance of a class, the compiler sets aside sufficient memory to hold an instance of that class (that's the dim statement) and fills the memory with an instance (that's the New statement). This means that if you create two instances of the class above, there will be two different chunks of memory filled with two instances of the class, but both instances need to have Blue, and it has to be the exact same Blue, not a copy. If you think about that, you will realize that Blue has to exist before either instance of the class. After all, if it was just created when the first instance of the class was created, then if that first instance was destroyed, Blue would be destroyed, and that can't happen, because another instance of the class might be created, so Blue has to be still hanging around.

    Therefore, Shared members are actually created as the program is started so that they exist by the time the first line of code is executed (that first line might reference them).

    Shared functions in a class work the same way. You don't actually need an instance of the class to exist to use them, because they have to exist prior to the starting of the program. The same is true with a shared class. One side effect of this is that all modules are shared classes with shared members. You don't actually see that, but it's true.
    My usual boring signature: Nothing

  4. #4
    Frenzied Member
    Join Date
    Mar 2006
    Location
    Pennsylvania
    Posts
    1,069

    Re: [2005] Question about static(shared) classes, functions and declarations

    Great post, Shaggy. Any idea why Microsoft did this? It seems to have done more harm than good, and made even more ambiguities.

  5. #5

    Thread Starter
    Lively Member
    Join Date
    May 2007
    Posts
    87

    Re: [2005] Question about static(shared) classes, functions and declarations

    Yeah, well then that is indeed what confused me .
    Cause i thought they became shared classes(cause of the way you use them).

    It like this:


    Where gray is the static area.

    Greets

  6. #6
    Frenzied Member
    Join Date
    Mar 2006
    Location
    Pennsylvania
    Posts
    1,069

    Re: [2005] Question about static(shared) classes, functions and declarations

    Yeup. I don't think C# has a default instance "feature." Lucky us :P

  7. #7
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    40,109

    Re: [2005] Question about static(shared) classes, functions and declarations

    I believe they did it because VB6 had them. In VB6, you could actually use the New keyword, but I, along with many others, couldn't figure out why you ever would. You certaintly didn't need the word in 99.9% of all situations, but every now and then you actually did need them. The model wasn't really the same, as VB6 wasn't an OO language, but prior to 2005, you had to use New for EVERY instance of EVERY class, including every form. This was one of the most common questions on this forum prior to the advent of 2005. Now we tend to see questions from people who atarted in 2005, and were misdirected by the default instances, which totally obscure the nature of forms, and allow people to learn the wrong lesson.

    Ovanwijk was using his head, but because MS made one specific (and common) type of class work in a different way from all others, he took a wrong turn.
    My usual boring signature: Nothing

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width