Board index » cppbuilder » TProgressBar & Application->ProcessMessages()

TProgressBar & Application->ProcessMessages()


2004-06-25 12:02:58 AM
cppbuilder67
Does anyone know if it's necessary to call Application->ProcessMessages()
when updating a progress bar in a loop. It seems to work and repaint fine
without it, but who knows how it will act on different pc's. Thanks!
Kelly
 
 

Re:TProgressBar & Application->ProcessMessages()

"Kelly Domalik" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
Does anyone know if it's necessary to call Application->ProcessMessages()
when updating a progress bar in a loop. It seems to work and repaint fine
without it, but who knows how it will act on different pc's. Thanks!

Kelly
hi Kelly,
i will suggest to call Application->ProcessMessages()
ANYWAY...it slows a bit down the loop because you let new messages
to be processed...
here's a copy 'n paste of a post from me & Remy few months ago...
-----------------------------------------------------------------------
"Oren Halvani" <....>wrote in message
Quote
Now, when a function is running and the ProgressBar is
stepping I see ONLY the ProgressBar !! The other controls
are invisible...why...?
Your function is not allowing new messages to be processed.
Quote
I tryed:

Application->ProcessMessages()

in the OnPaint Event of the form...
That is not the correct place to put it. If no new messages are processed
while you are inside your function, then that event won't be triggered to
begin with. You need to move the call to ProcessMessages() to inside your
actual function itself, ie:
void __fastcall TForm1::cmdInsert_LineNumbersClick(TObject *Sender)
{
frmProcessWindow->Progress->Position = 0;
frmProcessWindow->Progress->Max = Memo1->Lines->Count;
frmProcessWindow->Show();
Screen->Cursor = crHourGlass;
try
{
for(int x = 0; x < Memo1->Lines->Count; ++x)
{
Memo1->Lines->Strings[x] = String(x + 1) + ".) " +
Memo1->Lines->Strings[x];
frmProcessWindow->Progress->Position = (x+1);
Application->ProcessMessages(); // <-- here
}
}
__finally
{
frmProcessWindow->Progress->Position = 0;
frmProcessWindow->Close();
Screen->Cursor = crDefault;
}
}
Gambit
 

Re:TProgressBar & Application->ProcessMessages()

Kelly Domalik wrote:
Quote
Does anyone know if it's necessary to call
Application->ProcessMessages() when updating a progress bar in a loop.
It's advisable because without it your application will not respond to
the mouse. Some VCL components do seem able to redraw themselves
independant of the Windows messaging system but most can't.
You can test this by:
* Trying to move or resize the application's main window.
* Popping a window up over the top of your application then removing
it to see how is redrawn.
Note however that by calling ProcessMessages() you are allowing your
application to respond to any event. This is important because it
allows your user to click any buttons, menus etc. are that are not
disabled. There is also a bug in the VCL which can lead to a modal
window not being completely modal (usually when switching back to your
app from another one).
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

{smallsort}

Re:TProgressBar & Application->ProcessMessages()

"Andrue Cope [TeamB]" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
There is also a bug in the VCL which can lead to a modal
window not being completely modal (usually when switching back to your
app from another one).

--
Andrue Cope [TeamB]
[Bicester, Uk]
Andrue, this is true..i had this often in my projects..i'm using BCB3, is it
possible
to avoid this problem..?
Oren
 

Re:TProgressBar & Application->ProcessMessages()

Thanks Oren & Andrue, I'll go ahead and add it. I was actually hoping I
didn't need it because I don't want the user to be able to do anything while
it's looping.
"Kelly Domalik" < XXXX@XXXXX.COM >wrote in message
Quote
Does anyone know if it's necessary to call Application->ProcessMessages()
when updating a progress bar in a loop. It seems to work and repaint fine
without it, but who knows how it will act on different pc's. Thanks!

Kelly


 

Re:TProgressBar & Application->ProcessMessages()

Kelly Domalik wrote:
Quote
Thanks Oren & Andrue, I'll go ahead and add it. I was actually hoping I
didn't need it because I don't want the user to be able to do anything while
it's looping.
If it is only for the TProgressBar you might call its Update() method instead
if it has.
But if it updates withhout ProcessMessage() than you do not need to change anything.
Hans.
 

Re:TProgressBar & Application->ProcessMessages()

Oren Halvani wrote:
Quote
Andrue, this is true..i had this often in my projects..i'm using
BCB3, is it possible
to avoid this problem..?
I haven't found a way, yet. I use BCB6 and the problem is still there.
FWIW it also aflicts BCB itself. There was a post last year on the
subject but it failed to produce a solution.
--
Andrue Cope [TeamB]
[Bicester, Uk]
info.borland.com/newsgroups/guide.html
 

Re:TProgressBar & Application->ProcessMessages()

On 25 Jun 2004 01:06:43 -0700, Andrue Cope [TeamB] < XXXX@XXXXX.COM >
wrote:
Quote

I haven't found a way, yet. I use BCB6 and the problem is still there.
FWIW it also aflicts BCB itself. There was a post last year on the
subject but it failed to produce a solution.

We call one of our own messages instead of Application->ProcessMessages.
Give them the handle of the control you want to repaint or accept mouse
messages on, or pass in NULL to deal with all messages. We also use the
inProcessMessage param to clear the message queue instead of dealing with
the messages.
void ProcessMouseMessages(HWND Handle, bool inProcessMessage)
{
MSG msg;
while (PeekMessage(&msg, Handle, WM_MOUSEFIRST, WM_MOUSELAST,
PM_REMOVE))
{
if (inProcessMessage)
{
DispatchMessage(&msg);
}
}
}
void ProcessPaintMessages(HWND Handle, bool inProcessMessage)
{
MSG msg;
while (PeekMessage(&msg, Handle, WM_PAINT, WM_PAINT, PM_REMOVE))
{
if (inProcessMessage)
{
DispatchMessage(&msg);
}
}
}
Simon