get progress boar progress to the form, from another class.

[sapator]

Hi.
So I have a form and the form calls another class.
The issue is that the progress board is not getting updated with the values (it actually shows but the green counter is not updating).
Another note. I can see the counter updating if i run it on debug an see one by one the values, but at real time it just show empty.

Here is some code:

'Form
  Dim LDMS As New List(Of DMS)
        If cGeneral.FillDMS(DtSet, LDMS, Me, iexcelcount) = False Then
         
            Me.Close()
            Exit Sub
        End If

So I call the FillDMS function from another class.

  Friend Function FillDMS(ByVal ds As DataSet, ByRef DMSList As List(Of DMS), ByRef frm As Form2, i As Integer) As Boolean
        Dim Dt As New DateTime
        Dim strDateFrom As String
        Dim dc As Double

        frm.ProgressBarExcelLoad.Visible = True
        frm.ProgressBarExcelLoad.Minimum = 1
        frm.ProgressBarExcelLoad.Maximum = i
        frm.ProgressBarExcelLoad.Value = 1
        frm.ProgressBarExcelLoad.Step = 1

   Try

            For Each row As DataRow In ds.Tables("Voucher").Rows

''etc
  DMSList.Add(cl)
                frm.ProgressBarExcelLoad.PerformStep() ' step + 
next

return

I used both byref and byval for the form btw.
any idea?
thanks.

[jmcilhinney]

Firstly, that class should not know anything about any form. The proper way to do that would be for the class to raise an event when the progress of the operation has changed and then to have the form handle that event and update it's own ProgressBar.

Secondly, you're not going to see any control change when you are executing a loop on the UI thread. I'm surprised that you don't know this already but updating of the UI is done on the UI thread so it can't happen if the UI thread is busy doing something else. You can force it by calling the Refresh method of the control but it would be far better to avoid doing the heavy work on the UI thread in the first place.

[sapator]

Hmmm.
OK if I put a thread sleep I can see it loading.
It probably loads to fast to see or draw.
Also I have putted everything in the main form and I just left the frm.ProgressBarExcelLoad.PerformStep() is the function.
I could use a background worked but that is another story.

I would leave this open for a while so if that is not what needs to be done , comment are welcome.
Thanks.

[jmcilhinney]

You should also know that passing ByRef is of no value whatsoever there. The ONLY reason to declare a parameter ByRef if the data type of that parameter is a class is to be able to assign a new object to the parameter inside the method and have that change affect the original variable. If you're not assigning anything to a reference type parameter in a method then declaring that parameter ByRef CANNOT have ANY effect and should not be done.

[sapator]

OK.
Well thanks JMC.
Won't raising the event slow things down a lot (going back and forth on the form)?

I should have known about the UI thread but it has been about 7 years since I used winforms so, did not remember.
thanks for bringing it to my attention.

[jmcilhinney]

Hmmm.
OK if I put a thread sleep I can see it loading.
It probably loads to fast to see or draw.
Also I have putted everything in the main form and I just left the frm.ProgressBarExcelLoad.PerformStep() is the function.
I could use a background worked but that is another story.

I would leave this open for a while so if that is not what needs to be done , comment are welcome.
Thanks.

Actually, there may be some multi-threading built into the ProgessBar itself because I do know that a ProgressBar may not actually display an accurate representation of its Value. That's only going to make things worse though, not better.

[jmcilhinney]

Won't raising the event slow things down a lot (going back and forth on the form)?

I'd suggest that if it did affect things noticeably then the amount of time required to perform the entire task would be so small as to render the use of a ProgressBar pointless.

[sapator]

OK.
So ( will see for tomorrow).
what I do is, raise an event on the function every time a new value is passed and then have the form catch it an update the value?
That's the idea?

[sapator]

I'd suggest that if it did affect things noticeably then the amount of time required to perform the entire task would be so small as to render the use of a ProgressBar pointless.

It depends as I will be getting from 5 to 10 loops to 1000 - 10000, so i do not have a static amount of loops.

[jmcilhinney]

It depends as I will be getting from 5 to 10 loops to 1000 - 10000, so i do not have a static amount of loops.

But do you really need to update the ProgressBar on every iteration? You could do but I'm not sure that it would be any more meaningful than just showing a percentage regardless of the total.

[Shaggy Hiker]

