Active X Progress Bar...who knew??

[NauticalGent]

Stumbled across this on accident yesterday. I never explored Active X controls on forms - and from what the author says, they are not a good thing - however, when the topic of Progress Bars come up, I have never seen anyone mention this built in feature. Am I always the last one to the party??

 

[Isaac]

I didn't watch the entire thing, but, it looks like you still have to come up with your own homegrown logic for precisely when to tell the progress bar what to show. In other words, you still have to have, (ideally), a loop with a known # of iterations, and a known % complete proportion.

Which would mean that (although I agree, the visual is nice - the style of dots is a cool look for sure), it's not any advantage over the homegrown ones I've used.

The real magic would come if there was a progress bar that magically knew how much of a process was finished, with no judgment calls on the programmer's part. That would be gold. But judging from Microsoft's dismal attempt to show progress bars during everyday activities, it seems that will never materialize.

I humbly agree/admit - I never knew about that progress bar control!

 

[isladogs]

It is so easy to make your own progress bar from standard controls that there is no reason to ever use an ActiveX version

 

[NauticalGent]

Agree to both. My thing is, I never knew about this which makes me wonder what other features I am missing out on? My need to use Access on a daily basis is all but over so I dont not tinker as much as I used to but I still would like to know these things...

The more I find out, the less I know...

 

[Isaac]

The more I find out, the less I know...

Precisely the proper conclusion made by any well maturing developer, IMO.
Same for me!

I just found out about Excel VBA's SaveCopyAs a few weeks ago, and felt like a real idiot. Here all these years I thought there was no way to save a copy of the active file, without changing which file was the active file. Unbelievable.

 

[The_Doc_Man]

As far as progress bars go, I have always used two rectangles. The "bottom" one is fixed in size and has borders but no fill. The "top" one will vary in size and have fill (background) but no borders. Then make them align on .Top and .Left, copy .Height from the bottom to the top, and set top.Length to 1. Then at each update, it is a matter of the top's .Length = ( current value x bottom.Length) / max potential value

Or something close to that.

This works as long as you actually know the maximum value you could represent.

 

[shadow9449]

@The_Doc_Man: I do the same. I like to use tiny graphics with size mode set to 'stretch' for what you call the "top" so I can get some cool effects like grading/shading/rounding, etc.

I watched the video and while he says about 6 times NOT to use ActiveX where you can avoid it, it seems super easy to use the ActiveX progress bar (if you want something that looks like it's take from Windows XP) and I agree with NauticalGent: it's pretty amazing that there are controls that most people don't know about!

As far as the video, I actually like his teaching style. He seems really knowledgeable and presents well. I'm checking out some of his other videos as well.

 

[The_Doc_Man]

The only issue with ActiveX is that they are kind of disavowed or something like that.

 

[AccessBlaster]

ActiveX is not standardized across platforms. They are fine if you're not planning on sharing your app.

 

[Isaac]

As far as progress bars go, I have always used two rectangles. The "bottom" one is fixed in size and has borders but no fill. The "top" one will vary in size and have fill (background) but no borders. Then make them align on .Top and .Left, copy .Height from the bottom to the top, and set top.Length to 1. Then at each update, it is a matter of the top's .Length = ( current value x bottom.Length) / max potential value

Or something close to that.

This works as long as you actually know the maximum value you could represent.

Yep, me too.

About 90% of my progress bar usage is only in the context of known # of loop iterations.
Occasionally I'll use it for a known number of "tasks" (with, really, an unknown number of time and proportion), but not often. This latter approach, with a known number of tasks but no idea how long they'll really take nor any proportion to each other, is what Microsoft appears to have decided to do most of the time.