[SOLVED] Memo is NOT cleared without Application.ProcessMessages;

[CM630]

Just to make sure that this behaviour is correct.
If I execute the code once it behaves properly. The second and the next time (after pressing Button1) it looks... spectacular (the text is not cleared, only the currently updated line is)
If I put Application.ProcessMessages; after Memo1.Clear; it works as expected every time.

Code: Pascal  [Select][+][-]

1. procedure TForm1.Button1Click(Sender: TObject);
2. var
3.   i: integer;
4. begin
5.  Memo1.Clear;
6. // Application.ProcessMessages;
7.  for i:=0 to 10 do
8.  begin
9.    Memo1.Append(IntToStr(i))  ;
10.   sleep(1000);
11.  end; //for
12. end;  

[cdbc]

Hi
Your cpu goes from clearing the memo, straight to updating it with new data, before it has time to check its messagequeue, i.e.: 'GetMessage()' has lower priority than your loop-code.
Therefore, the rules of thumb are:
1) Main thread takes care of GUI-stuff ...and not much else.
2) Any(and all) 'Heavy Lifting', should be put in a background thread.
3) If your house is on fire, you can briefly use 'ProcessMessages'!
4) 'Decoupling' is the name of the game.
HTH
Regards Benny

[Thaddy]

memo.lines.text :=''; ?
but even that requires a repaint.
In both cases the actual memo content is empty.
It is just that the memo's visual representation needs to be updated.
You can also do that like so:

Code: Pascal  [Select][+][-]

1.   memo1.lines.beginupdate;// that is a paint lock
2.   memo1.lines.clear;
3.   memo1.lines.endupdate; // forces a repaint

That option does not need processmessages.
And is faster.

[rvk]

memo.lines.text :=''; ?
but even that requires a repaint.
In both cases the actual memo content is empty.
It is just that the memo's visual representation needs to be updated.
You can also do that like so:

Code: Pascal  [Select][+][-]

1.   memo1.beginupdate;// that is a paint lock
2.   memo1.clear;
3.   memo1.endupdate; // forces a repaint

That option does not need processmessages.
And is faster.

You probably mean:

Code: Pascal  [Select][+][-]

1.   memo1.lines.beginupdate;// that is a paint lock
2.   memo1.clear;
3.   memo1.lines.endupdate;

But NO, that doesn't update the screen !!!! Did you test this yourself? Apperantly not because you would have seen your code doesn't compile 

[Thaddy]

corrected it. And here it updates the screen.
You can also call memo1.invalidate if it does not work (I am on trunks)
It is really not necessary to call processmessages all the time.
Invalidate simply registers a request to update at the next paint.

And note the memo is cleared, it is just not updated on screen.

[rvk]

corrected it. And here it updates the screen.
You can also call invalidate if it does not work (I am on trunks)

NO IT DOESN'T  (I'm also on trunk)
Try it yourself. (or you are missing the point.

You need to press the button a second time and you see the memo isn't cleared until the loop is done (and during the loop you only see the current line updates/blanked).

Invalidate also doesn't update the screen. It sets a flag to update the screen the next time the cycle events comes around. Not directly.

[Thaddy]

Well, after your comment I already did. The memo is cleared. and a repaint occurred.

I only moved the silly sleep() outside the begin/endupdate.
Sleep is blocking.

[rvk]

Well, after your comment I already did. The memo is cleared. and a repaint occurred.

Here it doesn't.
Maybe you should put that sleep(1000) back in that you probably removed.

And you should know that invalidate isn't executed directly but only when the procedure ends.

[Thaddy]

Sleep is blocking. If you don't want that use a thread.

[rvk]

Sleep is blocking. If you don't want that use a thread.

That wasn't the point.
The point was that TMemo.Clear doesn't directly update the screen.
You said EndUpdate and Invalidate it DOES update the screen.
IT DOESN"T.

It only updates the screen when the procedure ends end the rest of the events can be handled.

If you are of a different opinion... please provide some code we can test to show invalidate does directly update the screen.

[BrunoK]

Code: Pascal  [Select][+][-]

1. begin
2.   Memo1.Clear;
3.   Memo1.Refresh;
4.  

[rvk]

Code: Pascal  [Select][+][-]

1. begin
2.   Memo1.Clear;
3.   Memo1.Refresh;
4.  

Yes, TControl.Refresh (which calls TControl.Repaint) does paint the component directly (it's the correct call there).
All other, like Invalidate and EndUpdate only signals the framework to do it after the current procedure but TControl.Repaint and TControl.Refresh repaints it directly.

[MarkMLl]

Sleep is blocking. If you don't want that use a thread.

That wasn't the point.
The point was that TMemo.Clear doesn't directly update the screen.
You said EndUpdate and Invalidate it DOES update the screen.
IT DOESN"T.

It only updates the screen when the procedure ends end the rest of the events can be handled.

If you are of a different opinion... please provide some code we can test to show invalidate does directly update the screen.

That might to some extent depend on the widgetset, i.e. depending on how much of the functionality is provided by the interface code and how much by some Windows-style standard component.

However I think that my experience at https://forum.lazarus.freepascal.org/index.php/topic,67337.msg519191.html#msg519191 might be relevant, which emphasised the importance of the begin/endupdate calls which was more or less where Thaddy came in.

MarkMLl

[CM630]

I tried

Code: Pascal  [Select][+][-]

1.   memo1.lines.beginupdate;// that is a paint lock
2.   memo1.lines.clear;
3.   memo1.lines.endupdate; // forces a repaint

It changes nothing for me.

I also tried:

Code: Pascal  [Select][+][-]

1.   Memo1.Clear;
2.   Memo1.Refresh;

It seems to do fine.

About the “silly sleep” - I have observed this behaviour in two other cases (once in loading files and once when getting data from a DLL).
I made a snippet with sleep, which visibly behaves the same way as the other cases.

[Martin_fr]

Normally painting (screen updates...) is only done during message processing.
That is either
- when your code has run, and no other events are pending
- when you call Application.ProcessMessages

"no other events are pending" means, that even if your ButtonClick has finished, if there is already another click, or a timer, or any other event, then (usually / in most cases) that other event has higher priority than the paint event. The paint event usually waits.

There may be occurrences where - by chance - a control will do paint/screen-update outside of the above schedule. I.e. immediately. But afaik those aren't guaranteed.  And maybe aren't even supposed to happen.


Other than this "Repaint" should work immediately.

Not checked, but "Refresh" may include "Repaint".