Yeah, I think it's time to fake it a bit. If you are doing something where progress will be made faster than 1/10th of a second, you can't show it anyways. I don't know how gas (or petrol, if you will) dispensers work over there, but we sometimes have digital displays with three digits to the left of the decimal point. I don't know who thought that was a good idea, but the dispensers are fast enough that the hundreds place is little more than a blur, and the thousands is totally unreadable. It's moving, though, so the precision of the dispenser is sufficient, and the interface is fast enough, that the display CAN update for every thousandth of a gallon, even though the people dispensing the gas can't see the numbers as fast as they are changing.

That's an example of an interface that CAN keep up with the progress being measured, but which should NOT be doing so, because it benefits nobody. The point of a progress bar is to show progress is being made. It should update fast enough that the user doesn't start wondering whether or not the system is frozen, but whether it fills in a second, or takes several seconds, is mostly an aesthetic consideration. Updating every tenth record may be sufficient to show that progress is being made. If so, then updating progress every record will actually waste time.

[Sitten Spynne]

They did it in the gas pumps for psychological reasons. Jokes about "perfect pump" aside, having that blur means the user expects imprecise results when they stop pumping. Joe Average would be irate if it updated more slowly and never seemed to stop on the value he was seeing, and Joe Average tends to be the one that makes the rules.

That said, when you're updating a form, you need to be really careful. Think about your form like a video game. People like to shoot for 60 frames per second in video games. That means the game needs to be able to do all of its work in about 17ms. When the frame rate slows down, it's because the game starts taking longer than 17ms and it's drawing frames at a slower interval.

Your form is like that. If you change the text in a text box, the UI thread has to process a Windows message to do that. And it triggers a WM_PAINT back to the form and the screen has to be drawn. That's also the same thread that has to process mouse clicks and keyboard inputs. Pretend we're on a really slow computer, and it takes 100ms to draw the screen after updating a progress bar. If we're only doing it once per second, we've still got 900ms to do all the other things. But if we do it 9 times per second, we only have 100ms left over to do other things. And if we increase the rate to 10 times per second, there's no time left. At 20 times per second, we end up generating 2 events per frame and never catch up until the process finishes.

So when you need to send updates to a form, it's important to think about how fast those updates will be arriving. My rule of thumb is I really don't want to update the UI more often than once every 250 milliseconds. Most people can barely perceive updates faster than that, so it's a waste of time and risks making the form seem slow. So if I'm working with, say, a device that updates its readings every 10ms, I write some code to throttle the UI updates down to a reasonable delay. It might look something like this:

Private _throttleTimer As System.Diagnostics.Stopwatch

Private Sub WhenNewReadingsArrive(...)
    _lastReading = e.Data

    If _throttleTimer.ElapsedMilliseconds > 250
        SendUpdate()
        _throttleTimer.Reset()
    End If
End Sub

I keep the readings as they come in, so if something asks it will get the most recent value, but the UI doesn't really need to be notified as often as the data's coming in so I update in 250ms intervals. There's a lot of code missing in that snippet, and it's not how I always implement a throttle, but it ought to give you a good idea of the technique.

[sapator]

OK.
So I do not really care for complete accuracy.
I can set the progress bar to update every, lets say, 10 iterations.
Not sure if I must raise an event as JMC suggested as it seems to work without that.

[jmcilhinney]

I would tend to just use a percentage. You can declare a property that you set after each iteration and then it can raise an event when the value actually changes, e.g.

Public Class Class1
 
    Private _percentComplete As Integer
 
    Public Property PercentComplete As Integer
        Get
            Return _percentComplete
        End Get
        Private Set(value As Integer)
            If _percentComplete <> value Then
                _percentComplete = value
                OnPercentCompleteChanged(EventArgs.Empty)
            End If
        End Set
    End Property
 
    Public Event PercentCompleteChanged As EventHandler
 
    Protected Overridable Sub OnPercentCompleteChanged(e As EventArgs)
        RaiseEvent PercentCompleteChanged(Me, e)
    End Sub
 
    Public Sub ProcessData(data As ICollection(Of Object))
        _percentComplete = 0
 
        Dim itemCount = data.Count
        Dim itemsProcessedCount = 0
 
        For Each item As Object In data
            'Process item here.
 
            itemsProcessedCount += 1
            PercentComplete = CInt(100 * itemsProcessedCount / itemCount)
        Next
    End Sub
 
End Class

You can then handle that PercentCompleteChanged event in your form and get the PercentComplete property value to update the ProgressBar. With the Minimum and Maximum of the ProgressBar set to 0 and 100 respectively, that will just work, regardless of the amount of data.

