Tim

Can you explain this please.

Roy Lambert

Roy,

<< Can you explain this please. >>

It specifies the progress time updates in milliseconds instead of going by a
fixed number of operations.  That way you're guaranteed to get a progress
update every X number of milliseconds, give or take.  Sometimes the length
of the operation between progress update checks might be longer than what
you're set, but you'll get an update as soon as possible.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


If possible, I'd like to surface the time the queries run so far so that I can decide wether or not to shove up a progress indicator. I know I can monitor it myself but I think it would be better as a parameter something like

procedure TForm1.EDBQuery1Progress(Sender: TObject; PercentDone, msSinceLastUpdate, msTotalElapsed: Integer; var Continue: Boolean);

The idea is to compare PercentDone and msTotalElapsed and if its likely to take less than (say) 100ms for the query do not show a progress bar. If its likely to take 2000ms then show it. Something like that.


Roy Lambert

Tim

Better still how about an EstimatedTimeToCompletion. I know it wouldn't be accurate but it would be good enough to decide wether to display a progress bar after 1 or 2%


Roy Lambert

Roy,

<< Better still how about an EstimatedTimeToCompletion. I know it wouldn't
be accurate but it would be good enough to decide wether to display a
progress bar after 1 or 2% >>

That might be tough when considering unions and other types of queries.
However, I'll put on the list to look at and see what I can do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< If possible, I'd like to surface the time the queries run so far so that
I can decide wether or not to shove up a progress indicator. I know I can
monitor it myself but I think it would be better as a parameter something
like

procedure TForm1.EDBQuery1Progress(Sender: TObject; PercentDone,
msSinceLastUpdate, msTotalElapsed: Integer; var Continue: Boolean);

The idea is to compare PercentDone and msTotalElapsed and if its likely to
take less than (say) 100ms for the query do not show a progress bar. If its
likely to take 2000ms then show it. Something like that.  >>

I'll see what I can do.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

I'm going through my V2 to-do list, and this was on my list still:

"If possible, I'd like to surface the time the queries run so far so that I
can decide wether or not to shove up a progress indicator. I know I can
monitor it myself but I think it would be better as a parameter something
like

procedure TForm1.EDBQuery1Progress(Sender: TObject; PercentDone,
msSinceLastUpdate, msTotalElapsed: Integer; var Continue: Boolean);

The idea is to compare PercentDone and msTotalElapsed and if its likely to
take less than (say) 100ms for the query do not show a progress bar. If its
likely to take 2000ms then show it. Something like that."

Given some time to think about this, the answer is very simple.  Each sesson
has a ProgressTimeInterval that dictates that a progress update only be
given every X number of milliseconds.  To do what you want, just keep track
of how many times the progress update event handler has been called.  If it
has been called once, then at least the ProgressTimeInterval setting has
elapsed.  The second time it is called, it's ProgressTimeInterval*2, etc.
Then, just display the progress bar when the total time has reached the
point that you desire.

--
Tim Young
Elevate Software
www.elevatesoft.com

I think may be two events would be good : beforeexecute and afterexecute
  it can be used to display busy status

Isaac,

<< I think may be two events would be good : beforeexecute and afterexecute
it can be used to display busy status >>

I'm not sure if that would help with Roy's specific issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>Given some time to think about this, the answer is very simple. Each sesson
>has a ProgressTimeInterval that dictates that a progress update only be
>given every X number of milliseconds. To do what you want, just keep track
>of how many times the progress update event handler has been called. If it
>has been called once, then at least the ProgressTimeInterval setting has
>elapsed. The second time it is called, it's ProgressTimeInterval*2, etc.
>Then, just display the progress bar when the total time has reached the
>point that you desire.

Nice bit of lateral thinking - all I need is an extra global to keep track of the number of times triggered. Shows there are some occasions when DBISAM indoctrination needs to be overcome.

Roy Lambert