Progress Indicator wanted

[ChrisO]

Smig.

If ‘Not Access timer’ then what timer?
You say the ‘System Timer’ but what is the System Timer?
How do we hook into the ‘System Timer’?
As far as I understand Windows, the best that can be done is to hook into the Media Player tick and I don’t know how to do it. And I wouldn’t do it just for the sake of some ‘eye candy’. Access is, after all, a data management application and I would not knowingly compromise that functionality with any such eye candy.

You also say if you place an ‘object’ on the form but you do not say what object.
A text box? An image? An ActiveX control?... you don’t say.
And what code is behind the ‘object’ that allows it to update?...you don’t say.



I’ll tell you a true story: -
About 5 years ago I was asked to make an Access database for our air force. It was to open an archive file and display its point to point data on a report. I chose not to go down the simple path and use a chart. Although it requires much more code I decided to draw the plot myself using draw commands. The reason for that decision was that, at the start of the job, I did not know if a chart object could handle it and I did not want any deficiency in the chart object to come back and bite me some distance down the track.

So I did it the hard way and did not go the easy route and use someone else’s predefined object.
Even though it was more difficult I ended up with something I understood and could modify.
The draw is done in simple steps, although there are a great many steps.
Using an ActiveX control reduces the number of steps but it also hides the detail.
When the detail is hidden we can’t fix it if it goes belly up.



Sorry, but you seem to want to throw eye candy at a work tool by installing this, that, whatever, and that may cause it to fail. And by asking some of these questions it appears that you don’t know how to fix them if they do fail.


My point being…
If you want a robust application, you have to write it. There is no point in using eye candy or someone else’s predefined object just to make it easy on yourself. Eventually the eye candy or object will fail and someone has to fix it. (Example: My chart works fine in Access 2003 but does not show in Access2007) When that happens, a lot of people jump onto the internet and ask for help. Will this happen, will that happen, how do I fix this or how do I fix that? At that point, and it will happen with something complex, someone else might do the work for you.

Might; but what if they don’t?

Chris.

 

[smig]

@Chris, if you go back this thread you'll see I said I'm asking for a theorethical question about using a DLL
it's totaly theorethical as for now I have no idea how to create a DLL

I know Access was built for db application.
Is making a Drag-Drop chess game in Access is what it was made for
We all try pushing it to the end, either by writing our oun tools or using someone else.

can I gurentee someone else tool will work in future? sure I can't. but I can also not gurentee my oun tool, or even Access itself will.
sure, if we take the most simple steps, and use the most simple tools there is higher chance for them to work in future.
But this is not the pointhere. People ask for more eye candy applications, and we will do our best to give it.
few days ago I had a look at another db I made 2 or 3 years ago, and I said to myself "wow this one looks real ugly compared to the current project, I realy need to upgrade"

now, back to my therotical question
If I use a DLL object that use the system timer, will Access prevent it from refreshing the form view.

*** edit ***
This is no more theorethical - a long routine will prevent any update to the form
I tested it using the StatusBar control time. as this one updated even at design mode it's not using the Access timer.
I used the Do While True to hang Access.
StstusBar time was not updated for several minutes

 

[Guus2005]

Okay then, in this thread there is a progress bar.

It operates over a range of 0 to 1 as a floating point single.
It should be passed (current step) / (total steps.)

Usage example: -

Public Sub SmoothAllSeries(ByRef chtThisChart As Object, _
                           ByVal blnSmoothLines As Boolean, _
                           ByVal intSize As Integer)
                           
...

End Sub

Maybe something to play with.

Chris.

Thanks Chris,

I've build a class around it so i don't have to think about closing the progressform. It now closes when the object is out of scope.

Guus

 

[ChrisO]

Although I do not recommend it, there is now a method in the following thread: -

http://www.access-programmers.co.uk/forums/showthread.php?t=206049

Chris.

 

[SpentGeezer]

Try this JohnPapa, I think you'll find it rather tastey...

 