[sapator]

Lot's of work for a small progress change but OK, will try it out and post back if any issues.
Will have to find some data with more than just 10-20 rows so I can see the change.
Thanks.

[sapator]

OK.
Spoke to soon.
I don't get any event hit on form2.
Probably doing something wrong.

Public Class Class1

#Region "percentage4progressBar"
    Private _percentComplete As Integer

    Public Property PercentComplete As Integer
        Get
            Return _percentComplete
        End Get
        Private Set(value As Integer)
            If _percentComplete <> value Then
                _percentComplete = value
                OnPercentCompleteChanged(EventArgs.Empty)
            End If
        End Set
    End Property

    Public Event PercentCompleteChanged As EventHandler

    Protected Overridable Sub OnPercentCompleteChanged(e As EventArgs)
        RaiseEvent PercentCompleteChanged(Me, e)
    End Sub
#End Region

.....etc
 Friend Function blah
   Dim itemCount = data.Count
        Dim itemsProcessedCount = 0
  For Each something in data
calculations()
  itemsProcessedCount += 1
                PercentComplete = CInt(100 * itemsProcessedCount / itemCount)
                RaiseEvent PercentCompleteChanged(Me, Nothing) ' or (me,PercentComplete ) ? 
            'or we need?    Application.DoEvents()
next
end function

Form2

 Dim WithEvents cGg As new Class1

Private Sub PercentageComplete(sender As Object, e As System.EventArgs) Handles cGg.PercentCompleteChanged
'WILL NOT HIT
    End Sub

Thanks.

[jmcilhinney]

Firstly, get rid of that RaiseEvent statement in that loop. I don't have that for a reason. As I said in an earlier post, the point is that you just set the property and then it will raise the event if an when necessary.

As for your issue, have you debugged the code? Is the event actually being raised? If the event is raised but your event handler is not executed then the first thing that comes to my mind is that you're handling the event of the wrong instance.

[sapator]

OK.
You are right I was handling it in a class with the same name so it did not have the withevents.
Now the issue is how would I go about on the Private Sub PercentageComplete(sender As Object, e As System.EventArgs) Handles cGeneral.PercentCompleteChanged

I set the ProgressBar.Value = sender.PercentComplete
but I also need to do a performstep. when should i do that. Obviously not in every event handler. I think i need to do that in every 10 of a percentage but I'm not good with maths.
any help?
thanks.

I use on form2
ProgressBar.min = 1
ProgressBar.max =100
ProgressBar.Step = 10
and i handle the .value in the event but when should I use the .performstep?
Thanks.

[sapator]

OK. The event just hit once here.
Hmmm....

[jmcilhinney]

I also need to do a performstep.

Why would you think that? The PercentComplete property contains the percentage of the process that is complete and you assigning that to the Value of the ProgressBar. Why would you need to do anything else?

[sapator]

Yes.
I just saw that. I do not need it.
So everything is fine but I have a question here.
How can I divide to 10 steps instead of 100?
Seems that the process is fast so even with a value of 5000 it shows "ugly"
So I would appreciate 10 steps.
Thanks.

[sapator]

Oh.
Should just use PercentComplete = CInt(10 * itemsProcessedCount / itemCount) ?
Is that correct?

[jmcilhinney]

Oh.
Should just use PercentComplete = CInt(10 * itemsProcessedCount / itemCount) ?
Is that correct?

That's correct, but you should probably change the name of the property and event because it's no longer percentage.

[sapator]

Thanks.
So finally the only issue i get is that the bar will not fill completely when it gets to 10.
I mean, when ProgressBar.Value = sender.PercentComplete goes to 10, the bar will not fill completely, will just sty one step back.
Is that an expected behavior?
thanks.

[sapator]

Hey.
I don't wont to bother you no more so I just use this on the event hit:

  If sender.PercentComplete > 10 Then
            Exit Sub
        End If

   If sender.PercentComplete >= 9 Then
            ProgressBar.PerformStep()
            Exit Sub
        End If

This works.So if you are busy don't let me take your time for this as it is a minor glitch.
Thanks for all the support

[sapator]

Hmmm.
and again Hmmm.
OK so even with this , when i put a thread.sleep on form 2 AFTER the calculations and the progessBar completes it will only show one step complete.
So is this a speed thing or something else?
thanks.

[sapator]

