That assumes that the users would actually read what was on
the screen

Roy Lambert wrote:

> Sean
>
>
> About the only thing that I can see that will work for you in all the scenarios you describe (eg the main thread of the app processing stuff that won't let messages through) is to write directly to screen memory (if that's even possible these days) and all I have to say to that is "rather you than me"!
>
> Personally if there's stuff clogging up the foreground to that degree I'd prefer to just put up a message "go and have a nice cup of coffee and chill out for 10" <vbg>
>
>
>
> Roy Lambert
>

Sean

>That assumes that the users would actually read what was on
>the screen

Good one - and your reason for a progress indicator was........

For some reason they don't read but they do react to a
progress bar moving. If I really had my way I could get the
keyboard to shock them when they did something stupid...

Roy Lambert wrote:

> Sean
>
>
>>That assumes that the users would actually read what was on
>>the screen
>
>
> Good one - and your reason for a progress indicator was........
>

Sean,

i posted a simple demo to the binary newsgroup.
The progressbar is updated no matter what you do in the thread until the
thread is finished. Additionally the thread updates the button if one loop
has been completed to give some "real" feedback to the user.


Bernd Kuhlmann

Bernd


That's pretty much the same as I posted. The problem is Sean wants the progress indicator to continue even if the MAIN thread is sleeping or doing something very intense eg running a procedure from a 3rd party DLL where he has no influence over it.

Roy Lambert

"Sean McCall" <NoSpam@nowhere.com> wrote in message
news:BA0B2A97-7B20-4D53-A47D-AC74EA130C12@news.elevatesoft.com...
> Roy,
>
> Thanks for taking the time to put that together, but your demo just
> demonstrates what I need. You should notice that when you click button2
> that the progress bar stops moving and then catches up when the sleep loop
> completes. This is because no messages are being processed while
> "sleeping". What I want is for the progress bar to keep steadily moving
> while button2's event handler is sleeping. If you change the sleep time to
> 25 seconds (make it 2500 ms or change the loop to 100) you will notice
> that the demo appears to lock up. I want to find some way to give a visual
> cue that it is not locked up in cases where I don't have access to the
> code that is causing the delay.
>
Just create the progress form in a small independend program/exe and send
the thread progress messages to that program. That IMHO is to only way if
the main program is extremly busy.

Bernd,

Thanks for taking the time to try this. Your method works
fine if the time consuming task is taking place within the
secondary thread. My problem is what to do when time
consuming tasks are taking place within the main thread and
I don't have an opportunity to force the application to
process messages. Add a Sleep(10000) at the end of the
Button1Click event and you'll see what I mean. The TTimer
component relies on the main thread actively processing
messages.

Sean

Bernd Kuhlmann wrote:

> Sean,
>
> i posted a simple demo to the binary newsgroup.
> The progressbar is updated no matter what you do in the thread until the
> thread is finished. Additionally the thread updates the button if one loop
> has been completed to give some "real" feedback to the user.
>
>
> Bernd Kuhlmann

Could have saved some typing if I read all the messages
before responding to Bernd. Roy has it right.

Sean

Roy Lambert wrote:

> Bernd
>
>
> That's pretty much the same as I posted. The problem is Sean wants the progress indicator to continue even if the MAIN thread is sleeping or doing something very intense eg running a procedure from a 3rd party DLL where he has no influence over it.
>
> Roy Lambert
>

"Sean McCall" <NoSpam@nowhere.com> wrote in message
news:4E010836-FDF1-47DB-B5E2-492024EFEBA1@news.elevatesoft.com...
> For some reason they don't read but they do react to a progress bar
> moving. If I really had my way I could get the keyboard to shock them when
> they did something stupid...

If all you want is a progress bar then the TProgressBar won't work for you
in this instance - if you want to be really naughty you can force a refresh
on the PegtopProgressBar (www.pegtop.net) from a seperate thread - although
personally I couldn't condone such behaviour

procedure TTestThread.Execute;
var
  nLoop : Integer;
begin
for nLoop:=1 to 100 do
 begin
  Form1.PegTopProgressBar1.Position:=nLoop;
  Form1.PegTopProgressBar1.Refresh;
  Sleep(20);
 end;
end;

procedure TForm1.Button1Click(Sender: TObject);
begin
With TTestThread.Create(False) do
 try
  WaitForSingleObject(Handle,INFINITE);
 finally
  Free;
 end;
end;

D.

Darren,

Sounds like this might be what I need. Couldn't find the
PegtopProgressBar on the site. Could you give me a hint on
where to find it?

BTW, are you the author?

Sean


Darren Davis wrote:

> "Sean McCall" <NoSpam@nowhere.com> wrote in message
> news:4E010836-FDF1-47DB-B5E2-492024EFEBA1@news.elevatesoft.com...
>
>>For some reason they don't read but they do react to a progress bar
>>moving. If I really had my way I could get the keyboard to shock them when
>>they did something stupid...
>
>
> If all you want is a progress bar then the TProgressBar won't work for you
> in this instance - if you want to be really naughty you can force a refresh
> on the PegtopProgressBar (www.pegtop.net) from a seperate thread - although
> personally I couldn't condone such behaviour
>
> procedure TTestThread.Execute;
> var
>    nLoop : Integer;
> begin
>  for nLoop:=1 to 100 do
>   begin
>    Form1.PegTopProgressBar1.Position:=nLoop;
>    Form1.PegTopProgressBar1.Refresh;
>    Sleep(20);
>   end;
> end;
>
> procedure TForm1.Button1Click(Sender: TObject);
> begin
>  With TTestThread.Create(False) do
>   try
>    WaitForSingleObject(Handle,INFINITE);
>   finally
>    Free;
>   end;
> end;
>
> D.
>
>