VB 2010 Express Progress bar

[Bushranger]

Sorry about that messy first post. Just to refresh memories, I have a progress bar on my Form3. The data processed (text encryption), on Modual1.

 

I got the progress bar to work, but it does not fill the progress bar completely. The data processed is variable in length and what happens is the progress bar shows the data being processed but stops relative to the amount of data it processed. I want the progress bar to fill to 100% regardless of the amount of data processed. But being old, I am having a problem figuring it out. Here is a code snippet from my Modual1. What coding would make the bar fill no matter the size/length of the data?

'Code for progress bar:
           'Give percent of data processed...not using this yet.
           Dim Percentage As String = CType((Form3.ProgressBar1.Value / NumberOf * 100), Integer).ToString & "%"
           'Counts the number of charators being processed.
           NumbCounter = NumbCounter + 1
           If     NumbCounter > Form3.ProgressBar1.Maximum Then
                  NumbCounter = Form3.ProgressBar1.Maximum
           End If           

                Form3.ProgressBar1.Value = NumbCounter  'Updates progress bar on Form3...this works.
           'Not using percentage yet.
           Form3.Label14 = Percentage

Edited December 9, 2019 by Bushranger

[Bushranger]

Whoops! I worked on the problem this afternoon and I have gotten the Progress bar to match with the data (fill the bar regardless of the amount of data). I added the following line of code:

Form3.ProgressBar1.Maximum = NumberOf

[ass17]

I was going to suggest you need a maximum value..... just out of interest does your data processing hold the program back? What I mean is does everything happen within a single process so the progress bar progress is clunky and not smooth. I suppose what I’m getting at is anything that needs to be done in terms of processing should be performed on a separate thread or background worker so that the main form can stay responsive. I do this all the time with my software I create. I find it’s best practice to keep your main form responsive to the end user so other things can be done along side those in the background.

[Bushranger]

I was going to suggest you need a maximum value..... just out of interest does your data processing hold the program back? What I mean is does everything happen within a single process so the progress bar progress is clunky and not smooth. I suppose what I’m getting at is anything that needs to be done in terms of processing should be performed on a separate thread or background worker so that the main form can stay responsive. I do this all the time with my software I create. I find it’s best practice to keep your main form responsive to the end user so other things can be done along side those in the background.

 

I am not sure if I understand your question, but I will take a shot at it anyway. In my program, once the operator enters the text and clicks the control that encrypts it, I do not want them doing anything until the text has been processed. It is a single purpose program. The only option I have given the operator is to quit the program.

 

A problem I have run into, is that it takes an inordinate amount of time to process (encrypt) the text which, inasmuch as un-encrypting the same text/message is very fast compared to encrypting it although one process is just a reverse of the other and should take the same amount of time. It is confusing in that, the program works and as such, cannot be too serious of a problem. I put the progress bar into the program and will put a "percent completed" textbox in it to aid me in finding out why the encrypting code is taking so long compared to the un-encrypting code processing. But, it is merely a hobby for me (have long been fascinated with the WWII Bletchley Park Code breaking and the Enigma Machine), I have no expectation that anyone would want a text message encrypting program...other than the odd terrorist or two.

[ass17]

I am not sure if I understand your question, but I will take a shot at it anyway. In my program, once the operator enters the text and clicks the control that encrypts it, I do not want them doing anything until the text has been processed. It is a single purpose program. The only option I have given the operator is to quit the program.

 

A problem I have run into, is that it takes an inordinate amount of time to process (encrypt) the text which, inasmuch as un-encrypting the same text/message is very fast compared to encrypting it although one process is just a reverse of the other and should take the same amount of time. It is confusing in that, the program works and as such, cannot be too serious of a problem. I put the progress bar into the program and will put a "percent completed" textbox in it to aid me in finding out why the encrypting code is taking so long compared to the un-encrypting code processing. But, it is merely a hobby for me (have long been fascinated with the WWII Bletchley Park Code breaking and the Enigma Machine), I have no expectation that anyone would want a text message encrypting program...other than the odd terrorist or two.

 

[emoji23][emoji1303]

 

I see, my point is that what you are doing is being done on the UI thread (User interface) thread so I will naturally be slower than running the encryption task in a separate thread or background worker.

 

It’s something to have a look at, I use many separate Threads in my ExamWritePad software so that the UI is as fast as it can be so the user when typing the document will not notice anything.

 

You are doing something different but because you are reporting back to the UI thread a progress bar it slows downs the whole process.

 

Once you get your head around threading and BGW (backgroundWorker) then you won’t look back...

[Bushranger]

[emoji23][emoji1303]

 

I see, my point is that what you are doing is being done on the UI thread (User interface) thread so I will naturally be slower than running the encryption task in a separate thread or background worker.

 

It’s something to have a look at, I use many separate Threads in my ExamWritePad software so that the UI is as fast as it can be so the user when typing the document will not notice anything.

 

You are doing something different but because you are reporting back to the UI thread a progress bar it slows downs the whole process.

 

Once you get your head around threading and BGW (backgroundWorker) then you won’t look back...

I took a cursory look at Multithreading and was warned off by some of the posts about it. I will also take a look at BackGroundWorker when I get the chance. Thanks for the heads-up.