Hmmm.
and again Hmmm.
OK so even with this , when i put a thread.sleep on form 2 AFTER the calculations and the progessBar completes it will only show on step complete.
So is this a speed thing or something else?
thanks.
I'm inclined to just remove the damn thing and get it over with.

[Sitten Spynne]

Let's make a full-fledged example to make sure you're not crossing any wires, and to make sure each concept and moving part gets explained.

Imports System.ComponentModel

Public Class Form1

    Private _rng As New Random()
    Private _worker As ThreadWorker

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        ' Set up controls for a new run.
        Button1.Enabled = False
        ProgressBar1.Value = 0

        ' Create the new worker and handle the change and completed events.
        _worker = New ThreadWorker()
        AddHandler _worker.ProgressChanged, AddressOf WhenProgressChanges
        AddHandler _worker.RunWorkerCompleted, AddressOf WhenWorkerFinishes

        ' Give the worker something to do.
        _worker.RunWorkerAsync(_rng.Next(1000, 2000))
    End Sub

    ' This event is raised when the worker calls ReportProgress(), and happens on the UI thread.
    Private Sub WhenProgressChanges(sender As Object, e As ProgressChangedEventArgs)
        Dim progress As Integer = e.ProgressPercentage
        ProgressBar1.Value = progress
    End Sub

    ' This event happens after all work completes, and happens on the UI thread.
    Private Sub WhenWorkerFinishes(sender As Object, e As RunWorkerCompletedEventArgs)
        ' The last progress event is rarely 100, so manually set it. Also re-enable the button.
        ProgressBar1.Value = 100
        Button1.Enabled = True

        _worker = Nothing
    End Sub
End Class

Public Class ThreadWorker
    Inherits BackgroundWorker

    Public Sub New()
        WorkerReportsProgress = True
    End Sub

    ' This is called on the worker thread when the user calls RunWorkerAsync().
    ' When it finishes, the RunWorkerCompleted event is raised.
    Protected Overrides Sub OnDoWork(e As DoWorkEventArgs)
        MyBase.OnDoWork(e)

        Dim throttleWatch = Stopwatch.StartNew()
        Dim countTo As Integer = CInt(e.Argument)
        For i As Integer = 0 To countTo
            If throttleWatch.ElapsedMilliseconds > 250 Then
                ReportProgress(CInt(Math.Floor(i / countTo * 100)))
                throttleWatch.Start()
            End If

            ' I did this JUST for the example, so the counting doesn't finish
            ' immediately. Computers are fast.
            Threading.Thread.Sleep(5)
        Next
    End Sub

End Class

I haven't really seen a lot of your code, but this is the basic pattern for a progress bar that displays something. It can be implemented a few other ways, but you have to understand how the bits work to branch out. If your code isn't working, odds are it's because it doesn't follow this basic pattern. I can't offer much specific advice about fixing that, based on the code I can see in the thread.

[sapator]

Hi.
I currently using application.doevents as this is a 1% of the total work i need to do.
I know this can break the application but it is a fast - dirty solution just for now and if I have time I will try to integrate the examples.
I removed the ProgressBar from the function (JMC example) as it is not updating, maybe it needs threading but kept the percentage solution of JMC as I really liked it.
As I'm re-learning forms development I remember using the ProgressBar on a background worker. Strangely I've read that the UI is not updated on the BGW but maybe (as JMC said), the ProgressBar may have some multi threading so it is updated. Do not know for sure.
Thanks

[jmcilhinney]

As I'm re-learning forms development I remember using the ProgressBar on a background worker. Strangely I've read that the UI is not updated on the BGW

The point of the BackgroundWorker is to do the work on a background thread so that the UI remains responsive to do UI things, e.g. update a ProgressBar. You call RunWorkerAsync and handle the DoWork event, which is raised on a background thread. You do your work in that event handler and, to update the UI as you go, you call ReportProgress and handle the ProgressChanged event, which is raised on the UI thread. That means that you can update the UI in that event handler. If you want to perform a final update on the UI when the operation is complete, you handle the RunWorkerCompleted event, which is also raised on the UI thread. As an example, you might display a ProgressBar and then call RunWorkerAsync, update progress as you go and then hide the ProgressBar again in the RunWorkerCompleted event handler. You can find an example of using a BackgroundWorker if you follow the link below to my CodeBank threads.

[sapator]

Hey.
As I've said I'm sure I have done this in the past (waaaay in the past).
Now I'm temped to change to whole progress bar code but I'm in a very tight schedule.....
Hmmm.

But, thanks anyhow