locked
ACCESS 2010 VB using MSComctlLib ProgressBar RRS feed

  • Question

  • I am having a hard time trying to figure out how to implement a Progress Bar into an application.  What I have found is that I need to create a form and then insert a ProgressBar ActiveX object into the form.  Problem is When I access the ActiveX objects while designing the form, I do not find the Progress Bar anywhere.  So the question is what do I have to do in order to have the Progress Bar included in the ActiveX list.  Also, there is precious little documentation about functions such as these.  Unless you are lucky you may spend days trying to find out how to use the software that your folks have spent time developing. Any clues on where to look for how to type information on the Common Controls?
    Friday, August 30, 2013 11:35 PM

Answers

  • I had a few extra minutes. Try this:

    Create new blank form. Drop a scrollbar control on it.
    Set the form's TimerInterval to 200.
    In Form_Timer event write:
        If Me.ProgressBar1.Value = Me.ProgressBar1.Object.Max Then Me.ProgressBar1.Value = Me.ProgressBar1.Object.Min
        Me.ProgressBar1.Value = Me.ProgressBar1.Value + 1
    Run the form.


    -Tom. Microsoft Access MVP

    • Marked as answer by George Hua Monday, September 9, 2013 1:36 AM
    Saturday, August 31, 2013 4:16 PM

