• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

.Net Statics

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    #11
    Originally posted by ASB
    Fair comment, but there are of course differing views.

    In this particular case the method has to retain state. Now I can retain it as a member in the class for example. However the issue with that is scope.

    Since it is only valid within the context of the method then I would prefer to reduce visibility to that method. If it's a member variable it's all too easy for somebody to come along and misuse it at a later date. Hence the thought of the static. Something I know you cannot do in C# (or couldn't).
    In which case as Weltchy suggested you need to store the state within the currently executing thread. In Java (sorry not a .NET developer) you have a ThreadLocal object (assuming it's the same idea as a ThreadStatic object) where you can store information that is specific to the current thread. If the thread re-enters the method it will be able to pick up it's own stored state, and any other thread would have it's own individual state.
    Listen to my last album on Spotify

    Comment


      #12
      Originally posted by Cowboy Bob
      In which case as Weltchy suggested you need to store the state within the currently executing thread. In Java (sorry not a .NET developer) you have a ThreadLocal object (assuming it's the same idea as a ThreadStatic object) where you can store information that is specific to the current thread. If the thread re-enters the method it will be able to pick up it's own stored state, and any other thread would have it's own individual state.
      Sounds about right. Just be careful if your using it within ASP.NET, as the thread you pickup will be different whenever you repost. However, if its a service component or winform, your fairly [thread]safe

      Comment


        #13
        Originally posted by DimPrawn
        Because you don't understand threading and the nature of Static data. Like most VB6 to VB.NET people.
        Perhaps. My take on it though is that he understands what it should do, and that the underlying VB.NET and CLR implementation does an unexpected hack which isn't capable of achieving what it should.

        Think outside the box...

        "In which case as Weltchy suggested you need to store the state within the currently executing thread. In Java (sorry not a .NET developer) you have a ThreadLocal object (assuming it's the same idea as a ThreadStatic object) where you can store information that is specific to the current thread."

        See above.

        Comment


          #14
          Yes I follow everything said and Weltchys point about thread static.

          But I still go back to what the documentation says:-

          "If the procedure is not Shared, its local variables are instance variables, including the Static variables."

          So, what my interpretation of this was is that it simply produced a member variable which was hidden from outside the method. It would be otherwise treated the same as any other instance variable. This is precisely what I wanted.

          Clearly the documentation simply lies.

          Comment

          Working...
          X