Newbie Modulus Animation WTF

sirhegel

I found the following awesome algorithm in one of our products. The code was written by a newbie, and since it "works", it is not a true WTF, just a funny over-complex solution to simple problem.

Imagine you have a long running application. Could it be nice to indicate the end user somehow that the application has not crashed, but is still actually doing something? Wo-hoo, got an idea, you could run an ASCII animation of some sort in the status bar! That can be easily accomplished by a neat function, like following (feel free to use it in your own software!):

Public Shared Tim As Date
Public Shared ApplicationIsRunning = True

    Private Sub StatusRunningText(ByVal Str As String)
        If ApplicationIsRunning = True Then
            Select Case Me.Tim.Now.Second
                Case 0, 3, 6, 9, 12, 16, 19, 21, 24, 27, 30, 33, 36, 39, 42, 45, 48, 51, 54, 57, 59
                    Me.StatusBarPanel1.Text = Str + "."
                Case 1, 4, 7, 10, 13, 17, 20, 22, 25, 28, 31, 34, 37, 40, 43, 46, 49, 52, 55, 58
                    Me.StatusBarPanel1.Text = Str + ".."
                Case Else
                    Me.StatusBarPanel1.Text = Str + "..."
            End Select
        End If
   End Sub

Note the ingenious fact, that the (global!) Tim variable has to be updated and this method has to be called repeatedly by some other routine to actually see some animation.

FraGag

@sirhegel said:

Note the ingenious fact, that the (global!) Tim variable has to be updated and this method has to be called repeatedly by some other routine to actually see some animation.

Actually, Now is a static (shared in VB (how many times have I seen that in the MSDN Library?)) property, thus the Tim variable is totally useless: replace Me.Tim.Now.Second with Date.Now.Second or DateTime.Now.Second.

Also, I've noticed that the values in the Case statements are not even following a rule: 0, 3, 6, 9, 12, 16, 19, 21, ... and the final 59. If this was wanted, then the modulus solution doesn't work, but I believe these are mistakes.

xrT

@sirhegel said:

Public Shared Tim As Date
Public Shared ApplicationIsRunning = True

    Private Sub StatusRunningText(ByVal Str As String)
        If ApplicationIsRunning = True Then
            Select Case Me.Tim.Now.Second
                Case 0, 3, 6, 9, 12, 16, 19, 21, 24, 27, 30, 33, 36, 39, 42, 45, 48, 51, 54, 57, 59
                    Me.StatusBarPanel1.Text = Str + "."
                Case 1, 4, 7, 10, 13, 17, 20, 22, 25, 28, 31, 34, 37, 40, 43, 46, 49, 52, 55, 58
                    Me.StatusBarPanel1.Text = Str + ".."
                Case Else
                    Me.StatusBarPanel1.Text = Str + "..."
            End Select
        End If
   End Sub

<FONT face=tahoma,arial,helvetica,sans-serif>Reminds me of my college days, back when we we're being taught VB6. Almost all of my class and pet projects that needs "some sort of animation" are driven by timers that constantly checks for a global variable and performs certain "animations" based on its value. I remember once I created an "animated logo" by creating a dozen bitmaps (with slight changes in position, color, etc), adding a timer then finally looping through these pictures.

Ah, the memories...

</FONT>

sirhegel

I found it particulary astonishing, how the computationally expensive modulus operation was replaced with much faster manually calculated value, which undoubtedly gives a huge increase in performance. This algorithm can be used easily in similar cases, such as if some task has to be executed every third day of a year, you just have to add more cases.

cavemanf16

@FraGag said:

@sirhegel said:

Note the ingenious fact, that the (global!) Tim variable has to be updated and this method has to be called repeatedly by some other routine to actually see some animation.
Actually, Now is a static (shared in VB (how many times have I seen that in the MSDN Library?)) property, thus the Tim variable is totally useless: replace Me.Tim.Now.Second with Date.Now.Second or DateTime.Now.Second.
Also, I've noticed that the values in the Case statements are not even following a rule: 0, 3, 6, 9, 12, 16, 19, 21, ... and the final 59. If this was wanted, then the modulus solution doesn't work, but I believe these are mistakes.

