What is the best way to Pause/Resume/Stop the current program?

[*PsyKE1*]

Imagine I have a program which has a big ammount of functions and procedures with a lot of loops.

Then I want to add four buttons:

• One to Start the process of my program (is an algorithm which takes minutes)
• Another one to Stop the process of my algorithm.
• Another one to Pause my process of my algorithm.
• And the last one to Resume the process of my algorithm wherever it has been stopped after.

I thought adding a variable in each loop to test if the algortihm has to continue is not the best way to do it.
And I'm afraid by this way I can't also Pause/Resume the algorithm, only Stop it, obviusly.

Any idea to do it?

[passel]

Would be pretty easy in VB.Net, with a background thread doing the processing, and a synchronizing object (a semaphore for example) to control pausing or resuming at different parts.

I don't know how you're doing your processing now in VB6, but in order to have the GUI active while you're processing I assume you must have some DoEvents in there.
I would think that inside your loops, at the point where you want to check for a pause/resume condition (it seems like Stop should quit the process, otherwise it would be the same as pause) you would have to have an idle condition, so if the pause is not active, you do your code, else (you're paused), so do an API sleep for 100ms and a DoEvents, and loop back up to check your pause condition again.
So, if you're paused you just take very short naps wake up and check it it time to start working again and if not, take another nap.

[LaVolpe]

Staying with a standard EXE, another option would be to use a timer, but would really require some creative organization. The timer when not paused would equate to resume. When the timer enters, the timer would be turned off and a loop of the process completes, the timer activated again on exit. You can see how complicated a design like this would be.

[Bonnie West]

Using a Timer control (or, if you prefer, the SetTimer API) is indeed the technique that is recommended the most by the VB6 manual. Here's an example:

Assuming your current code looks roughly like this:

Option Explicit

Private m_Stop As Boolean

Private Sub cmdStartLoops_Click()           '<-- CommandButton
    Dim i As Long, Item As Variant

    Do: While True
            With New Collection
                For Each Item In .[_NewEnum]
                    For i = 0& To .Count
                        If Not m_Stop Then
                            DoEvents
                        Else
                            Exit Sub
                        End If
                    Next
                Next
            End With
        Wend
    Loop Until False
End Sub

Private Sub cmdStopLoops_Click()
    m_Stop = True
End Sub

When using a Timer control, you'll restructure it in a way similar to the following:

Option Explicit

Private Sub chkStartPauseLoops_Click()      '<-- CheckBox
    tmrLoops.Enabled = chkStartPauseLoops.Value = vbChecked
End Sub

Private Sub tmrLoops_Timer()                '<-- Timer
    Static i As Long, Item As Variant       '<-- Persist variables' values between Timer() events

   'Do                                       <-- The outermost loop has been replaced by tmrLoops
        While True
            With New Collection
                For Each Item In .[_NewEnum]
                    For i = 0& To .Count
                       'If Not m_Stop Then   <-- The module-level variable m_Stop is no longer required
                       '    DoEvents         <-- No longer necessary
                       'Else
                       '    Exit Sub
                       'End If
                    Next
                Next
            End With
        Wend
   'Loop Until False
End Sub

Regarding toggling the Timer control when entering/exiting its Timer event, the following test code demonstrates that it is probably unnecessary:

Option Explicit 'In a blank Form

Private WithEvents List1  As VB.ListBox
Private WithEvents Timer1 As VB.Timer

Private Sub Form_Load()
    Set List1 = Controls.Add("VB.ListBox", "List1"): List1.Visible = True
    Set Timer1 = Controls.Add("VB.Timer", "Timer1"): Timer1.Interval = 1&
End Sub

Private Sub Form_Resize()
    List1.Move ScaleLeft, ScaleTop, ScaleWidth, ScaleHeight
End Sub

Private Sub List1_MouseDown(Button As Integer, Shift As Integer, X As Single, Y As Single)
    Timer1 = Not Timer1
End Sub

Private Sub Timer1_Timer()  'The Timer() event raised by the Timer control doesn't appear to be recursive
    Dim T!: Static C%

    C = C + 1
    List1.AddItem "Entered  " & C

    T = Timer + 3!          'Loop for 3 secs.
    Do:  DoEvents
    Loop Until Timer > T

    C = C - 1
    List1.AddItem "Exiting  " & C
End Sub

The VB6 doc mentioned this Timer behavior in Allowing Users to Interrupt Tasks:

When the Timer event gets control, allow it to run slightly longer than the time you specified for the Interval property. This ensures that your background task will use every bit of processor time the system can give it. The next Timer event will simply wait in the message queue until the last one is done.

[passel]

I can't believe some of the things that are posted by MSDN, whose people you would think should know better.

... The next Timer event will simply wait in the message queue until the last one is done.... Use a fairly large value — five to ten seconds — for the timer's Interval property, as this makes for more efficient processing....

Back when VB was young it was often written about how the timer worked, and the next Timer event is not waiting in the message queue until the last one is done.
The next timer interval doesn't start until the last one is done, which is why you don't have a recursive problem with DoEvents in a timer.

If you followed his advice you would have set your timer interval to something short of your three seconds of work.
But if you did that, you would do three seconds of work, leave the timer, the timer would be rearmed and somewhat less than three seconds later you would get the event to do more work.
A timer event will never queue up while you are in the timer. The time spent in the timer doesn't count. When you choose an interval, what you are choosing is the interval between the exit of the timer event until the start of the next.

To get the most work done, you need to choose as short a time as possible, as you did selecting an interval of 1. Larger intervals are just defining how much time you won't work be working.

If you have code that takes 50 ms to process, and you set the timer to tick at 100ms, you won't be running every 100ms, but 50ms + 100ms. The Timer is suspended while you are in the timer event, so time is not passing as far as the timer is concerned.

[DataMiser]

I remember running into some re-entrant issues back in VB5 that are not present in VB6 but can't clearly remember what they were. Sometimes though it seems that the docs for some things were not updated for VB6.