All replies

  • You don't insult me with "your folks", but I understand programming can be frustrating at times. I yelled at my keyboard today. This forum is kept alive by unpaid non-MSFT employees. The community helping the community - get it?

    With that out of the way, this ActiveX control you might be able to use but MUCH simpler is to use the built-in progress bar. Sure, it's not as pretty, but it's one line of code to use it. Can't beat that. And no problems with ActiveX versions being out of sync, etc.

    So look up the SysCmd topic in the help file, with arguments like acSysCmdInitMeter. acSysCmdUpdateMeter, and acSysCmdRemoveMeter.


    -Tom. Microsoft Access MVP

    Saturday, August 31, 2013 4:01 AM
  • I had a few extra minutes. Try this:

    Create new blank form. Drop a scrollbar control on it.
    Set the form's TimerInterval to 200.
    In Form_Timer event write:
        If Me.ProgressBar1.Value = Me.ProgressBar1.Object.Max Then Me.ProgressBar1.Value = Me.ProgressBar1.Object.Min
        Me.ProgressBar1.Value = Me.ProgressBar1.Value + 1
    Run the form.


    -Tom. Microsoft Access MVP

    • Marked as answer by George Hua Monday, September 9, 2013 1:36 AM
    Saturday, August 31, 2013 4:16 PM
  • How do I 1-get this progress bar to go faster if desired and

    2-How do I get it to close?  Put a DoCmd.Close at the end of the SUB?

    Tuesday, December 1, 2020 3:04 AM
  • Re 1: if updating every 200 msec does not suit your needs, then what do you do?

    Re 2: Define "it". If you are referring to the scrollbar control, it does not "close". You may want to close the form it is on, using:
    DoCmd.Close acForm, "yourFormName"


    -Tom. Microsoft Access MVP

    Tuesday, December 1, 2020 3:42 AM
  • I would also avoid using an ActiveX progress bar.

    The simplest approach is to have two rectangles overlaid on a form. The front rectangle has a coloured fill and its width increases incrementally after each action. The back rectangle is full width with a border and no fill.

    The progress bar can be updated in one of two ways:

    1. After each event being 'reviewed' is completed

    2. After a specified timer interval (as suggested by Tom)

    I have a working example at http://www.mendipdatasystems.co.uk/progress-bar/4594424316

    See screenshot below. It is based on a timer event


    • Edited by isladogs52 Tuesday, December 1, 2020 9:28 AM Added screenshot
    Tuesday, December 1, 2020 9:27 AM
  • I totally agree with isladogs52, you shouldn't use ActiveX controls as much as possible.  This is one of the most fundamental development rules. ActiveX controls are prone to versioning issues, amongst other things and this should be avoided whenever possible.

     

    There are numerous form/VBA based progress bars available on sites like utteraccess.com (in the code archives page).  I believe Albert Kallal has a nice and simple one on his site as well.  The one supplied above by isladogs52 is another great example.


    Daniel Pineault, 2010-2019 Microsoft MVP
    Professional Support: http://www.cardaconsultants.com
    MS Access Tips and Code Samples: http://www.devhut.net

    Tuesday, December 1, 2020 1:07 PM
  • I would also avoid using an ActiveX progress bar.

    The simplest approach is to have two rectangles overlaid on a form. The front rectangle has a coloured fill and its width increases incrementally after each action. The back rectangle is full width with a border and no fill.

    Hi,

    In any loop (recordsets, reading a file, collections) I can activate a progressbar form, and choose the functionality of the form. Two parameters are necessary: the Current_nr (cycles processed until now) and Total_nr (final cycles processed).

    At the start of the form a starttime is set. So now it is possible to display the Current_nr, Total_nr, but also the number of cycles left, the current processing time, the estimated remaining time, some information on the current cycle, etc.

    The backgroundcolor is derived from the application color, while the color of the moving bar is a dark shade of the application color, 

    The bar itself consists of two controls, the static one represents the Total_nr, the moving one represents the Current_nr.

    The bar is not necessarily moved in each cycle, but only after reaching then next "quantum": in most cases this is the next rounded percent.

    Triggered by this thread I plan a re-design. Instead of the two controls I think to use 100 continuous controls. Depending on the next quantum-number the next control(s) get their "onn"-color.

    This gives the possibility to use color-grades all over the bar, or use some "color-wave" travelling over the bar. 

    I am curious to see what the effect will be.

    Further detail, this progressbar-form is stored in a linked library, so immediately available in all loops in any of my applications.

    Imb.

    Thursday, December 3, 2020 9:53 AM
  • Hi imb

    To me, it sounds like you are trying to make a complicated solution in place of a perfectly effective simple solution.

    With the method I use, (similar to your current setup), it is possible to use an image for the progress bar. For example:

    It would be perfectly possible to use an image whose colour shading changes from left to right giving the effect of a gradient fill on the progress bar



    • Edited by isladogs52 Thursday, December 3, 2020 11:46 AM Spelling
    Thursday, December 3, 2020 10:26 AM
  • To me, it sounds like you are trying to make a complicated solution in place of a perfectly effective simple solution.

    Hi isladogs,

    I can imagine that it "sounds" complicated, especially the "quantization". It is in effect quite simple.

    When you have a loop with 10000 cycles, I do not update the bar every cycle, but only after the next "quantum" (or the next procent, in this case 100 cycles), is reached. When the loop has less than 100 cycles, the bar is thus opdated every cycle.

    The progressbar-form only needs three values, the Total, the Current, and the "bar-type". If the bar-type is not specified in the original loop, no progressbar-form is opened.

    But, thank you, I will remember the possible use of an image. In my "dynamical programming" I like to explore the possibilities.

    Imb.


    • Edited by Imb-hb Thursday, December 3, 2020 10:51 AM
    Thursday, December 3, 2020 10:51 AM
  • That part is simple enough though calling it 'quantization' originally made it sound otherwise in my opinion.

    This was the section I was actually referring to...

    Triggered by this thread I plan a re-design. Instead of the two controls I think to use 100 continuous controls. Depending on the next quantum-number the next control(s) get their "onn"-color.

    EDIT: Here are 2 examples with a gradient fill. I just had to substitute the image from my last screenshot to create each of these.

    As to whether these are better than a solid bar or just a distraction is a matter of opinion/personal preference!


    • Edited by isladogs52 Thursday, December 3, 2020 11:56 AM
    Thursday, December 3, 2020 11:19 AM
  • That part is simple enough though calling it 'quantization' originally made it sound otherwise in my opinion.

    ...

    As to whether these are better than a solid bar or just a distraction is a matter of opinion/personal preference!

    Yes, I can understand. Alas, I am better schooled in Chemistry than in English.

    The basis of the progressbar is the counting: 501 van 600. All the rest is cosmetics. Cosmetics are allowed, but only on a firm basis. It is my opinion that when you can generalize, there is a firm basis. And after that, cosmetics is fun.

    Imb.

    Thursday, December 3, 2020 12:28 PM
  • Luckily I'm a physicist by training so quantum mechanics is something I'm familiar with ... though perhaps not in this context :~)

    If you want to compare your progress bar code with mine, see

         http://www.mendipdatasystems.co.uk/progress-bar/4594424316


    • Edited by isladogs52 Thursday, December 3, 2020 3:28 PM
    Thursday, December 3, 2020 3:27 PM
  • Luckily I'm a physicist by training so quantum mechanics is something I'm familiar with ... though perhaps not in this context :~)

    Hi isladogs,

    I had better said: in discrete steps, and not continuous. But every cycle would also be a discrete step, and then came the dispair.

    The discrete steps are equidistant steps on the Total bar. You get good results with 100 equidistant steps (1% of the Total), but for more smoothiness you can choose 200 steps.

    And 100 discrete steps can be 100 contiguous controls, where each step/control can be treated independant of all the others!

    Imb.

    Thursday, December 3, 2020 5:06 PM
  • If you do look at my code, you will see I do a series of discrete steps depending on the number of steps involved. As you say, the larger the number of steps, the smoother the result. However that needs to be balanced against the fact monitoring progress using a progress bar adds to the total time taken to run the routine. The more steps you have the larger the increase in time.

    Sorry, but I still see absolutely no value in having 100 contiguous controls to do this. In fact that is exactly the same approach I used with my first progress bar almost 20 years ago (though with 'only' 20 controls). Doing that adds complexity to the process and will I think further add to the processing time.

    Thursday, December 3, 2020 7:08 PM
  • Sorry, but I still see absolutely no value in having 100 contiguous controls to do this. In fact that is exactly the same approach I used with my first progress bar almost 20 years ago (though with 'only' 20 controls). Doing that adds complexity to the process and will I think further add to the processing time.

    Hi isladogs,

    I want to come back to your above answer. I think you understand my progress bar in a different way then I designed it.

    The basic of the progress bar is a number of the total number of cycles, and a count of the number of cycles that has passed. Based on that you can calculate the - most basic - percentage progress.

    It is not always necessary to update the form at every cycle. In general an update is only done after the next percentage is reached.

    How the form is updated with what kind of information, is a different thing, It is more or less the cosmetics that you add per update.

    I have many different representations of the "progress", from a simple percentage to a display with progress bar, including cycles left, expected time left to finish, and almost all what you can think of. 

    In all processes that include a loop, I can add a progress_type, what suits the best with the typical process: fast, slow, few, many, ...

    In the Open event of the progress form the controls for the given progress_type are activated, and in each update-cycle these controls are refreshed. The appropriate actions form a given progress_type are selected in a SELECT CASE statement, organized from "fast" to "slow".

    I have one special loop-process, where I loop through all my applications to inspect all the code and see where some text is used under what conditions. This takes about 15 seconds per application, and with 107 different applications it takes almost half an hour. In this case it is worth to spend a few extra milliseconds per update, to amuse the user (or me?) with a changing color progress bar composed of 100 contiguous controls with each a different color.

    It is my challenge/fun to make robust systems with many possibilities.

    Imb.


    Tuesday, December 8, 2020 10:24 PM
  • Hi imb

    No. I understand it completely and, as already stated, almost all of my progress bars used in production databases are updated after each section of a lengthy procedure is completed...or after each step in a loop. My progress bars work in exactly the same way with the total number of 'steps' differing in each case from as low as 9 to several hundred. I have measured the time taken with and without progress bars being used. Typically, for a large number of 'steps', using progress bars adds up to 14% to the total time needed to run a procedure.

    All I'm saying is that using 100 contiguous boxes and making them visible one at a time after each % is more complex than increasing the width of a single progress bar after each step. I believe the extra complexity will further increase the time needed and, in my opinion, not provide any additional functionality.

    However, if you want to use that approach, its your database and your choice.

    Wednesday, December 9, 2020 9:48 AM