• 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 click through forms

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

    #11
    Originally posted by TimberWolf View Post
    Or to save using a timer, store the system time at form load and if the new form's button is clicked less than 200ms or so after form load, ignore it. 3 lines of code I expect.
    Can't remember off the top of my head what the resolution of DateTime is, in earlier .Net it was as large as 500ms. Stopwatch will use high def if it's available.
    Cooking doesn't get tougher than this.

    Comment


      #12
      display a small modal form saying "Loading..." for about 3secs when first button is pressed.

      Comment


        #13
        Originally posted by TheBigYinJames View Post
        Can't remember off the top of my head what the resolution of DateTime is, in earlier .Net it was as large as 500ms. Stopwatch will use high def if it's available.
        Ah, I see you'd proposed a similar and probably more exact solution earlier. My bad.

        Comment


          #14
          Originally posted by TheBigYinJames View Post
          Can't remember off the top of my head what the resolution of DateTime is, in earlier .Net it was as large as 500ms. Stopwatch will use high def if it's available.
          The precision has always been (according to the Docs) 100 Nanosecs. However there are some issues:-

          https://connect.microsoft.com/Visual...?wa=wsignin1.0

          Internally the stopwatch uses datetime.utcnow - which is precisely what datetime.now does.

          I doubt there is any difference in efficiency between datetime.now.subtract and using a stopwatch.

          Comment


            #15
            Originally posted by ASB View Post
            I doubt there is any difference in efficiency between datetime.now.subtract and using a stopwatch.
            Actually, there might be a slight overhead in loading the stopwatch wrapper object (needs to load the Diagnostics assembly?) so DateTimeNow.Subtract(someStoredVal) would probably be marginally quicker.

            I liked the modal dialogue suggestion.

            And all because the lady loves Milk Tray.
            Cooking doesn't get tougher than this.

            Comment


              #16
              Originally posted by TimberWolf View Post
              Or to save using a timer, store the system time at form load and if the new form's button is clicked less than 200ms or so after form load, ignore it. 3 lines of code I expect.
              btw stopwatch is not a timer. It is just a wrapper round datetime. It's lightweight. However it does some more calculations than would be done with using datetime.subtract.now.subtract.

              Comment


                #17
                Originally posted by TheBigYinJames View Post
                Actually, there might be a slight overhead in loading the stopwatch wrapper object (needs to load the Diagnostics assembly?) so DateTimeNow.Subtract(someStoredVal) would probably be marginally quicker.

                I liked the modal dialogue suggestion.

                And all because the lady loves Milk Tray.
                Out of interest (and boredom) I had a look at it in reflector. It does have a call to a kernel function on first instantiation to discover if it's high res or not. I it calls the same functions as datetime.now does in general. I think one would need a few hundred billion iterations to find a timeable difference though..

                Comment

                Working...
                X