My guess is that this 'Tim' character actually did some rudimentary testing with his new algorithm and found that the milliseconds of delays in all this case checking in VB added up over the first 12 or so seconds, and actually resulted in a 1 second delay. Therefore, to make it not look f'd up to the end user (because the Me.Tim.Now.Second call wasn't returning 15 and correctly printing "..", but rather it was returning 16 and defaulting to the "else" case statement to print "...") he just padded his case statement with that 1 second delay, adding "16" as the next instance of printing ".." instead of using "15". Same thing occurs again at the value of "59" as you noticed, and then he adjusted the whole thing to at least get it to display correctly.

Granted, the whole thing is needlessly complex, but at least give the guy props for unit testing! ;)

sycro

@cavemanf16 said:

@FraGag said:
@sirhegel said:

Note the ingenious fact, that the (global!) Tim variable has to be updated and this method has to be called repeatedly by some other routine to actually see some animation.
Actually, Now is a static (shared in VB (how many times have I seen that in the MSDN Library?)) property, thus the Tim variable is totally useless: replace Me.Tim.Now.Second with Date.Now.Second or DateTime.Now.Second.
Also, I've noticed that the values in the Case statements are not even following a rule: 0, 3, 6, 9, 12, 16, 19, 21, ... and the final 59. If this was wanted, then the modulus solution doesn't work, but I believe these are mistakes.

My guess is that this 'Tim' character actually did some rudimentary testing with his new algorithm and found that the milliseconds of delays in all this case checking in VB added up over the first 12 or so seconds, and actually resulted in a 1 second delay. Therefore, to make it not look f'd up to the end user (because the Me.Tim.Now.Second call wasn't returning 15 and correctly printing "..", but rather it was returning 16 and defaulting to the "else" case statement to print "...") he just padded his case statement with that 1 second delay, adding "16" as the next instance of printing ".." instead of using "15". Same thing occurs again at the value of "59" as you noticed, and then he adjusted the whole thing to at least get it to display correctly.
Granted, the whole thing is needlessly complex, but at least give the guy props for unit testing! ;)

You can't give somebody props for something you assume they may have done. Also, your guess makes no sense given his use of 21. Would it be confusing to go from "." to "...", but not to go from ".." back to "." ?

Edgesmash

@sycro said:

@cavemanf16 said:
@FraGag said:
@sirhegel said:
Note the ingenious fact, that the (global!) Tim variable has to be updated and this method has to be called repeatedly by some other routine to actually see some animation.
Actually, Now is a static (shared in VB (how many times have I seen that in the MSDN Library?)) property, thus the Tim variable is totally useless: replace Me.Tim.Now.Second with Date.Now.Second or DateTime.Now.Second.
Also, I've noticed that the values in the Case statements are not even following a rule: 0, 3, 6, 9, 12, 16, 19, 21, ... and the final 59. If this was wanted, then the modulus solution doesn't work, but I believe these are mistakes.

My guess is that this 'Tim' character actually did some rudimentary testing with his new algorithm and found that the milliseconds of delays in all this case checking in VB added up over the first 12 or so seconds, and actually resulted in a 1 second delay. Therefore, to make it not look f'd up to the end user (because the Me.Tim.Now.Second call wasn't returning 15 and correctly printing "..", but rather it was returning 16 and defaulting to the "else" case statement to print "...") he just padded his case statement with that 1 second delay, adding "16" as the next instance of printing ".." instead of using "15". Same thing occurs again at the value of "59" as you noticed, and then he adjusted the whole thing to at least get it to display correctly.
Granted, the whole thing is needlessly complex, but at least give the guy props for unit testing! ;)
You can't give somebody props for something you assume they may have done. Also, your guess makes no sense given his use of 21. Would it be confusing to go from "." to "...", but not to go from ".." back to "." ?

Sycro, I think he's being sarcastic... just a little bit ;)