[SpentGeezer]

Pretty much all processes are divisible. You just have to work out how many divisions (progress bar movements) you want and tell the P bar to progress at different stages through the code. If it is very time consuming due to processing a massive table then just use a counter or similar to increment your P bar at certain stages. E.g if you want a increment after every 500 records just use something like

if rdset.currentrecord / 500 = int(rdset.currentrecord/500) then
       'PBar increment 1 step
end if

you can use the record set count and divide it by 500 to work out the number of divisions needed before initiating the P Bar.

 

[ChrisO]

>>Pretty much all processes are divisible.<<
That statement would require some verification.

Progress meters are a dime a dozen, you can find them almost anywhere, but they all rely on the process being divisible.

So the real question is; what if the process is not divisible?

 

[SpentGeezer]

Please excuse my ignorance but what processes are not divisible?

 

[SpentGeezer]

I guess importing / exporting a single very large file would not be divisible...

 

[Galaxiom]

Try this JohnPapa, I think you'll find it rather tastey...

It is a good idea to compact and zip databases before posting them.

The posted file is 1.13 MB.
Compacting it reduced it to 736 KB
It then zips to 218 KB reducing the storage and transmission to just one fifth of the original.

 

[ChrisO]

SpentGeezer.

And so you have an answer.

There was also another answer to your question by Dave in post #37

So the question becomes; can we show progress in an indivisible process?

To my mind the answer is no.
Progress to me implies a starting point, ending point and ‘some’ points between.
The starting point and ending point are easy.

Message box start.
Run process.
Message box end.

But there is no progress because the process is indivisible and therefore we do not have ‘some’ points between.

So even that too complex thing I did is not progress, all it is is a continuation indicator but it does not show progress.

And because it is so complex, and for such little gain, I think of it as ‘lipstick on a pig’.

But people can use it if they want, that’s up to them.

Chris.

 

[SpentGeezer]

So best practice for indivisible process is something like:

dim a 
a = msgbox "This process takes up 2 hours and uses a lot of PC resources. Press Yes to continue or no to cancel", vbyesno, "Maybe you should run this overnight...."

if a = ........etc

 

[ChrisO]

"This process takes up 2 hours…”
"Maybe you should run this overnight...."

That seems entirely reasonable, except perhaps for the part about maybe.

There is no such thing as best practice; there is only best fit for the circumstance.

In a multi-user system such a process would probably not be initiated by a (singular) user.
That type of process sounds more like a server sink in that it, the server, would be updating its files, for all users, from another source.

One would have to ask the question; what happens to all the users while the server is updating?

The best fit answer to that question is probably…nothing.
Nothing because the users have all gone home.
If the users have all gone home, and are not using the server, then why would they need to be shown progress?

 

[JohnPapa]

I am returning back to this thread to ask about your experience regarding the overhead associated with a progress indicator.

Most likely I will use a moving yellow folder towards a PC, much like Windows uses. The trail of yellow folders will essentially be constructed from the same folder image repeated 4-5 times and the movement be handled through the Timer event. I plane to set the Timer to around 3 secs, so there will be a folder movement every 3 secs (about) and there maybe a need for a DoEvents every folder move.

Will this add too much overhead?
John

 

[JohnPapa]

Did some research and the result confirms what others reported on this and other threads. Namely that Access takes an electronic tea break and the indicator does not update regularly even with DoEvents sprinkled in during every move (= setting clipart to Visible and non-Visible).

In my specific case and without the progress indicator the code ran for about 10 secs. With the progress indicator (with Timer set to 3 secs), the code ran for the same 10 secs with no movement from the progress indicator and the progress indicator only showed some activity after the 10 secs.

Unless I am doing something wrong, I am thinking of using a progress indicator in the form of a list and a check mark for every completion of every list item. I can then include a message for each list item in the code (hard-coded). In this manner the user will know what is happening and will receive timely updates.

Regards,
John