[02/03] Progress Bars

[SomethinCool]

I have a function in a module that iterates through a large chunk of code. I have a progress bar on one of the windows forms that I would like to update when this function is called, but I don't know how to access the properties of the progress bar in order to update the value of it.

How can I access a progress bar from a form in a module?

[circuits2]

Can you be more specific? Where is the progress bar in relation to the function? Which form is calling the function? Are you using an MDI container? Are you using threading?

[kleinma]

you can either pass a reference to the progressbar into the given routine in the module, and have the routine itself update the progressbar. This would likely require doevents to be called to allow the message pump to not get blocked and keep updating the UI.

The other alternative is to use a background worker to use threading and report progress so you can update your UI.

[SomethinCool]

How would I use a background worker and threading support? I believe I tried using threads before and failed miserably. Can you please explain how I could do this?

Also, what would be the alternative? Creating a public property of the progress bar value then calling Application.DoEvents() when necessary?

[circuits2]

Matt I thought the backgroundworker was new with 2.0.?

[kleinma]

yes it is...

I didn't notice it was 1.1..

which means you would have to use threads and implement the UI updating code yourself using invokes.... there is an article on MSDN on how do do that using threads.

[SomethinCool]

Ok... i'm still a little confused as to how to use threads. How do multiple threads work at the same time on a machine that only allows one thread to process at a time? Is this where the MS Message Queuing service is used?

[kleinma]

what machine do you have that only allows one thread to process at a time? it must be ancient

Many applications, including Windows itself are mulithreaded. VB just never really had multithreading capabilities before .NET. Other languages have had it for some time...

There are a bunch of tutorials on the web for doing multithreading in VB.NET

I have been using 2005 for sometime, so I am not sure what differences there are in 2003 versus 2005. I know they cleaned up some of the threading stuff between versions.

[robertx]

I use the pass by reference method as follows:

 Public Sub UpdateProgressBar(ByRef myProgressBar As ProgressBar)
        Dim i As Integer, iRecordCount As Integer

        'Set record count here
         iRecordCount = 100000

        For i = 0 To (iRecordCount - 1)
            'do something here

            'increment progress bar
            myProgressBar.Value = ((i + 1) * 100) / iRecordCount
            Application.DoEvents()
        Next
    End Sub

[jmcilhinney]

I use the pass by reference method as follows:

 Public Sub UpdateProgressBar(ByRef myProgressBar As ProgressBar)
        Dim i As Integer, iRecordCount As Integer

        'Set record count here
         iRecordCount = 100000

        For i = 0 To (iRecordCount - 1)
            'do something here

            'increment progress bar
            myProgressBar.Value = ((i + 1) * 100) / iRecordCount
            Application.DoEvents()
        Next
    End Sub

There is no reason to pass the parameter by reference. You can set properties of the ProgressBar just the same when passing it by value. If you pass it by reference you are enabling the method to pass out a different ProgressBar than what was passed in. That is obviously not what you want.

[robertx]

In this case I only want a pointer to the progress bar - I don't need to pass a copy. Since the purpose of the procedure is only to amend the progress bar's Value property, what is different about the progress bar that is returned to the calling procedure except that it's Value property has been changed to 100? I can't see any advantage in passing the progress bar ByVal as opposed to ByRef.

[jmcilhinney]

In this case I only want a pointer to the progress bar - I don't need to pass a copy. Since the purpose of the procedure is only to amend the progress bar's Value property, what is different about the progress bar that is returned to the calling procedure except that it's Value property has been changed to 100? I can't see any advantage in passing the progress bar ByVal as opposed to ByRef.

You are confused as to how passing by value and by reference works. ProgressBar is a class so it's a reference type. That means that a ProgressBar variable contains a reference to a ProgressBar object. It does NOT contain a ProgressBar object itself. A reference is basically a pointer, so ALL variables whose type is a class are pointers.

When you pass a parameter to a method, whether you pass it by reference or by value affects the variable you're passing. If you pass by value then you make a copy of the variable and pass that. If your variable is a pointer to a ProgressBar then you're making a copy of a pointer, not a copy of a ProgressBar object. If you pass the variable by reference then you're passing a pointer to the variable, so a pointer to a pointer.

