Delphi_developer
asked on
How to perform regular screen refresh while processing?
Hi
my application is processing data and it can take up to 10 minutes to do. It can make tens of millions of cycles... to have some sort of screen refresh and indicator I put this to every main procedure :
if counter mod 10000 then
begin
StatusForm.Show;
StatusForm.myLabel.Caption := 'Procesing #'+myIndicatorNo;
Application.ProcessMessage s;
end;
Now, this works OK. Obivously with 'IF' I make sure that refresh doesn't take too much of resources, because it CAN, at least in my application!
Now, I would like to have another, easier and much less code approach. So I was thinking of having a Timer that would do the same think every second.
Is this possible? Can Timer take a lot of resources, while waiting for 1 sec to pass? Is this, being executed on Timer event, actually possible in one-threaded application?
If this is possible for my application, please give me some pointers.
Thank you
my application is processing data and it can take up to 10 minutes to do. It can make tens of millions of cycles... to have some sort of screen refresh and indicator I put this to every main procedure :
if counter mod 10000 then
begin
StatusForm.Show;
StatusForm.myLabel.Caption
Application.ProcessMessage
end;
Now, this works OK. Obivously with 'IF' I make sure that refresh doesn't take too much of resources, because it CAN, at least in my application!
Now, I would like to have another, easier and much less code approach. So I was thinking of having a Timer that would do the same think every second.
Is this possible? Can Timer take a lot of resources, while waiting for 1 sec to pass? Is this, being executed on Timer event, actually possible in one-threaded application?
If this is possible for my application, please give me some pointers.
Thank you
I would have thought that Timer is interrupt driven, and therefore uses less resources, but others here will have a clearer idea.
nope, not in 1 threaded app
the timer event will be put on the queue, and wait for the thread to process it
which off course will never happen as your calculation routine is using the 1 thread
you really need to put the calculation routine in a thread
if you want the GUI not to freeze
the timer event will be put on the queue, and wait for the thread to process it
which off course will never happen as your calculation routine is using the 1 thread
you really need to put the calculation routine in a thread
if you want the GUI not to freeze
I for one would be interested to know how to implement that
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Example of DB reading records
procedure TMyThread.Execute;
var I: Integer;
begin
DoCallback('Thread started', 0);
DoCallback('Records ' + IntToStr(Query.RecordCount)), 1);
I := 0;
while not Query.Eof do
begin
Inc(I);
DoCallback('Handling record ' + IntToStr(I), 2);
Query.Next;
end;
DoCallback('Thread started', 0);
end;
in your Form create a thread with the callback proc assigned
type
TForm1 = class(TForm)
ProgressBar1: TProgressBar;
Panel1: TPanel;
private
fThread: TMyThread;
procedure ProgressUpdate(aMessage: string; aMessageInfo: Integer = 0);
end;
procedure TForm1.ProgressUpdate(aMessage: string; aMessageInfo: Integer = 0);
begin
Panel1.Caption := aMessage;
case aMessageInfo of
0: ProgressBar1.Position := 0;
1:
begin
ProgressBar1.Position := 0;
ProgressBar1.Max := StrToInt(Copy(aMessage, 8, Length(aMessage)));
end;
2: ProgressBar1.Position := ProgressBar1.Position + 1;
3:
begin
ProgressBar1.Position := ProgressBar1.Max;
fThread := nil;
end;
end;
end;
procedure TForm1.Button1Click(Sender: Object);
begin
if not Assigned(fThread) then
fThread := TMyThread.Create(ProgressUpdate);
end;
o yes,
no need to call
Application.ProcessMessage s
no need to call
Application.ProcessMessage
GG:
v. comprehensive ty. I hope it answers DD's q!
v. comprehensive ty. I hope it answers DD's q!
ASKER
@Geert Gruwez: Thank you! I will need some time to test if this can be applied to my app...
ASKER
I decided that running my app in threads is a little too complicated... too many errors and too much things still to learn about threads, for now.
But thank you for the solution, I will definately use it in another app.
I will go back to Application.ProcessMessage s; for now, it is the easiset way and it works 100% for my app.
Thank you
But thank you for the solution, I will definately use it in another app.
I will go back to Application.ProcessMessage
Thank you
Please read the Help about giving grades for answers.
If someone gives you an excellent approach then the answer deserves an A
The questioner deserves a B for not implementing it.
And not vice versa
If someone gives you an excellent approach then the answer deserves an A
The questioner deserves a B for not implementing it.
And not vice versa
ASKER
Sorry, I thought C is for not using the proposed solution and A for it to be a solution to the question. So, I gave B because it is a good solutions, but not gonna use it as a solutinos for my question... I see I messed up.
nobody's perfect :)
>>But thank you for the solution, I will definately use it in another app.
don't you think you should change the grade to an A since you are going to use the solution ?
don't you think you should change the grade to an A since you are going to use the solution ?
Grade change by Asker request.
Vee_Mod
Experts Exchange Moderator
Vee_Mod
Experts Exchange Moderator
ASKER
@Geert_Gruwez: thank you for pointing this out - I didn't know I can do this, until your comment and a quick browse through the Help
@Vee_Mod: Thank you.
@Vee_Mod: Thank you.