If your variable is a value type rather than a reference type then the variable contains the value itself rather than a pointer to an object. If you pass a value type variable by value then you're creating a copy of the value. If you pass a value type variable by reference then you're creating a pointer to the value.

It is simply not possible to pass an actual reference type object in .NET code because reference type objects are always accessed via a reference.

[robertx]

OK. I follow. I passed the progress bar ByVal and ByRef and tested the Value property.

UpdateProgressBar(ProgressBar1)
MsgBox ProgressBar1.Value

In both cases the message box displayed "100" which is consistent with what you have described. Given that the outcome is the same, is there any advantage using ByVal and any disadvantage using ByRef in this instance?

I was so used to using ByRef in VB6 as it was the default that I have continued to use it as the default unless I specifically want to pass ByVal - that is when I don't want the value of the passed variable to be changed.

What was MS's rationale for changing the default to ByVal?

[jmcilhinney]

You should always pass everything by value unless you specifically want the value of the variable being passed to be changed. Note that I said "the value of the variable". If the variable is a reference type then the value it contains is the memory address of an object. Only if you want to be able to pass out a different object to what was passed in should you pass by reference.

Anyway, this is quite a way off topic so I'll leave it there. If you have any further questions on this topic then I'd suggest starting a new thread.

[SomethinCool]

what machine do you have that only allows one thread to process at a time? it must be ancient

I thought all Intel x86 CISC processors allow only one thread to be processed at a time until hyperthreading and multi-core processors were produced. I thought thats why Windows had a messaging queuing service as the OS could multi task, but the computer couldn't execute multiple threads at a time due to the limitations of the architecture. Am I wrong by this?

Also, the code that robertx posted confuses me as to how I can implement it into my project. Here is a sample of what I am doing:

'Here is code on frmMain
Private Sub tmrConnect_Tick(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles tmrConnect.Tick
Dim msgsNotFound As Boolean
 
        msgsNotFound = BeginDownloadMessages()
 
        If msgsNotFound = True Then
            txtActivity.Text = txtActivity.Text & vbNewLine & DateAndTime.Now & " No messages found in inbox!" & vbNewLine & DateAndTime.Now & " Disconnecting..."
            Exit Sub
        End If
 
        EndDownloadMessages()
 
        WriteEMLFilesToDisk()
 
        DisconnectFromPOP3Server()
 
        SortEmail()
End Sub

Each of those functions are public functions in a module. I would want to update the progressbar while the code is running depending on how many messages are in the inbox, how far it executes the code, etc. Does this require the use of another thread?

[SomethinCool]

Anyone have any ideas?

[Phill64]

as for your hyperthreading questin.. no, machines have for used used multi-threading, remember that multi-threading is the process of quantum timing, meaning (scenario only its a bit more complex!) The cpu processes one line of code from your program, then it processes one line of windows code, then one line of msn code, and any other app running on your pc.. hence why all programs run slwoer when you have many running on your machine at once.

As for a problem with the arch... maybe you're confused with vb6 not being multi-threading.

the recent hyperthreading cpus means the processor itself acts like 2 cpus, doubling its power. put simply, another thread, is another app... its not much different than opening your program twice, you can obviously run multiple apps on your pc, so you can multi-thread.

As for threading in vb03, yurk definately read carefully in msdn about referencing accross threads, i have on occasions done it a lazy way, having an error handle loop and simply retrying at interval if theres a thread access error

also, no you don't need another thread, this was just a suggestion, so that your GUI can still run hwile the operation is running. Sometimes (we have no idea your circumstance) it's best not to allow the rest of your ap pto run, maybe it depends o nthis function ending for example. To do this I would create a form, with a progress bar on it, and probably a label on it to for reporting status, call your form ProgressForm.

In your module simply

Dim pbar as new ProgressForm
'do
   pbar.progressbar1.value =
   pbar.refresh() 'allow form to update so user can see it
'while
pbar.dispose